Passkeys for small teams: a rollout that doesn't lock anyone out

Passkeys are the first login technology that is genuinely hard to phish: the private key never leaves the device, the credential is bound to your domain, and a fake login page has nothing to steal. That's the pitch, and it's true. The part the pitch skips is what happens at 2am when the one laptop holding the credential is at the bottom of a lake, or when the person who just resigned is the only human registered on the billing portal. Passkeys trade one failure mode (stolen passwords) for another if you roll them out carelessly (unrecoverable accounts). This is the rollout order that keeps every step safe even if the project dies there — the same rule that makes a password manager rollout survivable.

1. Why this is an ops decision, not an IT flavor-of-the-month

• Passwords are your biggest unpatched attack surface. Reused passwords, phished credentials, Post-it notes: every breach you'd spend 24 hours cleaning up starts with a login. Passkeys remove the reusable secret entirely — there is no password for an employee to reuse across the SaaS tool they also use at their other job.
• But recovery is the product, not the login. A login method is only as good as its recovery path, because recovery always happens under stress, at night, to the person least technical on the team. Any rollout that registers passkeys before it has tested account recovery is building a faster way to lose access, not a safer one.
• Vendors are wildly uneven. One tool supports passkeys natively; the next offers "passkey" but recovery falls back to SMS to a phone number nobody has updated since 2021; the third only takes passwords and TOTP. Treating passkeys as a single switch is the mistake; they're a per-vendor change, decided tool by tool.

2. Thirty seconds of theory, so the decisions make sense

• A passkey is a key pair per site. The public key sits with the vendor; the private key stays in the device's secure storage (iCloud Keychain, Google Password Manager, or a hardware key like a YubiKey). Nothing to type, nothing to phish: the browser only offers the credential to the exact domain it was created for.
• Synced vs device-bound is the fork in the road. Platform passkeys sync through iCloud or Google across a person's devices — convenient, and a lost laptop is survivable. Hardware keys are device-bound: nothing syncs, but you can hold a spare in a drawer. Small teams usually want both: synced passkeys for daily humans, hardware keys for the accounts that can't be allowed to break.
• The account is still the unit of failure. If the only registered credential belongs to one device and that device dies, the account isn't "less secure" — it's bricked. Every step below exists to keep a second live path to every account that matters.

3. The rollout order

1. Break-glass recovery first, before a single passkey exists. Pick one admin account that will never hold only a passkey: password in the shared vault (the same vault your password manager rollout maintains), TOTP codes from an authenticator whose backup lives in that vault, and — where the vendor allows it — two hardware keys, one in a safe, one off-site. Test logging in with it the same day. If this account can't get you into every critical SaaS, fix that before anything else.
2. Inventory the accounts and their vendor support. The same list discipline as the email audit: billing, hosting, registrar, DNS, payroll, helpdesk, the CRM. Three columns: passkeys fully supported / passkey plus weak recovery fallback / password-only. Column one is your rollout list; column two needs the fallback fixed first (update the phone number, kill SMS-only recovery); column three keeps TOTP, which is still a large step up from a reused password.
3. Fix the platform substrate before registering anything. iCloud Keychain sync requires two-factor authentication on the Apple ID; Google Password Manager requires 2FA on the Google account. If the team's platform accounts are themselves protected by SMS or a shared password, you're stacking a strong lock on a cardboard door. Turn on platform 2FA with an authenticator app first — the MFA-everywhere pass is where that's already written down.
4. Pilot with two or three people on one real system. Not the CEO's account — the person who will document what broke. Register the passkey, log out, log back in on a second device, then remove the second device's network and log in again. The pilot's output is a one-page note: what worked, what the vendor's recovery actually does, how long a lockout took to resolve.
5. Remove the password last, and only per person. The transition state is passkey plus password-plus-TOTP, for a defined window. Once a person has lived on the passkey for a couple of weeks, disable their password login if the vendor allows it ("passwordless"), or rotate the password into the vault and freeze it. The password is never removed from the team until every human has a tested second path.
6. Enforce with a date, not a nag. Like every rollout in these notes: a date in the calendar converts "we should all do this" into "done." Pick the date when you finish the pilot; the date is what keeps passkeys from becoming the security project everyone started and nobody finished.

4. The shared-login decision nobody wants to make

• Passkeys are personal by design. A credential lives in one human's platform account. Your shared vendor logins — the ones already living in a shared collection — can't become passkeys without breaking the sharing model, and pretending otherwise is how a team ends up with three people registered on one account and no idea who can still get in.
• Write the decision down per tool. For each shared login, choose: keep the shared password in the vault (fine for low-value tools), or promote the account to individually-licensed seats with personal passkeys (right for anything that touches money or customer data). An undocumented shared login after a passkey rollout is an offboarding landmine: the departure checklist says "revoke their access," but the access was never theirs.

5. Monday-morning runbook: someone is locked out

1. Establish which path died. Device lost? Platform sync broken (Apple ID or Google account issue)? Vendor wiped credentials after a security event? The fix is different for each, and guessing burns your one cool-headed hour. Same opening move as any incident: measure before you change.
2. Recovery ladder, in order. (1) Second synced device — iCloud and Google both offer "sign in with the passkey on your other device" via QR code. (2) The vendor's own recovery flow — this is where you discover it's an email code, which makes the mailbox the new crown jewel (see the mail-stopped-arriving runbook if that is what failed). (3) The break-glass admin account from step one — admin console, user, "reset credentials," then the person re-registers on a healthy device.
3. After recovery, close the gap that made it possible. If the lockout happened because one human held the only credential, register the second path the same day. If it happened because a vendor's recovery falls back to SMS, fix the fallback or move the vendor down a tier in the next vendor review.

6. Offboarding is where passkeys bite

• A departing person's passkeys die with their platform account. That's good news if they were the only registered human on an account — except when the account also holds the recovery phone or the billing card. The offboarding checklist needs one new line: "for each shared/vendor account, list every registered passkey holder; there must be at least two, and neither may be leaving today."
• Admins: revoke passkeys, not just passwords. A password reset doesn't remove a passkey the departed employee registered from their personal laptop. On offboarding day, an admin clears the person's passkeys in each vendor console — thirty seconds per tool, and the only part of the process that actually cuts the cord.

7. Keep it from drifting back

• One passkey question in every vendor review. "Do you support passkeys, and what does your recovery flow fall back to?" goes into the standing vendor security review. The answer changes over time; the review is where the change gets noticed.
• Quarterly: two live paths per critical account. Ten-minute pass: for each account on the critical list, confirm two humans (or one human plus break-glass) can currently authenticate. Dead credentials get pruned with the same discipline as the secrets rotation — a stale passkey on a departed employee's laptop is a live credential you forgot you owned.
• New-tool gate. The same line as every rollout: no new critical tool goes live without its login model decided — passkey where supported, TOTP where not, and the recovery path tested before the first real customer data lands in it.

The whole discipline fits one line: a passkey rollout is a recovery-path rollout that happens to remove passwords along the way. Register the second path before the first, keep one account no vendor can lock you out of, and the phishing-resistant future arrives without a single 2am rescue mission.