Malware on your machine beats every password manager. What happens next is where they differ.

There is a version of the local-first pitch that is not honest, and it goes roughly like this: your passwords never leave your device, so the breaches you read about cannot touch you.

The first half is a design decision. The second half is a leap, and this article is about where it lands.

Here is the short answer, so nobody has to read to the end for it. No password manager — ours, theirs, the one built into your browser — protects you from malware that is already running with your privileges. What differs between products is everything that happens on either side of that sentence: how much a single infection is worth, whether a copy of your vault is also sitting in a company’s database in a form that company can open, and whether the vendor tells you where the edges are before you find them yourself. Those differences are large, they are checkable, and they are the reason we think the local-first trade is the better one.

The number

On September 1st, Flashpoint published the midyear edition of its threat intelligence report. The line worth copying down: the company tracked 7.4 million hosts compromised by infostealers in the first half of 2026 — a 27% increase period over period — harvesting 1.7 billion credentials and identity records. Delivery was mostly unglamorous: drive-by downloads, watering holes, and pirated software .

Those are not 1.7 billion passwords guessed, or cracked, or prised out of a company’s database. They were taken off ordinary computers, one at a time, by software the owner installed by accident.

That distinction matters more than the size of the number, because it describes a completely different attacker than the one most security advice is written for.

What an infostealer actually does

A stealer is not clever, and it is not trying to be. It runs on your machine, with your account’s privileges, and it reads the things you can read.

That means the browser’s saved-password store and its autofill entries. It means session cookies and refresh tokens, which are the part people underestimate. It means crypto wallet files, messaging app sessions, and whatever documents match a filename pattern worth grabbing. Then it packages the lot as a “log” — a tidy archive, sorted and searchable — and uploads it. Modern ones do the whole job in well under a minute and try to keep everything in memory so there is less on disk to notice.

The session cookie is the part that quietly defeats the advice most people have already followed. A valid session token is proof that somebody already passed the login — including the multi-factor prompt, which the real user answered honestly, hours earlier. An attacker who replays that token does not need the password or the code. There is nothing left to challenge.

The current generation makes this sharper. Varonis’ write-up of the Storm stealer  in April described malware that does not bother decrypting the browser’s credential store on the victim’s machine at all. Chrome’s App-Bound Encryption made local decryption awkward, so Storm ships the encrypted files to the attacker’s own infrastructure and decrypts them there, server-side, for Chromium and Firefox-family browsers alike. It also pairs a stolen Google refresh token with a SOCKS5 proxy in roughly the victim’s location, so the resumed session looks unremarkable and no “new sign-in” warning fires.

Read that again as a design brief rather than a news item: the attacker has moved the hard part off your computer, and left behind only the fast, boring, easily-missed part.

The part no password manager fixes

Here is the sentence we would rather write ourselves than have someone else write about us. From the Vauz threat model , in the section listing attackers the design does not defend against:

Code holding your privileges can read what you can read, watch what you type, and see what is on your screen.

That is the whole answer, and it applies to Vauz exactly as it applies to everything else on the machine. A password manager is an application. Malware running as you outranks an application running as you. If it can watch the screen, it can watch a password appear on it; if it can read your keystrokes, an unlock is just more keystrokes. The same page says the point again about the layer underneath: if the operating system itself is backdoored, everything above it applies without a ceiling.

This is not a local-vault problem. It is an application problem, and every password manager is an application. A cloud-synced vault on that same infected machine is in precisely the same position the moment you unlock it — the decrypted entries are in memory on a computer the attacker controls, and the session tokens it uses to sync are in the same log as everything else. Nobody’s architecture puts them out of reach of code running as you. So no: keeping a vault on your own device is not, by itself, a defence against a stealer already on that device, and anyone selling local-first as malware protection is selling something that does not exist.

The honest claim is narrower than that, and it is worth stating precisely, because a narrow claim you can check is worth more than a broad one you cannot. It is also, once you look at it properly, the more useful half.

What it does change

Think about what a stealer has to do to get 1.7 billion credentials: infect 7.4 million machines, one at a time, each one a separate operation that can fail, get cleaned, or find nothing. Now think about what happens when a company holding millions of vaults on one set of servers has a bad week. Same haul, one operation.

That is the trade a local-first design actually makes, and it is not a small one. It does not lower the risk that your own machine gets compromised — nothing a password manager does can. What it removes is every other path to your entries. Your entries are not sitting in a pile that someone could read by breaching one company. Nobody’s mistake but yours puts them in a log. We cannot read your vault — not the entries, not the passwords, not the notes, not the sites you saved, not your V-Key and not its hint — and that holds wherever a copy of it happens to sit, because we hold no key that opens it. The threat model’s line on stolen vault files is that they are readable only on the computer that created them; copying the file to another machine gets an attacker a file, not a vault. That is a smaller promise than “you are safe,” and a considerably easier one to keep — the reasoning we laid out in how Vauz keeps secrets local.

There is a second, less obvious effect. Because no two stored values share an encryption key, and because what protects them is derived from the machine rather than from a phrase you memorised, “the attacker got in” and “the attacker got everything” stop being the same sentence — the same structural point that made the master-password recovery bug earlier this month possible in the first place.

So if you are weighing a move from a cloud-synced manager, here is the trade in one line, with nothing hidden in it. Your exposure to malware on your own machine is roughly unchanged, because that exposure was never really about where the vault lives. What goes away is the part of your risk that depends on a company you cannot audit having a good year, every year, forever — the breach you read about in someone else’s headline, the server-side copy you did not know existed, the login server that has to be working for you to open your own vault. For most people that is the larger share of the risk, and it is the share you can actually do something about today. Removing it is what we built Vauz  to do.

What actually helps

Since the mechanism is “code runs as you,” the defences are the unglamorous ones:

• The delivery is the weak link, not the encryption. Cracked software, a download from a search ad, a helpful-looking installer. Almost everything in those 7.4 million hosts arrived through a decision, not an exploit chain.
• Treat session cookies as credentials. After any suspected infection, signing out everywhere — invalidating sessions server-side — matters as much as changing passwords, because the cookie is what survives a password change.
• Order matters when cleaning up. Changing passwords on a machine that is still infected just hands over the new ones. Clean or rebuild first, from a device you trust, then rotate.
• Use a password manager, and use unique passwords per site. This is the ordinary, boring reason a vault is worth having — not because it repels malware, but because it stops one stolen credential from becoming twenty, and because rotating after an incident is a twenty-minute job instead of a weekend.
• Ask any vendor where their protection stops. A product that publishes explicit non-goals has thought about the boundary. A product that implies there isn’t one has told you something too, just not on purpose.

The reason to write this down

It would be easier to publish the number, gesture at the cloud, and let the reader conclude that a local vault is a forcefield. That reader would come away with a wrong model of their own risk, and would find out it was wrong at the least convenient possible moment.

The zero-knowledge piece made a version of this argument about a phrase on a pricing page: a promise is only worth something once someone has written down what would have to be true for it to hold, and what it never covered. A threat model is that document. Ours says in plain words that malware on your machine beats us, and it will keep saying so, because the alternative is a claim we would have to quietly walk back the first time someone tested it.

It says the other half just as plainly, and that half is why we build this. There is no copy of your vault that we can read. A stolen file is not a vault. One compromised entry is not all of them. Those are the things a password manager can actually promise you, and they are the things we would want a reader to weigh — not in place of the limits, but alongside them. If that is the trade you would make, Vauz is free for life on the free plan , and moving your entries in is a job for one evening.