Passkeys at Scale: Architecture & Deployment

The previous chapter made the case for why passwords need to go. This chapter is about how. We are going to get technical, not in an academic, whiteboard sense, but in the way that matters when you face a deployment plan. You need to make real decisions about cryptography, device support, enrollment flows, recovery procedures and integration with your existing identity infrastructure.

If you have ever implemented OAuth or SAML, the conceptual model will feel familiar. If you have not, do not worry. The core ideas are straightforward, and the complexity lives in the edge cases, which is exactly where we will spend our time.

What Passkeys Actually Are

A passkey is a FIDO2 credential built on public-key cryptography. That sounds abstract, so let us make it concrete.

When you register a passkey with a website, your device generates a key pair: a public key and a private key. The public key goes to the server. The private key stays protected on your device, typically in a secure enclave or TPM (trusted platform module): hardware that keeps the key isolated even from the operating system. With synced passkeys, an end-to-end encrypted copy also lives in your platform's credential manager so it can reach your other devices.

When you sign in, the server sends a random challenge. Your device signs that challenge with the private key (after verifying your identity through a biometric or device PIN), and sends the signature back. The server verifies the signature using the public key it stored during registration. If it matches, you are in.

At no point does a secret travel over the network. There is no password, no OTP and no shared secret of any kind. The private key is never sent to the website. The public key is useless without the private key. Even if the server is completely compromised, the attacker gets a list of public keys that cannot be used to impersonate anyone.

How Passkeys Work: The Registration and Authentication Flows

Anyone making architectural decisions needs to understand the two core flows: registration and authentication.

Registration Flow

1. User initiates registration: The user clicks "Create a passkey" in the application.
2. Server generates a challenge: The server creates a random challenge (a cryptographically random byte string) along with relying party information (your domain), user information, and supported algorithm preferences.
3. Browser invokes the authenticator: The browser calls the WebAuthn API (navigator.credentials.create()), which triggers the platform authenticator (Touch ID, Face ID, Windows Hello, or an external security key).
4. User verifies their identity: The user scans their fingerprint, looks at the camera, or enters their device PIN. This unlocks the secure enclave.
5. Authenticator creates a key pair: A new public-private key pair is generated. The private key is stored in the secure enclave, bound to the relying party's origin (domain).
6. Authenticator returns the attestation: The public key, a credential ID and an attestation object are returned to the browser. Attestation can prove the make and model of the authenticator, though most consumer passkeys return none.
7. Browser sends to server: The browser forwards this data to the server.
8. Server stores the public key: The server validates the attestation, stores the public key and credential ID, and associates them with the user's account.

Authentication Flow

1. User initiates login: The user navigates to the login page or clicks "Sign in with passkey."
2. Server generates a challenge: The server creates a new random challenge and sends it along with the relying party ID and (optionally) a list of allowed credential IDs.
3. Browser invokes the authenticator: The browser calls navigator.credentials.get(), triggering the authenticator.
4. User verifies their identity: Biometric scan or device PIN, same as during registration.
5. Authenticator signs the challenge: The private key signs the challenge along with authenticator data (including the relying party ID and a signature counter).
6. Browser sends the assertion: The signed challenge and metadata are sent to the server.
7. Server verifies the signature: Using the stored public key, the server verifies that the signature is valid and that the relying party ID matches. If valid, the user is authenticated.

For the user, the whole process is a single biometric or PIN prompt. That is usually faster than typing a password and waiting for an SMS code.

Device-Bound vs. Synced Passkeys

This is one of the most important architectural decisions you will make, and it involves a genuine tradeoff between security and usability.

Characteristic	Device-Bound Passkeys	Synced Passkeys
Private key location	Single device only	Synced across devices via cloud (iCloud Keychain, Google Password Manager)
Survives device loss	No: the credential is lost with the device	Yes: available on any synced device
Security model	Highest: key never leaves the hardware	High: end-to-end encrypted, but the sync provider is in the trust chain
Usability	Lower: requires backup and recovery planning	Higher: works across the user's devices
Typical use case	High-security enterprise, regulated industries	Consumer applications, general enterprise workforce
Examples	Hardware security keys (YubiKey), enterprise-managed authenticators	Apple Passkeys, Google Passkeys
NIST AAL level	Can meet AAL3	Up to AAL2 (SP 800-63B-4)

For most enterprise deployments, synced passkeys are the right default for the general workforce, with device-bound passkeys (hardware security keys) reserved for privileged accounts, admin access, and regulated workloads.

Platform Support Matrix

As of November 2026, passkey support is effectively universal across major platforms:

Platform	Passkey support	Sync mechanism	Cross-device sign-in	Notes
Apple (iOS 16+, macOS Ventura+)	Full	iCloud Keychain	Yes (QR + Bluetooth)	Synced across Apple devices on the same Apple Account
Google (Android 9+, Chrome)	Full	Google Password Manager	Yes (QR + Bluetooth)	Works on Android and in Chrome on desktop
Microsoft (Windows 10 and 11)	Full	Windows Hello (device-bound); Microsoft Password Manager in Edge for sync	Yes (QR + Bluetooth)	Edge 142 added passkey saving and syncing through a Microsoft account
Linux	Partial	Browser or third-party password manager	Yes (phone as authenticator)	No OS-level passkey store
Third-party managers (1Password, Bitwarden and others)	Full on supported platforms	The manager's own vault	Varies	Useful for mixed Apple, Android and Windows fleets

Real-World Deployment Data

Theory and standards are important, but what matters is whether passkeys work in production, at scale, with real users. The best public evidence now comes from the FIDO Alliance and from Google.

The FIDO Passkey Index. The October 2026 Passkey Index pools data from 15 large consumer services, including Amazon, Google, Microsoft, PayPal, Shopify, TikTok and WhatsApp. No figure is attributed to a single company. Its headline results:

Finding	Result
Share of successful sign-ins that used a passkey	36%, up from 26% in the 2025 Index
Sign-in success rate, passkeys vs passwords and traditional MFA	93% vs 78%
Speed	Passkey sign-in 2.8 times faster, about 27 seconds saved per sign-in
Phishing	All 8 participants that measure it saw fewer successful phishing attacks
Active accounts eligible for passkeys	90%

Google. In May 2023, Google published data from roughly 100 million sign-ins. Same-device passkey sign-ins succeeded 63.8% of the time, against 13.8% for passwords, about four times as often. The average passkey sign-in took 14.9 seconds; a password sign-in took 30.4.

These are not pilot results from a lab. They are production deployments serving hundreds of millions of users. Note that both sources are consumer services. Workforce deployments tend to be smaller and better managed, so expect your own numbers to differ, and measure them.

Enterprise Enrollment Strategies

The most secure passkey implementation in the world is worthless if nobody enrolls. Enrollment strategy is where enterprise passkey deployments succeed or fail.

Gradual Rollout vs. Big Bang

Approach	Pros	Cons	Best For
Gradual rollout	Low risk, learn from early adopters, iterate on UX	Slower time to value, must maintain dual systems longer	Most enterprises
Big bang	Fast, clear cutover date, less complexity in steady state	High risk, requires extensive preparation, potential for disruption	Small organizations or greenfield deployments

For the vast majority of enterprises, a phased rollout is the right approach. You want real-world data from your own users before you commit the entire organization.

Enrollment UX Patterns That Drive Adoption

Just-in-time enrollment is the highest-converting pattern. In my experience, it converts best. Instead of asking users to set up a passkey through a separate configuration flow, you prompt them immediately after a successful password login:

"You just signed in with your password. Want to skip that next time? Set up a passkey in a few seconds."

This works because the user is already authenticated, already in context, and the value proposition is immediate.

Nudge patterns work well for driving adoption over time without forcing the issue. Show a dismissable prompt at login, track how many times a user has dismissed it, and escalate gently:

• First login: "Passkeys are now available. Learn more."
• Third login: "Most of your team is using passkeys. Set yours up in a few seconds."
• Tenth login: "You're one of the last people still using a password. Set up a passkey to save time."

Incentive structures can accelerate adoption in organizations with competitive cultures. Leaderboards showing passkey adoption by team, or small rewards (extra PTO hours, swag) for early adopters, can move the needle.

Cross-Device Authentication

One of the common concerns with passkeys is: "What if I need to sign in on a device that does not have my passkey?" The FIDO2 specification addresses this with cross-device authentication using a combination of QR codes and Bluetooth proximity.

Here is how it works:

1. The user attempts to sign in on a device without a passkey (say, a shared conference room laptop).
2. The login page displays a QR code.
3. The user scans the QR code with their phone (which has their passkey).
4. The phone and the laptop establish a secure connection over Bluetooth Low Energy (BLE), verifying that the two devices are physically close to each other.
5. The user authenticates on their phone (biometric or PIN).
6. The authentication assertion is relayed to the server, and the user is signed in on the laptop.

The Bluetooth proximity check is critical: it prevents remote attacks where someone intercepts the QR code and tries to authenticate from a different location.

Recovery Design for Enterprise

Device loss and employee transitions are the scenarios that keep IT administrators up at night during passkey deployments. If the private key is on the device and the device is gone, how does the employee get back in?

A robust recovery design includes multiple layers:

Synced passkeys as the first line of defense. If the employee's passkey syncs through iCloud Keychain or Google Password Manager, losing a single device does not matter. The passkey is available on their other devices and syncs to a replacement device once the employee signs in to that account.

Backup authenticators. Require employees to register at least two authenticators during enrollment. A common pattern is a primary passkey on their phone plus a hardware security key stored in a secure location (desk drawer, home safe). Some organizations issue two YubiKeys per employee for precisely this reason.

IT admin recovery flow. When an employee has lost all authenticators, IT needs a secure process to re-verify the employee's identity and issue a new credential. This typically involves:

1. Identity verification through an out-of-band channel (video call with manager, in-person verification with ID badge)
2. IT admin generates a time-limited recovery token
3. Employee uses the token to enroll a new passkey
4. Old credentials are revoked immediately

Temporary access. For situations where recovery takes time (shipping a new security key to a remote employee), provide a temporary access mechanism with elevated logging and reduced permissions. A time-boxed magic link or a supervised session with an IT admin can bridge the gap.

Recovery Scenario	Primary Mechanism	Backup Mechanism	Time to Restore
Lost phone (synced passkeys)	Auto-sync to new/other device	Backup security key	Minutes
Lost phone (device-bound)	Backup security key	IT admin recovery flow	Minutes to hours
Lost all authenticators	IT admin recovery flow	In-person identity verification	Hours to 1 day
Employee offboarding	Credential revocation	Access review and audit	Immediate

Enterprise-Specific Considerations

Enterprise passkey deployments face challenges that consumer deployments do not. Here are the scenarios you need to plan for:

Managed Devices

On fully managed devices (MDM-enrolled laptops and phones), you have significant control. You can pre-configure passkey providers, enforce enrollment during device provisioning, and remotely wipe credentials when an employee leaves. This is the simplest deployment scenario.

BYOD (Bring Your Own Device)

BYOD introduces complexity. The passkey lives on the employee's personal device, synced through their personal Apple or Google account. When the employee leaves the company, you can revoke the server-side credential, but the private key remains on their device. This is acceptable from a security standpoint, because the private key is useless once the server no longer holds the matching public key. It still makes some compliance teams uncomfortable.

Contractor and Third-Party Access

Contractors often use their own devices and may not be willing to sync credentials through your organization's identity provider. For these users, hardware security keys or cross-device authentication flows are typically the right approach. Issue a security key at the start of the engagement and collect it when the contract ends.

Shared Workstations

Shared workstations in manufacturing, healthcare, and retail present a unique challenge. No single user "owns" the device, so device-bound passkeys do not apply. The solution is cross-device authentication: each user authenticates using their phone as the authenticator, with the shared workstation acting as the display and input device.

Integration Patterns: Passkeys in Your Existing Identity Stack

Most enterprises are not starting from scratch. They have an existing identity infrastructure built on SAML, OIDC or both, typically run through an SSO provider (Okta, Microsoft Entra ID, Ping Identity or similar). Passkeys need to fit into this stack, not replace it.

SAML + Passkeys

In a SAML-based environment, the identity provider (IdP) handles authentication. To add passkey support, you implement passkeys at the IdP layer. The service providers (SPs) do not need to change. They continue to receive SAML assertions as before. The only difference is that the IdP now uses a passkey instead of a password to verify the user's identity before issuing the assertion.

OIDC + Passkeys

The pattern is identical for OIDC. The authorization server / IdP adds passkey support as an authentication method. Relying parties continue to receive ID tokens and access tokens through standard OIDC flows. The authentication method used at the IdP is opaque to the relying party.

Direct WebAuthn Integration

For custom applications where you control the authentication stack, you can integrate WebAuthn directly. This is particularly relevant for customer-facing applications where you are the identity provider.

Code Example: WebAuthn Registration and Authentication

Here is a simplified but functional example of the WebAuthn flows in JavaScript. This is what the client-side integration looks like:

Registration

async function registerPasskey() {
  // 1. Get registration options from your server
  const optionsResponse = await fetch('/api/webauthn/register/options', {
    method: 'POST',
    headers: { 'Content-Type': 'application/json' },
    body: JSON.stringify({ username: currentUser.email })
  });
  const options = await optionsResponse.json();

  // 2. Convert base64url strings to ArrayBuffers
  options.challenge = base64urlToBuffer(options.challenge);
  options.user.id = base64urlToBuffer(options.user.id);

  // 3. Call the WebAuthn API - this triggers the authenticator
  const credential = await navigator.credentials.create({
    publicKey: {
      rp: { name: options.rp.name, id: options.rp.id },
      user: {
        id: options.user.id,
        name: options.user.name,
        displayName: options.user.displayName
      },
      challenge: options.challenge,
      pubKeyCredParams: [
        { type: 'public-key', alg: -7 },   // ES256
        { type: 'public-key', alg: -257 }  // RS256
      ],
      authenticatorSelection: {
        authenticatorAttachment: 'platform',
        residentKey: 'required',
        userVerification: 'required'
      },
      timeout: 60000
    }
  });

  // 4. Send the credential to your server for storage
  const registrationResponse = await fetch('/api/webauthn/register/verify', {
    method: 'POST',
    headers: { 'Content-Type': 'application/json' },
    body: JSON.stringify({
      id: credential.id,
      rawId: bufferToBase64url(credential.rawId),
      type: credential.type,
      response: {
        attestationObject: bufferToBase64url(
          credential.response.attestationObject
        ),
        clientDataJSON: bufferToBase64url(
          credential.response.clientDataJSON
        )
      }
    })
  });

  return registrationResponse.json();
}

Authentication

async function authenticateWithPasskey() {
  // 1. Get authentication options from your server
  const optionsResponse = await fetch('/api/webauthn/authenticate/options', {
    method: 'POST',
    headers: { 'Content-Type': 'application/json' }
  });
  const options = await optionsResponse.json();

  // 2. Convert challenge from base64url to ArrayBuffer
  options.challenge = base64urlToBuffer(options.challenge);

  // 3. Call the WebAuthn API - this triggers the authenticator
  const assertion = await navigator.credentials.get({
    publicKey: {
      challenge: options.challenge,
      rpId: options.rpId,
      userVerification: 'required',
      timeout: 60000
    }
  });

  // 4. Send the assertion to your server for verification
  const verifyResponse = await fetch('/api/webauthn/authenticate/verify', {
    method: 'POST',
    headers: { 'Content-Type': 'application/json' },
    body: JSON.stringify({
      id: assertion.id,
      rawId: bufferToBase64url(assertion.rawId),
      type: assertion.type,
      response: {
        authenticatorData: bufferToBase64url(
          assertion.response.authenticatorData
        ),
        clientDataJSON: bufferToBase64url(
          assertion.response.clientDataJSON
        ),
        signature: bufferToBase64url(assertion.response.signature),
        userHandle: bufferToBase64url(assertion.response.userHandle)
      }
    })
  });

  return verifyResponse.json();
}

Common Deployment Mistakes

These are the mistakes I see repeated most often, and the ones that cause the most damage:

Not providing fallback options. Your passkey flow will fail for some users some of the time. If there is no fallback, those users are locked out. Always maintain at least one alternative authentication path during the transition period.

Poor enrollment UX. If enrollment means finding a settings page, clicking through five screens and reading documentation, adoption will stall. The best enrollment flows take seconds and appear at the moment of highest motivation, immediately after a password login.

Ignoring platform gaps. Deploying passkeys without accounting for Linux users, older Android versions, or employees who do not own smartphones creates a two-tier workforce and breeds resentment.

Treating passkeys as "just another MFA method." Passkeys are not a second factor bolted onto a password. They are a complete replacement for the password. If your implementation still requires a password as the primary factor with a passkey as the second, you have not gone passwordless. You have added complexity.

Skipping the pilot. Rolling out to 10,000 users without first learning from 100 is a recipe for a rollback that sets the project back by a year.

Migration from Passwords: The Coexistence Period

No enterprise moves from passwords to passkeys overnight. There is always a coexistence period during which both authentication methods are supported. Managing this period well is critical.

Phase 1: Passive availability. Passkeys are available for users who want them, but passwords remain the default. No prompts, no nudges. This phase is about ensuring the technical infrastructure works.

Phase 2: Active enrollment. Just-in-time enrollment prompts appear after password logins. Early adopters create passkeys. Support documentation is published. IT helpdesk is trained on passkey troubleshooting.

Phase 3: Preferred method. Passkeys become the default authentication method. Users who have enrolled no longer see the password field unless they explicitly choose "Sign in another way." New employee onboarding includes passkey enrollment as a mandatory step.

Phase 4: Enforcement. Passwords are disabled for roles and systems where passkey support is confirmed to be universal. This typically starts with privileged accounts (where the security argument is strongest) and expands outward.

Phase	Name	Duration	Password Status	Passkey Status	Key Metric
1	Pilot	4-8 weeks	Default	Optional	Technical stability, support ticket volume
2	Early Adopter	8-12 weeks	Default	Actively promoted	Enrollment rate, login success rate
3	General Availability	12-24 weeks	Available but not default	Preferred	Adoption percentage, support reduction
4	Enforcement	Ongoing	Disabled (by role/system)	Required	Coverage percentage, exception count

The Architecture Decision That Matters Most

If there is one takeaway from this chapter, it is this: passkeys are not a feature you add. They are an architectural shift in how your organization thinks about identity.

The server no longer stores secrets. The network no longer carries secrets. The user no longer has to remember secrets. Authentication becomes a cryptographic handshake between a device that holds a private key and a server that holds the corresponding public key, with the user's biometric serving as the authorization to use that key.

This changes your threat model, your support model, your onboarding process, your compliance posture, and your cost structure. It is a substantial undertaking. But the organizations that have done it report the same things in the Passkey Index: higher sign-in success, faster sign-ins, fewer successful phishing attacks and lower SMS costs.

For a comprehensive, step-by-step deployment framework including vendor evaluation criteria, compliance mapping, and ROI calculations, see Passkeys at Scale: The Complete Enterprise Deployment Playbook 2026.

The next chapter adds the intelligence layer: adaptive authentication and behavioral signals that decide when a passkey alone is enough.