Designing Enterprise Passwordless Systems.
WebAuthn is well-specified and library-supported. Anyone can stand up a demo in a weekend. What separates a demo from a production deployment is the nine load-bearing operational components around the protocol. Here they are, in order.
The deployment, not the protocol
WebAuthn is the easy part. The protocol is well-specified, browser-native, library-supported. Anyone can stand up a demo in a weekend. What separates a demo from a production deployment for 10,000+ employees is the operational work around it: provisioning, recovery, lifecycle, federation, attestation policy, incident response. This post is the deployment runbook.
Architecture — the nine load-bearing components
An end-to-end enterprise passwordless deployment has nine components. You can ship without some of them but you cannot ship without all of them simultaneously.
- Authenticators. The hardware. Two per user, ideally different form factors (smart card + USB key).
- Provisioning pipeline. How a new hire gets a credential on day 1.
- RP backend (FIDO Validation Server). WebAuthn / CTAP2 verification, attestation-policy enforcement, AAGUID allow-list.
- FIDO MDS sync. Daily BLOB fetch + verify; cache by AAGUID.
- IdP integration. Federation at the IdP layer; downstream apps inherit via SAML / OIDC.
- Lifecycle automation. HR-driven enrol / revoke; offboarding propagation under 5 minutes.
- Recovery flow. IT-mediated re-enrolment; never password fallback.
- Audit logging. AAGUID + serial + signCount per ceremony; anomalies to SOC.
- User communication. The non-technical part that decides whether rollout succeeds.
The provisioning pipeline
Day-zero enrolment is the moment of highest sensitivity in the deployment. The user has not yet authenticated to anything; you cannot use their existing identity to bootstrap a new one. The right pattern is in-person, identity-verified, single-shot.
The IT desk pattern
- HR system flags the new hire's start date.
- IT has hardware ready (card + USB key) on day 1.
- New hire visits IT desk on day 1. IT verifies government ID against HR record.
- IT triggers an enrolment session. New hire registers both authenticators against the IdP. The IdP records AAGUID + serial against the user record.
- New hire leaves with both credentials. Card carries their badge photo; USB key carries an asset tag.
Distributed-workforce variant
For remote-first workforces, the IT desk pattern does not scale. Two alternatives:
- Mailed kit + supervised enrolment. Tamper-evident envelope with both authenticators, mailed to the user. Enrolment session over Zoom with IT manager observing identity-verification (driver's license, employer-of-record check). The envelope's tamper-evidence is the chain-of-custody attestation.
- Regional satellite IT desks. Quarterly travel days where an IT person visits a region; new hires from that region's queue are enrolled in person. Higher friction; better assurance.
Recovery — the politically hard problem
Recovery is where most passwordless rollouts come apart. The user lost their key on a Thursday morning before a board meeting. What is the recovery path?
The honest answer requires accepting that there is no purely-self-service recovery path that preserves the security model. Any self-service recovery is, by definition, a back-channel that an attacker can also use. So the recovery path is IT-mediated.
Tiered recovery flow
- Tier 1 (90% of cases): use the second enrolled authenticator. The user enrolled two; one is at home, the other at the office. They sign in with whichever they have, then re-issue the lost one through the normal process.
- Tier 2: in-person re-issuance. The user goes to the IT desk, identity-verifies in person, leaves with a fresh authenticator. Same protocol as day-zero enrolment.
- Tier 3: identity-vouched re-issuance. Two co-workers (managers or peers) vouch for the user's identity in a video session with IT. Time-boxed (24h validity), single-shot, audited. For users who can't physically reach an IT desk and can't wait.
- No tier 4. If none of the above work, the user is offboarded and re-onboarded. This sounds severe; in practice it covers maybe 0.1% of cases per year.
The key word is "audited". Every recovery action is a privileged operation that creates a paper trail. The trail is what stops the recovery flow from itself becoming the attacker's preferred path.
Federation at the IdP, not the application
The temptation when first deploying WebAuthn is to integrate with a few apps directly. Don't. The right architectural decision is to put WebAuthn / passkey support at the IdP layer (Okta, Entra ID, Ping, Auth0) and let downstream applications inherit via SAML / OIDC.
This single decision saves you from N integrations becoming N×M when the policy changes. Want to require BE=0 for engineering and accept BE=1 for marketing? Configure two policies at the IdP, attach to the relevant directory groups, done. Without IdP federation, you would re-implement the policy in every app.
The upstream cost: your IdP must support WebAuthn natively, not via plug-in. Okta, Entra ID (Microsoft), Ping, Auth0, ForgeRock all do as of 2026. If your IdP doesn't, the IdP migration is the project, not the WebAuthn integration.
Attestation policy — the practical levers
Attestation policy is configuration, not code. The levers:
- attestation: 'direct' in the registration options. The browser asks the authenticator to produce attestation. The browser may or may not strip it (depends on user agent and policy); in enterprise-managed contexts you can configure UAs to pass it through.
- AAGUID allow-list at the RP. The list of AAGUIDs your security team has approved. Maintained as runtime config; updated when new device families are procured or revoked.
- MDS status check. Reject any AAGUID with a compromise status. Refresh daily.
- BE/BS policy. Per application or per directory-group: require BE=0 for high-assurance flows, accept BE=1 for everyday flows.
- UV policy. Require user verification for sensitive actions. The application layer must request
userVerification: 'required'and the RP must verify the UV bit.
Logging — what to capture, what to ignore
Per-ceremony, your auth log should capture:
- User ID, RP ID, ceremony type (create / get).
- credentialId (or hash thereof).
- AAGUID, vendor, model (joined from MDS at log time).
- Authenticator serial (if enterprise attestation in use).
- signCount (and delta from prior).
- BE / BS / UV / UP flags.
- Origin, IP, user agent, geo.
- Timestamp, latency.
Anomalies that should alert SOC:
- signCount regression for the same credentialId — suggests cloned credential or rolled-back authenticator.
- AAGUID change for the same credentialId — should be impossible; investigate.
- Geo + IP improbable-travel for the same user.
- BS flag changing on a credential where BE=0 — should be impossible; investigate.
- Multiple registrations for the same user from different AAGUIDs in a short window — could be normal (re-issuance) or could be account takeover.
User communication — the non-technical part
Half of "passwordless rollout failures" are not technical. They are communication failures. The user does not understand what changed, why, and what to do when something goes wrong. Three areas pay dividends out of proportion to investment:
1. The narrative
Lead with the user benefit, not the security benefit. "You will stop typing passwords" beats "we have improved the cryptographic posture". The latter is true; the former is what the user cares about.
2. The lost-key playbook
Pre-emptive: every user gets a one-page handout describing exactly what to do if they lose a key. The handout includes the second-key-fallback, the IT desk hours, and the support phone number. Without this, the first lost-key incident produces a flood of confused tickets.
3. The training
30 minutes of mandatory training, paired with the day-1 enrolment. Cover: how to tap, how to enter PIN, how to recognise a legitimate prompt, how to react to an unexpected prompt (don't tap; report). Repeat the recognition training every 6 months.
Lifecycle automation — the propagation graph
HR is the source of truth for employment status. Onboarding and offboarding events flow from HR to:
- IdP user record — create / disable / delete.
- Authenticator inventory — mark devices as issued / returned / lost.
- RP attestation policy — usually no change (policy is per-tier, not per-user).
- Audit log — record the lifecycle event with timestamp.
The hard requirement: offboarding must propagate from HR to IdP to active sessions in under 5 minutes. Anything slower means an offboarded employee with active sessions for an unknown window. A queue-driven event bus with retries and a dead-letter alert is the standard pattern.
Migration plan — from password+OTP to passkey-only
A 12-month plan for a 10,000-person organisation:
Months 0-2: foundation
- Procure authenticators. Stage at IT desks.
- Stand up FIDO Validation Server. Integrate with IdP.
- Build provisioning + recovery runbooks.
- Configure attestation policy: AAGUID allow-list, MDS sync, BE policy.
- Pilot with engineering / IT cohorts (~200 people).
Months 3-6: cohort rollout
- Enrol cohort by cohort, ~1,000-2,000 people per month.
- Track enrolment %, lost-key rate, recovery latency.
- Iterate on user comms based on support tickets.
- Deprecate password as primary at the IdP for enrolled users; password becomes recovery-only.
Months 7-9: deprecate alternatives
- For users who have been enrolled 60+ days, disable password sign-in entirely.
- Recovery flows become the only password use; rotate password to a high-entropy random value at recovery completion.
- Remove TOTP / push as accepted second factors at the IdP.
Months 10-12: cleanup
- Disable any remaining password-only login paths.
- Audit holdouts; force-enrol or offboard.
- Final security review: attestation logs reconciled, no orphaned credentials, no expired authenticators in use.
- Document the deployment for onboarding the next cohort of users.
What we got wrong, what we learned
From real deployments, three lessons that are not in the protocol spec:
Lesson 1: do not skip the second authenticator. Cost-conscious deployments sometimes ship one authenticator per user. The result is a doubling of lost-key incidents, a recovery flow that becomes the user-experience bottleneck, and a de-facto fallback to less-secure recovery paths. The second authenticator is not optional.
Lesson 2: the IdP is the lever. Apps that integrate with WebAuthn directly become a maintenance burden. IdP federation is the right abstraction; pay the cost upfront.
Lesson 3: comms before crypto. A 30-minute user-comms investment per cohort prevents weeks of confused support tickets. The cryptography is there to make the protocol work; the comms is there to make the deployment work.
The summary
Enterprise passwordless is a deployment, not a feature. The protocol is necessary but not sufficient. Get the nine components right and the result is operationally calmer than what you replaced — fewer incidents, lower support load, higher assurance. Skip any of the nine and you ship something that works on day one and breaks on day thirty.