DEV Community

Hive80-lab
Hive80-lab

Posted on Originally published at hive80-lab.github.io

The passkey rollout that doesn’t lock anyone out: break-glass first, password last

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 exact domain, and a fake login page has nothing to steal. That part of the pitch is 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 was 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. Here is the rollout order that keeps every step safe even if the project dies there.

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,
  • TOTP codes from an authenticator whose backup lives in that vault,
  • two hardware keys where the vendor allows it — one in a safe, one off-site.

Then test logging in with it, the same day. If this account can't get you into every critical SaaS, fix that before registering anything else.

2. Inventory vendor support — it's wildly uneven

Three columns, tool by tool:

  1. Passkeys fully supported → your rollout list.
  2. Passkey, but recovery falls back to SMS to a phone number nobody updated since 2021 → fix the fallback first.
  3. Password + TOTP only → keep TOTP. Still a big step up from a reused password.

Treating passkeys as one big switch is the mistake. They're a per-vendor change.

3. Fix the platform substrate before registering anything

iCloud Keychain sync requires 2FA on the Apple ID. Google Password Manager requires 2FA on the Google account. If the team's platform accounts are protected by SMS or a shared password, you've built a strong lock on a cardboard door.

4. Pilot with 2–3 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 kill the network on that device and log in again. The pilot's output is one page: what worked, what the vendor's recovery actually does, how long the lockout took.

5. Remove the password LAST, per person

Transition state: passkey plus password+TOTP, for a defined window. Once a person has lived on the passkey for a couple of weeks, go passwordless on that vendor — or rotate the password into the vault and freeze it. No password is removed team-wide until every human has a tested second path.

Then enforce with a date, not a nag. A date in the calendar converts "we should all do this" into "done."

The two decisions nobody wants to make

Shared logins. Passkeys are personal by design — the credential lives in one human's platform account. Your shared vendor logins can't become passkeys without breaking the sharing model. Write down, per tool: keep the shared password in the vault (fine for low-value tools), or promote to individually-licensed seats with personal passkeys (right for anything touching money or customer data).

Offboarding. A departing person's passkeys die with their platform account — good — except when that account 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." And admins: revoke passkeys, not just passwords — a password reset doesn't remove a passkey someone registered from their personal laptop.

Monday-morning runbook: someone is locked out

  1. Establish which path died: device lost, platform sync broken, or vendor wiped credentials. Guessing burns your one cool-headed hour.
  2. Recovery ladder, in order: (1) second synced device via QR, (2) the vendor's recovery flow — this is where you discover it's an email code and the mailbox becomes the crown jewel, (3) the break-glass admin account → console → "reset credentials" → re-register on a healthy device.
  3. Close the gap that made the lockout possible: same day.

The whole discipline fits one line: a passkey rollout is a recovery-path rollout that happens to remove passwords along the way.

I wrote the full version as a free page on our ops-notes site — including the per-vendor support inventory and the drift-prevention pass (one passkey question in every vendor review, quarterly two-live-paths check):

👉 Passkeys for Small Teams: A Rollout That Doesn't Lock Anyone Out

If you want the fill-in-the-blanks version of the surrounding discipline, that's what the HIVE80lab kit is for:

  • The First 30 Minutes — free one-page incident quick-start
  • Ops Starter Kit — $14, fillable incident response plan
  • Launch week: 30% off any paid kit with code HIVE-LAUNCH30

No signup, no email wall. Just notes that work at 2AM.

Top comments (0)