Passkeys are quietly breaking multi-account workflows

If you run many accounts, you have probably already hit this without diagnosing it: an account that used to log in fine now insists on a passkey, and the profile cannot produce one. The account is not banned. It is unreachable.

Why a password manager does not solve it

A password is a string. Copy it anywhere and it works. That is why the whole multi-account tooling ecosystem is built around storing strings.

A passkey is not a string. It is a key pair generated inside an authenticator, and the private half never leaves it. During registration the site stores the public key and a credential ID. At sign-in the site sends a challenge, the authenticator signs it, and the site verifies the signature. Nothing that can be pasted between profiles is ever produced.

Three consequences follow, and each breaks something people rely on:

1. No authenticator, no enrolment. A browser profile without one cannot complete registration at all. Sites that require a passkey are simply closed.
2. The credential is bound to where it was made. Enrol on profile A and profile B cannot use it, even with identical cookies. There is nothing to export.
3. Losing the profile loses the account. If the passkey was the only factor, a wiped profile means an account you can no longer authenticate to, and recovery flows are exactly the friction the passkey removed.

Why this hits account warming hardest

Warming an account is an investment: consistent identity, plausible activity, a history that makes the account look real. It pays off over weeks.

Passkeys change what "the same identity" has to include. It is no longer just cookies, storage and a coherent fingerprint. It now includes a cryptographic key the site expects the same authenticator to hold. A warmed account whose passkey is gone is a warmed account you cannot open, and the effort is written off.

The migration is one-directional. Platforms are moving passkeys from optional, to default, to required. Every month, more of the accounts you already hold quietly move into the category that needs one.

What a per-profile virtual authenticator changes

A virtual authenticator is a software authenticator the browser exposes to the WebAuthn API. The site cannot tell the difference: it gets a valid key pair, valid signatures, a valid credential ID.

The part that matters is scope. One authenticator per profile, stored with that profile rather than shared. So:

• Profile A enrols a passkey on a site. The credential is captured and stored with profile A.
• Later, profile A signs in. The stored credential is replayed, and the account opens without re-enrolment.
• Profile B, on the same site, is a different person with a different authenticator, exactly as two real people on two real laptops would be.
• The credential travels with the profile. Export the profile, import it on another machine, and the passkey comes with it.

In AntiBrow this is on by default for every new profile, and can be turned off per profile if you would rather choose per site. The credentials live in the profile directory on your own disk, alongside the cookies, and only leave the machine if you explicitly turn on cloud sync for that profile.

What this does not do

• It is not a bypass. It does not defeat a passkey requirement, forge someone else's credential, or recover an account you do not control. It makes a browser profile behave like a device that owns its own keys, which is what a real user's laptop is.
• It does not survive a deleted profile unless you exported it or had sync on. Same as losing a phone.
• It does not affect detection. Proxy quality, behaviour and account history still decide most outcomes.

Check whether it works

Open webauthn.io in a fresh profile, register a passkey, close the browser, reopen the same profile, and log in. If the credential replays, the profile owns its authenticator. If it does not, that profile will lose every account that moves to passkeys.

That test is free to run: unlimited local profiles, no card.

Download the desktop app or see where the credentials are stored.