Overview
Passkeys can make ordinary WebAuthn login resistant to phishing and replay without exposing a reusable password, but account security extends beyond that ceremony. Binding additional authenticators, synchronization, loss reporting, fallback, recovery, delegated identity, notification, and invalidation move control across multiple owners. This series shows how to compare those paths, distinguish availability from assurance, and state observed, inferred, and unknown findings without treating a strong front door as proof that the whole account is controlled.
Learning outcomes
- Passkeys can make normal login resistant to phishing and replay, but that protection is bounded by the ceremony.
- Binding, syncing, recovering, and invalidating authenticators determine whether account control continues after device loss.
- A second authenticator or recovery method can improve availability without matching the original passkey’s assurance.
- Native and delegated paths have different control owners, so findings must separate observed facts, inferences, and unknowns.
Keywords
Preview every chapter · Unlock full text, audio, and video from chapter 4
PlansFAQ
What does a passkey protect?
A passkey protects the normal login with a fresh, relying-party-bound cryptographic assertion instead of a reusable password. That ceremony does not by itself secure recovery, fallback, or replacement binding.
Does a passkey secure account recovery?
No; the passkey ceremony does not by itself show that recovery, fallback, or replacement binding has the same protections. Those are separate account-control decisions with their own evidence and failure modes.
What changes when a passkey is synchronized?
A synchronized passkey can preserve the normal challenge-and-verifier-bound login while expanding the trust boundary to the sync fabric, its access controls, recovery, and receiving devices. NIST treats the resulting key as exportable, so it cannot satisfy AAL3’s non-exportability requirement.
How should a whole-account passkey audit begin?
A whole-account audit should trace every route that can authenticate, add an authenticator, recover access, or keep an old credential active. It should then identify each control owner, compare the evidence and authority of each path, and label facts, inferences, and unknowns accurately.