What actually happens when a password manager's servers go down

On the evening of August 27, 2026, NordPass logged a login incident on its own status page. Investigation started at 20:31 EEST, the cause was identified by 21:04, a fix went out at 21:16, and by 21:41 the company had marked it resolved. Seventy minutes, start to finish. Outage trackers that aggregate user reports show the same window from the other direction — a handful of complaints climbing to dozens within the first quarter hour, then tapering off once the fix landed.

By the standards of a security newsletter, this barely registers. No data was exposed. No vault was cracked. Nobody’s encryption failed. It was a login problem, fixed in about the time it takes to watch a movie’s first act, and it could have happened to any company running a service like this — it says nothing in particular about NordPass’s competence, and we’re not writing this to suggest otherwise.

We’re writing about it because it’s a clean, undisputed, dated example of something worth understanding regardless of which password manager you use: for about seventy minutes, an unknown number of people who use that product could not get to their own passwords. Not because the passwords were compromised. Because the door was locked, and the only key was on the other side of a server that was, briefly, not answering.

Two different promises, easy to mix up

A password manager makes you two separate promises, and most marketing collapses them into one word: “secure.”

The first promise is about confidentiality — is my data unreadable to anyone who shouldn’t have it? That’s the promise behind end-to-end encryption, zero-knowledge architecture, all the things a company can (and should) demonstrate with real engineering evidence. We wrote about how four cryptographers spent a year testing whether “zero-knowledge encryption” actually holds up against that exact question.

The second promise is about availability — can I actually open my vault, right now, when I need to? That one gets almost no attention, because it’s usually true. Cloud services have excellent uptime. Most people go years without noticing this promise exists at all, the same way you don’t think about your tap water until it stops running.

The NordPass incident is a reminder that these are genuinely two different things. Your data can be perfectly safe and still be temporarily out of reach. Neither promise implies the other.

Why a login server sits in the way at all

Here’s the part that’s easy to miss if you’ve never had to think about it: for most cloud-synced password managers, “safe” and “reachable” are linked by design, because reaching your vault means talking to a server first.

The usual shape looks like this. Your vault — the actual encrypted blob of your passwords — lives on the company’s servers, synced across your devices. To open it, your device authenticates you (password, passkey, whatever the product uses), the server confirms the session is legitimate, and only then does your device fetch the encrypted vault and decrypt it locally. The encryption is real. The company genuinely cannot read the contents. But the fetch has to happen first, and the fetch needs a server that recognizes you.

That login step is where an incident like this one lands. The vault itself was never touched — it sat on NordPass’s infrastructure exactly as encrypted as it was the day before. What broke was the handshake that lets a legitimate device prove it’s allowed to ask for that vault. Nothing about the seventy minutes made anyone’s data less safe. It made the data briefly unreachable to the person who’s actually supposed to have it, which is its own kind of bad day, just a much smaller one than a breach.

This isn’t a criticism specific to any one company. It’s a structural property of any product where retrieval is gated behind a live login. Build a password manager that syncs across devices through a central service, and you’ve built something that inherits that service’s uptime as a ceiling on how reliably you can reach your own encrypted data. The alternative — never requiring a login to open a local copy — trades away centralized sync for something that doesn’t have this specific failure mode. Neither choice is free; they just fail differently.

What actually helps, no matter what you use

If you use a cloud-synced password manager and none of this changes your mind, that’s a completely reasonable place to land. Seventy minutes a few times a year is a trade a lot of people would happily make for automatic sync across every device they own. But it’s worth knowing the trade is real, and worth doing a few concrete things regardless of which product you use:

Find out if your tool has a genuine offline cache. Some cloud-synced managers keep a locally decrypted (or locally decryptable) copy on each device after your first successful login, specifically so a later server hiccup doesn’t lock you out of a vault you already opened once today. Others re-authenticate every session. Check your product’s own documentation — this is exactly the kind of thing that should be stated plainly, not buried.

Keep an actual export. An encrypted export file, stored somewhere you control, is the difference between “the company is down” being an inconvenience and being a genuine lockout. This matters more than it sounds like it should, because most people set up a password manager once and never touch the export function again. We added real import and export to Vauz for exactly this reason — not to compete with cloud sync, but because moving a vault, or having a backup of one, is table stakes for anything asking to hold this much of your digital life. Encryption is on by default, the export passphrase has to clear a real strength check, and writing the file out requires a fresh Touch ID or V-Key confirmation, the same discipline we described when we rebuilt how Vauz approves anything leaving the vault.

Separate “is my data safe” from “can I reach it right now” when you’re evaluating a product. They’re both real questions. They just have different answers, and a company that only ever talks about the first one is telling you half the story.

Where local-first actually changes the picture

This is the moment where it’s honest to talk about Vauz specifically, because the architecture genuinely bears on the exact failure mode above — not a general claim that local-first is “more secure,” but a specific, checkable one: Vauz doesn’t ask you to log in to a server to open your own vault, because there’s no server in that path to begin with.

Vauz  keeps your vault on the device you’re using it on. The reasoning is the same one we laid out when we wrote about why Vauz keeps secrets local: every system that has to sit between you and your data is a system that can have a bad seventy minutes. Removing an unnecessary hop doesn’t just narrow who has to be trusted with your secrets — it narrows how many things have to be working correctly at 8 p.m. on a Thursday for you to get into your own accounts.

That’s not a free lunch, and we’d rather say so than let the omission do the arguing for us. A local-first vault doesn’t have a company-run backup sitting behind it the way a cloud-synced one does. If your device is lost, stolen, or destroyed and you never made an export, there’s no support ticket that gets your vault back — because nobody but you ever had a copy of it. The tradeoff is real: you gain freedom from someone else’s login server, and you take on the job of being your own backup plan. We think that’s the better trade, not because a bad seventy minutes is your only alternative, but because the same architecture that removes the login-server dependency is the one that means nobody but you was ever in a position to lose your vault, misconfigure your account, or hand it to the wrong person by mistake.

The actual takeaway

Nobody’s password was in danger this week. That’s worth saying plainly, because it’s true, and because it’s tempting to read any outage as a security failure when it usually isn’t one. What happened was smaller and, in its own way, more instructive: a perfectly safe pile of encrypted data became briefly unreachable, because reaching it required a server that wasn’t, for seventy minutes, doing its job.

That’s a fact about architecture, not about any one company’s diligence. Every product built the same way carries the same exposure. The question worth asking about whatever you use — Vauz included — isn’t just “is my data encrypted?” It’s “what has to be true, right now, for me to actually open it?” That second question is the one most of us never get around to asking until the seventy minutes when we need to.

For Vauz, the answer to that second question is the same on every plan: nothing has to be true except that your own device is on, because there was never a login server in the path to begin with. That’s the architecture, not a feature you pay for. Vauz is free for life on the free plan, with Plus and Premium  available if you want more from it.