Passkeys Are a Recovery Design Problem
Passkeys strengthen sign-in, but account recovery remains an identity lifecycle and control-plane decision.
TL;DR
Passkeys remove passwords from the primary login path. They do not remove recovery risk. A secure rollout must define backup authenticators, recovery evidence, notifications, and revocation. The article covers the Netics position, the operational boundary, and the implementation checklist. The TL;DR also covers phishing resistance and the Netics checklist.
Phishing resistance is not the whole lifecycle
NIST’s syncable-authenticator guidance [1] describes domain-bound cryptographic authentication while identifying risks around sync access, recovery, and revocation. The strongest login can coexist with a weak recovery path.
Recovery becomes the real credential
A recovery code, help-desk reset, backup device, or identity-proofing flow may become the credential that returns a user to the account. Define who can start recovery, what evidence is required, which assurance level survives, and how old authenticators are revoked.
Multiple authenticators reduce emergency pressure
The FIDO Alliance guidance [2] recommends thinking about multiple authenticators as part of the lifecycle, not as an afterthought.
The Netics checklist
Enroll a second authenticator before making passkeys mandatory. Require stronger authentication to add or remove authenticators. Notify users about recovery events. Test support-led recovery as an attack path.
NIST SP 800-63B-4 [3] is the baseline: authentication assurance includes authenticator management and account recovery.
For an identity architecture review, visit Netics or book a free audit.
Recovery flows are a known social-engineering target
Cryptographic passkey authentication resists phishing by design: the credential is bound to the origin and cannot be typed into a fake site. Help-desk-mediated account recovery has no equivalent binding. A support agent who resets an account after a phone call is authenticating a story, not a credential, and that gap is a well-documented attack pattern independent of how strong the primary login is. Treat recovery approval as its own authentication event, with its own evidence requirements, rather than a fallback path that only exists to route around a lost device.
Passkey portability differs by platform, and that shapes recovery design
A passkey created in Apple’s iCloud Keychain syncs across a user’s Apple devices but does not transfer natively to a Windows or Android device without cross-device sign-in over Bluetooth (the FIDO CTAP2 hybrid transport, the “scan this QR code” flow). Google’s Password Manager and Microsoft’s platform authenticators have their own separate sync boundaries. A user who loses their only synced-platform device, or switches ecosystems entirely, falls outside the sync boundary and lands directly in the recovery path this article describes — recovery design has to treat platform-switching as a normal case, not an edge case. The FIDO Alliance’s own guidance on reducing recovery reliance recommends enrolling at least one authenticator that does not depend on the same account or device ecosystem as the primary passkey, such as a hardware security key, specifically so that platform sync loss and account lockout do not become the same failure.
Revocation is part of the same design problem
A recovery flow that issues a new authenticator without revoking the old one leaves a lost or stolen device still valid. Enrollment and revocation should be the same policy surface, not two separate features built at different times: every recovery event that adds a credential should also force a review of what it is replacing. Log the old authenticator’s last-used timestamp so a security review can tell whether it was actually compromised or simply retired.
Ownership and review questions
Assign ownership for enrollment policy, recovery approval, help-desk procedures, and audit review. Ask which event can create a new authenticator, which evidence is required, who can override a lock, and how the user is notified. Review these answers after organizational changes, because a recovery process that depended on one administrator can become a hidden single point of failure. Include recovery in red-team exercises and measure both abuse resistance and legitimate user recovery.
Decision criteria for leaders
Choose the recovery assurance level from the account’s impact, not from the convenience of the enrollment screen. A consumer application may choose a different recovery balance from a privileged administrator account, but both need an explicit decision. Document acceptable fallback factors, notification channels, waiting periods, and the evidence retained for every reset. Then test the policy with real support staff. If the support team cannot explain why a request is safe, the process is not ready. A successful passkey program is therefore measured across enrollment, daily authentication, recovery, and revocation.
Operating questions
A good implementation must be observable by more than one team. Ask what data is produced, where it is retained, who can change it, and what event triggers a fresh verification. Assign an owner for policy and an owner for operations. Record exceptions with an expiry date, a responsible person, and a reason. Define a recovery path as well: when a control fails, the team should be able to pause, correct, and resume without losing history. This discipline turns a security recommendation into a repeatable procedure. It reduces implicit decisions, makes audits easier, and gives operators a clear signal when the system leaves its documented assumptions.
Handoff notes
Keep decisions and evidence with the relevant release or task. During review, compare the observed result with the declared policy, then improve the procedure instead of hiding the gap. The loop should remain short, understandable, and reusable by the next team. It also provides a concrete starting point for quarterly tests and provider changes.
Final review
Before production, have security and operations review the scenario together. Check limits, alerts, logs, and the recovery plan. A documented decision is better than a broad promise: it states what is guaranteed, what is not, and which action follows when the system leaves its assumptions.