Most small teams adopt passkeys for the right reason: passwords keep failing in the same quiet ways. A shared login sits in a spreadsheet, a reset email cannot be found, and a former employee still knows a password they should no longer have. Passkeys fix the underlying problem. They replace the shared secret with a cryptographic key pair built on the FIDO2 standard, and the private half never leaves the device that created it. There is nothing to phish, nothing to reuse, and nothing for a breached database to leak.
Yet the sign-in itself is rarely where a passkey rollout breaks. The break comes later, on an ordinary bad day: a phone is lost, or someone leaves and their access needs to end cleanly. Those are the moments most guides skip, and they are worth planning for before anyone needs the plan.
A lost phone is not a lost account — if the passkey can sync
If passkeys sync through a password manager or a platform account, a new phone restores them after signing in. Apple stores them in iCloud Keychain, Google in Google Password Manager, and Microsoft through Windows Hello. The major password managers, including 1Password and Bitwarden, also store passkeys alongside passwords. That sync turns a lost phone from a crisis into an inconvenience.
If a passkey was created on-device only, with no sync, it is gone with the phone. The account then falls back to its password and second factor — assuming those still work. That is why work passkeys should live in the synced manager, not on one device: no work passkey lives only on one person’s phone. The manager itself deserves the same care — set up its own recovery method at the start and test it once, since it is the one account a team cannot afford to lose.
Shared accounts need shared passkeys — in a shared vault
Shared accounts are where good intentions quietly undo themselves. A passkey on one person’s phone for a shared account is a new version of the old problem: the access belongs to a person, not to the team.
The fix is not more technology. It is a vault rule: shared-account passkeys go in the shared vault of the password manager, where anyone with vault access can use them and where removing a person revokes them. Personal passkeys stay personal. Shared passkeys stay shared.
Offboarding: one removal, in the right order
When someone leaves, the order of operations matters. First, remove them from the password manager the same day, and from the shared vaults. Their personal passkeys go with them, which is correct. Any shared-account passkey stored in the shared vault stays with the team.
Second, rotate the shared passwords they could see, starting with the most sensitive. Some services still do not support passkeys — many banking apps, government services, and smaller tools among them — so those accounts still run on strong, unique passwords in the manager. A leaver who knew one of those passwords still needs that password changed.
That two-step sequence — remove, then rotate — is the whole offboarding checklist. Written down in advance, it takes minutes. Discovered in the moment, it takes an afternoon of password changes and guesswork. A new starter is the same checklist in reverse: invite them to the manager, share vaults by job, and let them create passkeys as they go.
Do not remove the safety net too soon
One common mistake is removing passwords the moment passkeys are working. Keep the password as a fallback for at least two weeks of normal use, then remove it only on services that offer a passkey-only option. The long tail of services that do not support passkeys yet should stay on strong passwords in the manager, reviewed every quarter.
Passkeys do not fix a bad account. A passkey on an account with weak recovery settings — a reset email nobody monitors, a phone number that belongs to a former employee — is still a weak account. Fix recovery settings during the first audit, before the rollout begins, not after a lockout exposes them.
Test the plan before you need it
A recovery plan earns its keep in a rehearsal, not in a crisis. Pick one person, have them sign into the manager on a spare device, and confirm their passkeys are there. Walk through a departure on paper: who removes the person, and who rotates which passwords? If any step depends on one person’s memory or one person’s phone, it is not a plan yet.
The FIDO Alliance’s Passkey Index 2026, published in October 2026, found passkey sign-ins succeeded 93% of the time, against 78% for traditional multi-factor authentication. Reliability is no longer the argument against passkeys. The remaining work is operational: where passkeys live, who can reach them, and what happens when a device or a person disappears.
That is the part worth writing down first. A team that plans recovery and offboarding before it needs them gets what passkeys promise — fewer resets, fewer shared secrets, and one clean action when someone leaves. For a fuller walkthrough of the rollout that leads up to this point, see the ExactReads guide to moving a small team off passwords on ExactReads.