← Patterns / SP-033

Passkey Authentication

Passkey Authentication represents the most significant shift in authentication since the introduction of passwords. Built on the FIDO2 standard -- which comprises the WebAuthn browser API and the CTAP2 client-to-authenticator protocol -- passkeys replace shared secrets (passwords) with public key cryptography. The user's private key never leaves the authenticator device, eliminating the entire class of credential theft attacks that dominate the threat landscape. The core mechanism is simple. During registration, the authenticator generates a unique public-private key pair bound to the relying party's origin. The public key is sent to the server. The private key stays on the device, protected by the authenticator's secure element (TPM, Secure Enclave, hardware key). During authentication, the server sends a challenge, the authenticator signs it with the private key after local user verification (biometric or PIN), and the server verifies the signature against the stored public key. No shared secret ever crosses the network. Three authenticator types serve different use cases. Platform authenticators are built into the device -- Touch ID, Face ID, Windows Hello, Android biometrics -- offering frictionless authentication on that specific device. Roaming authenticators are external hardware keys (YubiKey, Titan, SoloKeys) that work across devices via USB, NFC, or Bluetooth, providing the highest assurance for privileged access. Synced passkeys (sometimes called multi-device credentials) synchronise private keys across a user's devices through the platform vendor's cloud (iCloud Keychain, Google Password Manager, Windows Hello) -- they sacrifice the hardware-binding property of device-bound credentials but dramatically improve usability by eliminating the per-device registration requirement. For enterprise deployment, the security decision is which authenticator types to permit for which access levels. Device-bound passkeys (platform authenticators that do not sync, and hardware security keys) provide the highest assurance and are appropriate for privileged access, financial transactions, and high-classification data. Synced passkeys provide excellent phishing resistance with much better usability and are appropriate for the majority of workforce authentication. The pattern provides guidance for tiered authenticator policies, migration from password-based authentication, and integration with enterprise identity providers.

Release: 26.02 Authors: Aurelius, Vitruvius Updated: 2026-02-07

Assess

ATT&CK This pattern addresses 443 techniques across 13 tactics View on ATT&CK Matrix →

Click any control badge to view its details. Download SVG

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.

Related Patterns

Patterns that operate within or alongside this one. Click any to view.

SP-010 Identity Management SP-029 Zero Trust Architecture SP-032 Modern Authentication

AC: 6AT: 1AU: 4CA: 1CM: 1CP: 1IA: 5PL: 1PM: 1SA: 1SC: 4SI: 1

AC-01 Policy and Procedures

AC-03 Access Enforcement

AC-06 Least Privilege

AC-07 Unsuccessful Logon Attempts

AC-12 Session Termination

AC-14 Permitted Actions Without Identification or Authentication

AT-02 Literacy Training and Awareness

AU-02 Event Logging

AU-03 Content of Audit Records

AU-06 Audit Record Review, Analysis, and Reporting

AU-09 Protection of Audit Information

CA-02 Control Assessments

CM-06 Configuration Settings

CP-02 Contingency Plan

IA-02 Identification and Authentication (Organizational Users)

IA-04 Identifier Management

IA-05 Authenticator Management

IA-06 Authentication Feedback

IA-12 Identity Proofing

PL-02 System Security and Privacy Plans

PM-12 Insider Threat Program

SA-08 Security and Privacy Engineering Principles

SC-08 Transmission Confidentiality and Integrity

SC-12 Cryptographic Key Establishment and Management

SC-13 Cryptographic Protection

SC-17 Public Key Infrastructure Certificates

SC-23 Session Authenticity

SI-07 Software, Firmware, and Information Integrity