Passkey Authentication

Key Control Areas

• Authenticator Credential Management (IA-05, IA-04, IA-02, IA-06): Passkey credential lifecycle requires careful management. IA-05 governs the full authenticator lifecycle: initial registration (binding a credential to a verified identity), credential metadata management (tracking which authenticators are registered, their type, last use, and attestation data), rotation (registering new credentials and revoking old ones), and revocation (removing credentials when devices are lost, compromised, or decommissioned). IA-04 manages the identifiers associated with passkey credentials: the credential ID is a unique handle per relying-party/authenticator combination, and the user handle links credentials to the user account without exposing personally identifiable information. IA-02 defines the authentication policy: which user verification methods are acceptable (biometric, PIN, presence-only), whether user verification is required or preferred, and which authenticator types satisfy which assurance levels. IA-06 governs authentication feedback: the system must not reveal whether a credential ID exists during authentication (preventing enumeration), and error messages must be generic. Implementation requires a credential management interface where users can register multiple passkeys, view registered credentials, and revoke lost devices -- with a secure recovery path when all credentials are lost.
• Cryptographic Assurance and Key Protection (SC-12, SC-13, SC-17, SI-07): The security of passkeys rests entirely on the cryptographic implementation. SC-12 governs key generation and management: authenticators must generate key pairs using approved random number generators within their secure element, and private keys must never be exportable (for device-bound credentials) or must be protected by platform encryption (for synced credentials). SC-13 mandates approved cryptographic algorithms: WebAuthn supports ES256 (ECDSA with P-256) and RS256 (RSASSA-PKCS1-v1_5 with SHA-256); ES256 is preferred for its compact key size and strong security properties. SC-17 addresses the certificate infrastructure: FIDO attestation certificates chain to the authenticator manufacturer's root certificate, enabling the relying party to verify the authenticator model and its security properties during registration. SI-07 verifies software and firmware integrity of authenticators: FIDO Metadata Service (MDS) publishes security status for certified authenticators, including revocation of models with known vulnerabilities. Enterprises should consume MDS data to automatically adjust policy when authenticator vulnerabilities are discovered.
• Registration and Ceremony Security (IA-12, IA-02, SC-23, AC-03): The registration ceremony is the critical trust establishment point. IA-12 requires identity proofing before credential registration: the user must prove their identity through an existing strong authentication method (or in-person verification for initial enrollment) before registering a passkey. If registration security is weak, attackers can register their own credentials to legitimate accounts. IA-02 defines the user verification requirement during registration: 'required' ensures biometric or PIN verification on the authenticator, establishing that the person registering is physically present. SC-23 protects the registration ceremony from replay and interception: the challenge is a cryptographic nonce with a short validity window, and the attestation response is bound to the specific origin (scheme + host + port), preventing registration on phishing sites. AC-03 enforces access control on the registration endpoint: only authenticated users can register new credentials, registration rate limits prevent credential stuffing of the registration flow, and administrative controls allow security teams to register credentials on behalf of users during onboarding. Attestation verification during registration enables the relying party to enforce authenticator type policies: accept only FIDO2 Certified authenticators, require specific authenticator models for privileged access, or distinguish between device-bound and synced credentials.
• Authentication Ceremony and Phishing Resistance (SC-23, SC-08, IA-02, AC-07): The authentication ceremony provides cryptographic phishing resistance. SC-23 ensures session authenticity through the WebAuthn protocol: the authenticator signs the challenge along with the relying party ID (derived from the origin), the client data hash (including the origin URL), and a signature counter. If a user is tricked into visiting a phishing site (attacker.com instead of bank.com), the authenticator signs a challenge bound to attacker.com's origin, which the legitimate server rejects because the origin does not match. This is the fundamental advantage over passwords and OTP codes, which are origin-agnostic and can be phished and replayed. SC-08 protects the authentication flow with TLS, though WebAuthn's origin binding provides an additional layer even if TLS were compromised. IA-02 defines acceptable user verification: biometric verification provides continuous assurance of user presence, while PIN verification is a fallback. AC-07 handles failed authentication: signature verification failures, user verification failures, and credential not found errors must be rate-limited and logged. The signature counter incremented by the authenticator on each use enables detection of cloned credentials (if the counter value received is less than or equal to the stored value, the credential may have been cloned).
• Enterprise Policy and Tiered Access (AC-01, AC-06, CM-06, PL-02, PM-12): Enterprise deployments require policy granularity. AC-01 defines the passkey policy: which authenticator types are accepted (platform, roaming, synced), minimum authenticator assurance level per resource sensitivity, attestation requirements, and user verification requirements. AC-06 implements tiered access through authenticator strength: standard workforce access may accept any passkey type, but privileged access management requires device-bound credentials (hardware security keys or non-synced platform authenticators). CM-06 enforces configuration settings on managed devices: ensuring platform authenticators are enabled, secure element is available, and biometric enrollment is completed. PL-02 documents the passkey deployment plan: phased rollout starting with IT and security teams, progressive enrollment campaigns, and timeline for password deprecation. PM-12 ensures the insider threat programme accounts for passkey-specific risks: synced credentials accessible from personal devices, registered credentials surviving offboarding if not revoked. Enterprise policy should distinguish between three tiers: Tier 1 (standard access) accepts all FIDO2 authenticator types including synced passkeys; Tier 2 (elevated access) requires device-bound credentials with user verification; Tier 3 (privileged access) requires hardware security keys with attestation verification.
• Recovery and Fallback Mechanisms (IA-05, CP-02, IA-12, AC-14): Recovery from credential loss is the hardest problem in passwordless authentication. IA-05 mandates backup authenticator registration: users must register at least two credentials on different devices or authenticator types, ensuring that loss of a single device does not lock the user out. CP-02 includes passkey recovery in the contingency plan: what happens when a user loses all registered devices, how temporary access is granted during recovery, and how identity is re-verified before registering new credentials. IA-12 applies identity proofing to recovery: the recovery process must verify the user's identity with assurance equivalent to initial enrollment -- otherwise recovery becomes the weakest link that attackers target. AC-14 defines permitted actions without authentication during recovery transitions: the organisation may maintain a sealed recovery process (e.g., supervisor-verified in-person re-enrollment) that does not rely on any digital credential. Common anti-patterns to avoid: recovery via email/SMS OTP (downgrades to phishable factor), recovery codes stored by the user (reverts to shared secret), and self-service recovery without identity verification (enables account takeover).
• Audit and Compliance (AU-02, AU-03, AU-06, CA-02): Passkey operations must be comprehensively audited. AU-02 defines auditable events: credential registration (including authenticator type, attestation, user verification method), successful and failed authentications (including signature counter values), credential revocation, recovery operations, and policy changes. AU-03 specifies record content: credential ID (never the private key), authenticator AAGUID (identifying the model), attestation trust path, user verification method used, signature counter, client origin, and IP address. AU-06 analyses passkey-specific anomalies: signature counter regression (potential credential cloning), registration from unexpected locations, rapid credential registration across many accounts (potential bulk attack), and authentication from authenticators that should have been revoked. CA-02 assesses the passkey deployment: testing that attestation verification is working, that revoked credentials are truly denied, that recovery processes maintain assurance level, and that tier policies are enforced correctly.

When to Use

This pattern is indicated for any organisation seeking to eliminate phishing as a viable attack vector against their users. It is particularly relevant for: financial services organisations facing sophisticated phishing campaigns, organisations subject to regulatory requirements for phishing-resistant MFA (US Executive Order 14028, PCI DSS v4.0 requirement 8.4.2), organisations with high-value accounts requiring strong authentication (administrators, executives, developers with production access), consumer-facing services wanting to improve authentication UX while strengthening security, and organisations already deploying FIDO2 hardware keys that want to extend passwordless authentication to the broader workforce via synced passkeys.

When NOT to Use

Organisations whose user base primarily uses devices that do not support WebAuthn (legacy browsers, very old operating systems) cannot deploy passkeys without first upgrading the device estate. Environments requiring authentication from shared or kiosk devices where biometric enrollment is impractical may need alternative approaches (though roaming authenticators work in this scenario). Organisations that require credential escrow or recovery through the IdP alone (without any user-side component) face challenges with the decentralised nature of passkey storage. If the threat model requires that no credential material ever leaves a certified hardware boundary, synced passkeys are inappropriate and only device-bound credentials (hardware keys, non-synced platform authenticators) should be used.

Typical Challenges

The biggest challenge is the transition period: organisations cannot simply switch off passwords overnight, so they run dual authentication paths (passwords and passkeys) for months or years, during which the password path remains the weakest link. Synced passkeys create a new dependency on platform vendors (Apple, Google, Microsoft) for key synchronisation security and availability. Enterprise use of synced passkeys means credentials may reside on personal devices, complicating offboarding -- credential revocation at the relying party is essential but does not remove the synced credential from the user's device. Hardware security key deployment at scale requires logistics: procurement, distribution, replacement for lost keys, and user training. Some legacy enterprise applications cannot integrate WebAuthn and require proxy-based solutions. Users with accessibility needs may struggle with biometric verification; PIN-based user verification must be available as an alternative. Cross-platform passkey synchronisation between Apple and Google ecosystems is improving but not seamless. Attestation verification is operationally complex: maintaining trust stores, consuming FIDO MDS updates, and handling authenticators that do not provide attestation.

Threat Resistance

Passkey Authentication provides the strongest available protection against credential-based attacks. Phishing attacks are cryptographically defeated: the authenticator binds the assertion to the relying party's origin, so credentials cannot be replayed on a different site even if the user is tricked into interacting with a phishing page (SC-23, IA-02). Credential stuffing and password spraying are eliminated: there are no passwords to stuff or spray (IA-05). Man-in-the-middle attacks are prevented: even if an attacker intercepts the authentication flow, they cannot forge the authenticator's signature (SC-13, SC-08). Credential theft from server breaches is neutralised: servers store only public keys, which are useless to attackers (SC-12). SIM swapping attacks that compromise SMS MFA are irrelevant: passkeys do not rely on phone numbers (IA-05). Push notification fatigue attacks (MFA bombing) are eliminated: passkeys require local user verification, not remote approval (IA-02). Credential cloning is detectable through signature counter validation for device-bound credentials and is prevented by secure element hardware for certified authenticators (SI-07). The remaining attack surface is primarily social engineering of the recovery process and compromise of the platform sync mechanism for synced passkeys.

Assumptions

Applications support the WebAuthn API (all major browsers have supported it since 2019). Users have devices with platform authenticators (Touch ID, Face ID, Windows Hello, Android biometrics) or the organisation provides hardware security keys. The Identity Provider supports FIDO2/WebAuthn as an authentication method. User devices are running sufficiently recent operating systems to support passkeys (iOS 16+, Android 9+, macOS Ventura+, Windows 10 build 1903+). The organisation has a credential management interface or can build one. A recovery process exists for users who lose all registered credentials.

Developing Areas

• Cross-platform passkey synchronisation security remains a significant trust question. Apple iCloud Keychain, Google Password Manager, and Microsoft Windows Hello each implement different sync encryption models, key escrow mechanisms, and recovery paths. No independent audit of these sync mechanisms has been published, and enterprises must trust platform vendor security claims without the ability to verify the cryptographic guarantees around synced credential material.
• Enterprise passkey provisioning at scale lacks mature tooling. Onboarding thousands of users to passkeys requires coordinated registration campaigns, helpdesk support for edge cases, and integration with identity governance platforms that were designed for password lifecycle management. Fewer than 10% of enterprise IdPs offer automated passkey enrollment workflows, forcing organisations into manual or semi-automated processes.
• Account recovery when all passkeys are lost is the unsolved hard problem of passwordless authentication. Current approaches -- recovery codes (revert to shared secrets), email-based recovery (downgrade to phishable factor), or in-person re-enrollment (does not scale) -- each undermine the security model in different ways. The FIDO Alliance is exploring social recovery and delegated recovery protocols, but no standardised solution has reached production maturity.
• Passkey adoption rates vary dramatically by sector. Consumer services with young, mobile-first user bases report 30-50% passkey registration rates within months of launch, while regulated enterprises in financial services and healthcare see single-digit adoption due to legacy device estates, accessibility requirements, and conservative change management. Bridging this gap requires sector-specific deployment strategies that current vendor guidance does not adequately address.
• The attestation trust model adds operational complexity that most organisations underestimate. Maintaining FIDO Metadata Service (MDS) trust stores, interpreting attestation certificates, and making policy decisions based on authenticator security properties requires cryptographic expertise that security teams typically lack. The distinction between basic, self, and attCA attestation types, combined with the growing diversity of authenticator models, creates a trust evaluation problem that has no simple tooling solution.