Passkeys are arriving, and they change fleet logins

What a passkey actually is

A passkey isn’t a stronger password. It’s a different kind of object entirely. When you “create a passkey” for a site, your device generates a public-private key pair using the WebAuthn standard. The private key never leaves the device’s secure hardware, whether that’s a TPM on a laptop, the Secure Enclave on an iPhone, or the StrongBox keystore on a modern Android phone. The site only ever gets the public key. When you log in, the site sends a challenge, your device signs it with the private key, and the site checks the signature against the public key it already has on file.

That’s why passkeys resist phishing in a way passwords never could. There’s nothing to type into a fake login page, because the private key physically can’t leave the hardware it was generated on. It’s also why passkeys don’t behave like the credentials we’re used to managing across a fleet.

The whole model of running many accounts has always rested on a simple pattern: one email, one password, stored per-profile, isolated from every other profile’s cookies, storage, and fingerprint. Password managers made this trivial to scale. Passkeys don’t fit that pattern, because a passkey isn’t a string you can copy into a vault and drop into a different browser profile. It’s cryptographically bound to the authenticator that created it.

For most people, that authenticator is tied to a platform account: an Apple ID, a Google account, a Microsoft account. Passkeys created on a device sync end to end encrypted to every other device signed into that same ecosystem account. So if you sign into the same Apple ID or Google account across ten different antidetect profiles just to get passkey support working, all ten of those “separate” accounts are now authenticating through the same underlying key material and the same platform identity behind the scenes. The browser fingerprint can look completely different from profile to profile. The authenticator behind the login doesn’t care about any of that.

This is the part that matters for anyone searching passkeys multiple accounts and expecting the answer to be a workaround. There isn’t a clean one. Passkeys were built specifically to resist being detached from a device and reused elsewhere, which is exactly what running isolated accounts requires.

The signal hiding inside the ceremony

Antidetect browsers spoof canvas output, fonts, timezone, WebGL parameters, and dozens of other surface-level signals. None of that touches what happens during a WebAuthn ceremony, because the browser just forwards the request to the OS-level authenticator API and reports back what it gets.

Two details in that exchange matter for detection. First, the AAGUID: an identifier the authenticator sends that names the vendor and model of the authenticator itself (Windows Hello, a specific security key model, a specific phone’s secure element). If a platform sees the same AAGUID enrolling passkeys across accounts it otherwise has no reason to link, that’s a correlation signal, the same category of problem as reusing one canvas fingerprint across many profiles, just one layer deeper in the stack.

Second, some relying parties request attestation, a signed statement from the authenticator about its own hardware. Not every site asks for it, and not every authenticator provides much detail even when asked, but where it’s present it’s another fact about the real device that no amount of profile spoofing changes.

None of this means passkeys are some kind of trap built to catch multi-account operators. They exist to stop credential theft and phishing, and they do that well. But a side effect of binding a credential tightly to hardware is that the credential also becomes a much stickier identifier than a password ever was.

Cloud phones and the keystore problem

This is where the hardware you’re actually running on starts to matter more than the software spoofing layered on top of it.

A genuine cloud phone, a separate Android instance with its own isolated storage and its own hardware-backed or virtualized keystore, generates its own distinct authenticator identity. Enroll a passkey there and it’s bound to that instance, not to twenty other profiles running on the same physical box. That’s a real, structural form of isolation, not a cosmetic one, because the key material itself never crosses instances.

Compare that to running many browser profiles on a single desktop OS, all pointed at the same Windows Hello or the same signed-in Google account for passkey sync. However convincing the fingerprints look, the authenticator underneath is shared, and shared authenticators are exactly what passkeys were designed to make identifiable.

This is also why cloud phones matter more here than they do for ordinary session isolation. Cookie and storage separation was always solvable with software. Authenticator separation needs separate hardware, or at minimum separate virtualized secure elements that don’t share sync state with each other.

Proxies still matter, just not for this

It’s worth being direct about what residential and mobile proxies do and don’t solve. Proxies control the network origin an account is seen from, which matters enormously for IP reputation, geolocation consistency, and ASN-based flags. None of that touches the WebAuthn layer. A passkey ceremony doesn’t route through your proxy in any way that changes the signature or the authenticator identity being presented. You can run a perfectly clean residential IP in the right city and still have every account behind it share one authenticator fingerprint if they’re all enrolling passkeys through the same signed-in device account.

Proxies remain necessary for the network-level story an account tells. They were never going to be the answer to a credential-level correlation problem, and passkeys are exactly that.

What to actually do about it

A few practical points, based purely on how the mechanism works:

Treat each isolated identity as needing its own authenticator, not just its own browser profile. If you’re using cloud phones, that’s already close to true by default, since each instance has its own keystore. If you’re running desktop profiles, sharing one OS-level passkey store across accounts undoes a lot of the separation you’re paying for elsewhere.

Don’t assume you have to enroll a passkey everywhere it’s offered. Most platforms still support password plus a second factor as a fallback, and that path doesn’t create the same authenticator-level fingerprint. Passkeys are being pushed hard as the default, but “default” and “required” aren’t the same thing yet on most platforms, and it’s worth checking per-platform rather than assuming.

Where a platform does move toward requiring passkeys, plan for account recovery before you need it. A passkey lost with its device is often harder to recover than a forgotten password, and that’s a real operational risk on top of the correlation risk, not just a security upside.

The honest state of things right now

Passkey adoption is uneven. Some platforms offer it as one option among several. Others are actively steering users toward it and away from passwords. That’s going to keep shifting, and it’s not something a single article can pin down with certainty months out. What doesn’t shift is the underlying mechanism: a passkey is hardware-bound key material, not a portable secret, and that changes the math on what “isolated” actually means for a fleet.

The operators who’ll handle this well aren’t the ones looking for a clever bypass. They’re the ones who match their infrastructure to how the credential actually works: real hardware separation where it counts, proxies doing the network job they’re good at, and a clear-eyed read on which platforms are moving fast on this versus which ones aren’t yet.

If you’re building out a fleet and want infrastructure built around how detection actually works rather than around guesswork, take a look at Multi Account Ops.

Get new guides and videos first — join the Telegram channel.