Passwords and MFA: Moving to Passkeys Without Breaking Your Recovery

The first time a client called me at 11pm because their CFO had dropped his iPhone in a pool and lost access to everything, it became obvious that passkeys without a recovery plan are just an elegant way to lock yourself out. Passkeys solve the right problem: they kill password reuse, reverse phishing and most of the MFA fatigue that drives today's incidents. But a sloppy rollout creates a brand new incident class: legitimate user locked out, no trustworthy reset channel, helpdesk turned into a social engineering vector. This post treats passkey rollout as an identity project, not a new button on the login page, and walks the chain protocol, recovery, team enrollment, helpdesk, detection and checklist in the order it actually breaks in production.

What a passkey technically is

A passkey is a WebAuthn/FIDO2 keypair, typically ES256 (P-256) or EdDSA (Ed25519), generated at registration and bound to an origin. The private key never leaves the authenticator: Secure Enclave on iPhone, TPM 2.0 behind Windows Hello, StrongBox on Android, or an external token like a YubiKey 5C NFC. The server (the relying party) stores only the public key, the credentialId and a signature counter. At login the server sends a random challenge, the authenticator signs it after a user-presence or user-verification gesture, and the server verifies the signature against the stored public key. There is no shared secret to phish, leak from a database, or capture through a reverse proxy.

Why phishing fails at the protocol level

The decisive value is the binding to the RP ID (the registered domain). The browser only signs when the calling origin matches the registered RP ID, and the signature covers a clientDataHash over origin and challenge. In tests against an evilginx2 clone, the passkey simply refuses to sign for the wrong domain, while TOTP is proxied through 100% of the time because the user willingly types the code into a look-alike page. You reproduce that attacker viewpoint in a lab as in Authorized Red Team Phishing: Templates, GoPhish and Ethical Guardrails, with the general web setup in Web Pentesting From Scratch: Building a Safe Lab with DVWA, Juice Shop and Burp Suite.

The real risk: recovery, not the protocol

Map how your provider syncs credentials and what the restore ceremony looks like. Apple iCloud Keychain requires the device passcode plus a recovery contact or a 28-character recovery key. Google Password Manager relies on the previous device's screen lock. Password managers like 1Password and Bitwarden sync the passkey through your vault, whose master secret then becomes the real crown jewel. The mistake that locks people out: disabling SMS and email fallback without configuring the new path first. Document the flow in a personal threat model before migrating; OPSEC for Security Researchers: Building a Personal Threat Model has the skeleton I use with high-risk clients and journalists.

Synced vs device-bound: the wrong debate

A synced passkey is convenient and survives device loss because it lives in the provider's cloud; its security is exactly as good as that provider's account recovery. A device-bound passkey (hardware token, or a platform key with no sync) never leaves the silicon and survives no lost device without a second copy. The mature answer is not either/or: for personal researcher accounts, pair a synced passkey for convenience with a physical security key for resilience. Never confuse a synced passkey with a hardware-bound one in your inventory - the attestation returned during registration tells you what you actually hold.

Team rollout: two authenticators, hard policy

My rule for critical users: two physical authenticators (e.g. YubiKey 5C plus YubiKey 5 Nano), enrolled on the same day, one stored in a physical safe. On IdPs like Entra ID, Okta or Google Workspace, set attestation policy to require FIDO2 L1+ certified authenticators for privileged accounts, and disable self-service enrollment without review for admin groups. Enforce user verification (userVerification: required), not just user presence. The workstation playbook in Windows 11 Hardening for High-Risk Offensive Security Workstations covers the endpoint, and macOS Hardening: Lockdown Mode, MDM and Attack Surface Reduction the Apple equivalent.

The helpdesk vector: where 80% of bypasses happen

MGM, Caesars and Cloudflare have all documented the same pattern: attacker calls, fakes lost device, helpdesk resets MFA. With passkeys the vector does not disappear, it becomes passkey reset. Mandate out-of-band verification: video call with ID, or manager approval through a separate, pre-defined channel - never the same channel the request came from. Add a delay for high-risk resets and notify the real account owner over a second wire before the reset takes effect. Every reset operation is logged, with 1-year retention and a SIEM alert.

Detection: reset anomalies in Sigma

A reset outside business hours followed by a login from a new geo within minutes is a plaintext signal. If you run Sigma, write a rule for credential/authenticator reset followed by login from a divergent ASN or an impossible-travel time delta. Concrete example in Threat Hunting with Sigma and Elastic: From Indicator to Detection Rule, and complementary post-access hunting patterns in Hunting Living-off-the-Land Binaries on Windows with KQL. Alert on enrollment of a new authenticator shortly after a reset - that is the attacker's classic persistence move.

Killing the password? The phased path

Not so fast. In practice, keep a strong password (>=20 chars, manager-generated) as backup on accounts that do not yet support passkey-only, and disable SMS wherever possible. On accounts that already support it (Google, Microsoft, GitHub, Apple, Cloudflare), flip passkey-only only after a 30-day parallel run. Store printed backup codes in a safe, separate from the authenticators. For disk and password vault crypto, Disk Crypto and Backups: VeraCrypt, LUKS and a Resilient 3-2-1 Strategy shows how to apply 3-2-1 without collapsing into a single copy that becomes a single point of failure.

Common mistakes from audits

The same five keep coming back: 1) global admin with a single passkey on a personal phone; 2) recovery email pointing to an account without MFA; 3) BitLocker recovery key saved in the cloud of the same account you are trying to recover - the perfect loop; 4) helpdesk allowed to disable MFA by ticket without manager sign-off; 5) synced passkey marked as hardware-bound in the inventory. Audit this with a quarterly purple team exercise, the same loop as Purple Team in Practice: Building a Red vs Blue Feedback Loop. On authorized red team engagements, these are the first paths we test after initial access.

Migration checklist

Per critical account, in this order: (a) register two authenticators on different hardware; (b) check the attestation, synced or device-bound; (c) print backup codes and seal them in a safe; (d) run a recovery dry-run without the primary device; (e) remove the SMS fallback; (f) point the recovery email at an account that is itself MFA-protected; (g) document the reset procedure and alert on it in the SIEM. Only when all seven are green is the account truly migrated - not the moment the new login works.

Discoverable credentials and usernameless login

A resident key (discoverable credential) stores the user-handle mapping inside the authenticator itself, so login works with no username typed first: through Conditional UI (WebAuthn autofill) the browser offers the matching passkey directly. It is convenient but has a capacity limit - older YubiKeys store only around 25 resident keys, and a full slot causes silent enrollment failures that are painful to debug during a rollout. On shared or kiosk devices, discoverable credentials are also a privacy risk because a list of accounts becomes visible on the device. Choose deliberately between resident (usernameless) and non-resident (server-side credential) based on the device's threat model, instead of accepting the default.

Cross-device: the hybrid transport over CTAP 2.2

The most common real case - logging into a desktop with the passkey on your phone - runs over the hybrid transport (formerly caBLE): the desktop shows a QR code, the phone scans it and confirms over a BLE proximity check that the two devices are physically close. That proximity requirement is exactly why passkeys cannot be phished remotely the way a phone OTP can. Explicitly test the cross-device flow in your rollout, because it often fails on disabled Bluetooth, restrictive corporate networks, or outdated authenticator apps - and a user who cannot execute the only recovery path is just as locked out as one with no backup.

FAQ: Are passkeys quantum-safe?

No, ES256 and EdDSA are classical elliptic curves and are not safe against a cryptographically relevant quantum computer. In practice this matters less than it sounds: passkeys use challenge-response, so no reusable secret travels the wire to be recorded and cracked later. The FIDO Alliance is already working on PQC attestation and signatures; on the migration side nothing changes for you once authenticator firmware and browsers ship it.

FAQ: What if I lose every device at once?

This is exactly what the sealed envelope is for: printed backup codes plus a third, offline-only hardware key in a safe or bank box solves the total-loss scenario. At the provider level, the recovery contact (Apple) or a business admin reset over verified out-of-band channels is your last way back in. If your only recovery path is SMS to a lost SIM, you do not have recovery, you have the illusion of it.

Conclusion and practical takeaway

Next Friday, open your 5 most critical accounts (primary email, bank, password manager, corporate IdP, domain registrar). For each one, register 2 passkeys on different authenticators, print backup codes, verify you can log in without the primary device, and remove SMS as fallback. Document the recovery procedure in a sealed envelope. If you cannot do that in 90 minutes per account, you are not ready to kill the password yet - and that is fine, it is part of the plan. Passkeys are an enormous security win, but only when the recovery path is taken as seriously as the login itself.