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 todays 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. The point of this post is treating passkey rollout as an identity project, not as a new button on the login page.

Technically, a passkey is a WebAuthn keypair (typically ES256 or EdDSA) bound to an origin. The private key lives in an authenticator: Secure Enclave on iPhone, TPM 2.0 in Windows Hello, StrongBox on Android, or an external token like a YubiKey 5C NFC. The server only stores the public key and credentialId. Classic phishing fails because the signature is tied to the RP ID (domain). In tests against evilginx2 clones, a passkey simply refuses to sign for the wrong domain, while TOTP falls 100% of the time behind a reverse proxy. Practical setup in Web Pentesting From Scratch: Building a Safe Lab with DVWA, Juice Shop and Burp Suite and adversarial context in Authorized Red Team Phishing: Templates, GoPhish and Ethical Guardrails.

The real risk is not the protocol, it is recovery. Map how your provider (Apple iCloud Keychain, Google Password Manager, 1Password, Bitwarden) syncs credentials and what the restore ceremony looks like. Apple requires the device passcode plus a recovery contact or a 28-character recovery key. Google relies on the previous devices screen lock. If you disable SMS and email fallback without configuring that path, you are done. 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.

For corporate teams, my rule is two physical authenticators per critical user (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. Disable self-service enrollment without review for admin groups. For personal researcher accounts, pair a synced passkey (convenience) with a physical security key (resilience). The workstation playbook in Windows 11 Hardening for High-Risk Offensive Security Workstations covers the endpoint side, and macOS Hardening: Lockdown Mode, MDM and Attack Surface Reduction the Apple equivalent.

Helpdesk is 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 shifts but does not disappear, it becomes passkey reset. Mandate out-of-band verification: video call with ID, or manager approval through a separate channel. Log every reset op with 1-year retention and a SIEM alert. If you run Sigma, write a rule for credential reset outside business hours followed by login from new geo - concrete example in Threat Hunting with Sigma and Elastic: From Indicator to Detection Rule and broader hunting patterns in Hunting Living-off-the-Land Binaries on Windows with KQL.

Does the password go away? 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 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 I see in audits: 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 - 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, 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.

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.