Passkeys at National Scale: 300,000 Adopters in 30 Days

Scope

This guide explores the technical and operational steps for integrating passkey authentication into enterprise IAM systems, inspired by the UK Government Digital Service's rollout to 23 million users. You'll find insights on requirements, implementation strategies, and cost analysis for organizations considering passwordless authentication.

This isn't a passkey primer. If you need FIDO2 protocol basics, start with the FIDO Alliance technical specifications. This guide assumes you understand public-key cryptography and are evaluating passkeys for your authentication stack.

Key Concepts

Passkey: A FIDO2 credential with a private key (stored in device hardware or OS credential manager) and a public key (registered with your identity provider). Users authenticate by proving possession of the private key via biometric or device unlock.

Phishing-Resistant Authentication: Methods that cryptographically bind the credential to the origin domain. Passkeys qualify because the private key only responds to challenges from the registered relying party.

Credential Manager: Secure storage for passkey private keys at the OS or browser level. Examples include iCloud Keychain, Windows Hello, and Google Password Manager.

Relying Party: Your identity provider or application that verifies passkey authentication attempts. In OAuth 2.0 flows, this is typically your authorization server.

Requirements Breakdown

Protocol Requirements

Your identity provider must support the WebAuthn API (part of FIDO2). Specifically:

• Registration flow: Generate a challenge, receive the authenticator's public key and attestation, verify the attestation signature, store the credential ID and public key.
• Authentication flow: Generate a challenge, receive the signed assertion, verify the signature against the stored public key.
• Credential management: Allow users to view, rename, and revoke registered passkeys.

Client Requirements

Users need:

• A device with biometric capability (fingerprint, face recognition) or secure PIN.
• An OS that supports platform authenticators (iOS 16+, Android 9+, Windows 10 1903+, macOS Ventura+).
• A browser that implements WebAuthn (Chrome 67+, Safari 13+, Firefox 60+, Edge 18+).

Infrastructure Requirements

Your IAM architecture needs:

• TLS 1.2 or higher on all authentication endpoints.
• Session management that handles passkey authentication alongside existing methods during transition.
• Audit logging that captures credential registration, authentication attempts, and revocation events.
• Account recovery workflows that don't undermine passkey security (avoid SMS fallback).

Implementation Guidance

Phase 1: Parallel Deployment

Don't force passkey adoption. The GDS rollout reached 300,000 users in the first month by making passkeys optional. Your implementation should:

1. Add passkey registration to account settings without removing password authentication.
2. Prompt users at next login with a dismissible offer to set up a passkey.
3. Track adoption metrics (registration rate, authentication success rate, support ticket volume).

Your session broker needs to handle multiple credential types simultaneously. A user might authenticate with a passkey on their phone but still have a valid password for desktop access.

Phase 2: Cost Analysis

The UK government expects to save millions annually by reducing SMS-based One-Time Password delivery. Build your own cost model:

Current state costs:

• SMS delivery fees per authentication (typically $0.01-0.05 per message).
• Password reset support tickets (average handle time × hourly support cost).
• Account lockout incidents (user productivity loss + IT intervention).

Passkey state costs:

• Initial implementation (WebAuthn integration, testing, documentation).
• Device registration support (first-month spike, then minimal).
• Credential recovery process (should be rare if implemented correctly).

Most enterprises see positive ROI within 12-18 months if SMS OTP volume exceeds 100,000 monthly authentications.

Phase 3: Hardening

Once adoption reaches 30-40%, consider:

Requiring passkeys for high-risk operations: Financial transactions, privileged access elevation, or sensitive data access might require passkey authentication regardless of how the user initially signed in.

Sunsetting legacy MFA: If you're maintaining HMAC-Based One-Time Password tokens or SMS codes purely for backward compatibility, set a deprecation timeline once passkey coverage reaches your threshold.

Syncing across devices: Users expect credentials to work on their phone and laptop. Apple's iCloud Keychain, Google Password Manager, and third-party password managers now sync passkeys. Document which sync methods you'll support.

Common Pitfalls

Account Recovery Undermines Security

If your account recovery flow allows SMS-based password reset, you haven't eliminated phishing risk. An attacker who compromises the user's phone number can still take over the account.

Better approach: Require users to register multiple passkeys (phone + laptop, or primary + hardware security key). Recovery requires possession of any registered passkey.

Assuming Universal Device Support

Not every user has a compatible device. Your workforce might include:

• Contractors on older corporate laptops without TPM 2.0.
• Field workers with basic Android phones.
• Users who disable biometrics for privacy reasons.

Keep a phishing-resistant fallback. Multi-Factor Cryptographic Devices (hardware security keys) work on any device with USB or NFC.

Ignoring Cross-Platform Scenarios

A user registers a passkey on their iPhone. They try to sign in on a Windows desktop. What happens?

Option 1: The desktop browser prompts them to scan a QR code with their phone, which completes authentication via Bluetooth.

Option 2: They register a second passkey on the desktop.

Both work, but users find Option 2 confusing. Your registration flow should explain that passkeys are device-specific unless using a syncing credential manager.

Treating Passkeys as Single-Factor

Passkeys combine "something you have" (the device) and "something you are" (biometric) or "something you know" (device PIN). But if your risk model requires separate factors, you might still need an additional authentication step for privileged operations.

The National Cyber Security Centre recommends passkeys "wherever possible," but that doesn't mean every authentication decision carries the same risk weight. Just-in-Time Elevation for production access might still warrant a second factor.

Quick Reference

Decision Point	Recommendation	Rationale
Minimum browser versions	Chrome 67+, Safari 13+, Firefox 60+, Edge 18+	Earlier versions lack stable WebAuthn support
Attestation verification	Optional for most enterprises	Required only if you need to restrict specific authenticator models
Credential storage	Let users choose their credential manager	Forcing a specific manager reduces adoption
Registration limit	5-10 passkeys per user	Prevents abuse while allowing multiple devices
Session lifetime	Match your existing policy	Passkeys don't change session risk
Fallback authentication	Hardware security key or recovery passkey	Never fall back to SMS
Adoption target	40% in first year	Based on GDS reaching 10% in first month
Support documentation	Device-specific setup guides	Users need screenshots for their specific OS

Standards Reference

• FIDO2: Umbrella term for WebAuthn (browser API) and CTAP2 (authenticator protocol).
• WebAuthn Level 2: W3C Recommendation published April 2021.
• CTAP 2.1: FIDO Client to Authenticator Protocol, adds PIN protection and credential management.

Integration Checkpoints

Before production rollout:

• WebAuthn registration completes successfully on iOS, Android, Windows, macOS.
• Authentication works with platform authenticators and hardware security keys.
• Users can view and revoke registered passkeys.
• Audit logs capture credential lifecycle events.
• Account recovery doesn't bypass passkey requirement.
• Support team has device-specific troubleshooting guides.
• Cost tracking measures SMS OTP reduction.

The UK government's deployment proves passkeys work at national scale. Your implementation timeline depends on your existing IAM maturity and user device landscape, not on the protocol's readiness.