Enterprise passwordless — deploying and operating it across the organisation.
Most "passwordless" deployments still have a password sitting in the recovery flow. Real passwordless is when the password is not just hidden — it doesn't exist on the user's account. Hard to reach, but reachable. This is the deployment guide.
It assumes the decision to replace password + OTP is already made; the case for that is on Passwordless & MFA. Here the question is how to roll it out and run it.
The six pieces of a deployment
An end-to-end enterprise passwordless deployment has six load-bearing pieces:
- Hardware authenticators — certified, attestation-anchored. OnePass Card (turnstile + desktop), OnePass USB Key (laptops), platform passkeys (mobile fallback only).
- Provisioning pipeline — first-day enrolment without a password as a fallback.
- Recovery flow — what happens when an employee loses their key. Hint: not "answer security questions" or "wait for an email link".
- Federation — passkeys at the IdP (Okta / Entra ID / Ping) so every downstream app benefits without per-app integration.
- Attestation policy — AAGUID allow-list anchored against the FIDO MDS BLOB, with explicit BE=0 enforcement for high-assurance sessions.
- Lifecycle automation — revoke at offboarding, rotate at policy boundary, audit everywhere.
The recovery problem — honestly
Recovery is where most passwordless rollouts collapse. The user lost their key. What now? If the answer is "reset password to a temp value and email it" you have not removed passwords; you have hidden them.
The right answers, in priority order:
- Two enrolled authenticators per user. Card + USB key. Lose one, the other stands in. Re-issue the lost one through the normal pipeline.
- Just-in-time IT-mediated re-issuance. Short-lived TOTP codes printed at the IT desk after in-person identity verification. Time-boxed; one-shot.
- Last-resort: identity-vouching with an enrolled colleague. Two co-workers approve, IT issues. Audit trail.
What the answer should never be: a recoverable password sitting on a recovery email.
Deployment architecture
Operating model: onboarding to offboarding
HR onboarding kicks off issuance. New hire receives card + key on day 1, enrols both at the IT desk in person.
Tap card on reader / insert USB key. Browser passes signed assertion to IdP. SSO mints session for downstream apps.
Use the still-enrolled second authenticator to sign in; IT issues a replacement; old AAGUID/serial revoked across IdP.
HR offboarding triggers revocation in IdP; sessions terminated; cards collected.
Rolling out across teams and sites
- Inventory the authentication estate first. List every place a user still types a password: IdP, VPN, privileged access, legacy apps outside SSO, shared and service accounts. The rollout is finished only when that list is empty.
- Roll out by population, not by app. Start with one team and its IdP integration. Then cover privileged users, then each site or business unit. Federation means each new population needs enrolment, not new integration work.
- Put enrolment where people are. In-person enrolment needs an IT desk or enrolment station at each site, with stock of spare authenticators. Remote staff need a verified shipping and activation process.
- Give administrators a single view. They need to see which authenticators are enrolled to whom, by AAGUID and serial, with revocation from one place in the IdP.
- Retire the fallback deliberately. Once a population is fully enrolled, remove its password and OTP fallback. A fallback that is never removed is a password that was never removed.