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 are standing in front of a deployment plan and 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 on your device, locked inside a secure enclave - a hardware-isolated area of your phone or computer's processor that even the operating system cannot directly access.

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, no shared secret of any kind. The private key never leaves your device. 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

Understanding the two core flows - registration and authentication - is essential for anyone making architectural decisions.

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 (proving the authenticity of the authenticator) are returned to the browser.
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.

The entire process typically takes under two seconds for the user - 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 - credential is lost with device	Yes - available on any synced device
Security model	Highest - key never leaves hardware enclave	High - encrypted in transit and at rest, but cloud provider is in the trust chain
Usability	Lower - requires backup/recovery planning	Higher - works seamlessly across 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	Typically AAL2

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 early 2026, passkey support is effectively universal across major platforms:

Platform	Passkey Support	Sync Mechanism	Cross-Device Auth	Notes
Apple (iOS 16+, macOS Ventura+)	Full	iCloud Keychain	Yes (QR + Bluetooth)	Passkeys synced across all Apple devices with same Apple ID
Google (Android 9+, Chrome)	Full	Google Password Manager	Yes (QR + Bluetooth)	Supports passkeys on Android and Chrome across platforms
Microsoft (Windows 11 23H2+)	Full	Windows Hello + Microsoft Account	Yes (QR + Bluetooth)	Synced passkeys supported since late 2024
Linux (Chrome/Firefox)	Partial	Depends on browser	Yes (via phone as authenticator)	No native OS-level passkey sync
Safari	Full	iCloud Keychain	Yes	Aligned with Apple ecosystem
Firefox	Full	Firefox sync (limited)	Yes (via phone)	Added full WebAuthn support in 2024

Real-World Deployment Data

Theory and standards are important, but what matters is whether passkeys work in production, at scale, with real users. The data from early enterprise and consumer deployments is compelling.

eBay reported a 102% increase in passkey adoption within the first months of their rollout, with authentication success rates significantly higher than password-based flows. The reduction in account takeover attempts was immediate and measurable.

HubSpot achieved 4x faster login times after deploying passkeys, while simultaneously reducing support tickets related to authentication. Their users did not need to be convinced - faster and easier was enough.

Shopify reduced account takeover by more than 50% after introducing passkey support for merchant accounts, with the highest-risk accounts (those with the most revenue) seeing the fastest adoption.

Google reported that passkey sign-ins are 40% faster than passwords and have a 4x higher success rate - meaning users complete the authentication flow without errors far more consistently than with passwords.

"The data is clear: passkeys are not just more secure - they are more usable. And that combination is rare in security." - From Passkeys at Scale: The Complete Enterprise Deployment Playbook 2026

These are not pilot results from a controlled environment. These are production deployments serving millions of users.

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. 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 - it takes 10 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 10 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 regain access?

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 will sync to a replacement device automatically.

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 - the private key without the corresponding server-side public key is useless - but it 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 orchestrated through an SSO provider (Okta, Azure AD, 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

Having worked with organizations deploying passwordless authentication at scale, I have seen the same mistakes repeated. Here are the ones that cause the most damage:

Not providing fallback options. If your passkey flow fails - and it will, for some percentage of users, some of the time - and 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 requires navigating to a settings page, clicking through five screens, and reading documentation, adoption will stall below 20%. The best enrollment flows take fewer than 15 seconds and are triggered 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 knows 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 - eBay, Google, Shopify, HubSpot, and a growing list of enterprises - report the same thing: lower costs, fewer breaches, faster logins, and happier users.

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 will focus on the organizational and change management dimensions - because the hardest part of going passwordless is rarely the technology. It is the people.