Phasing out SMS and TOTP across a mixed enterprise estate.

A 9,000-seat engineering and operations workforce migrating from SMS one-time codes and TOTP apps to FIDO2 hardware authenticators — against a legacy stack that included Okta SSO for SaaS, Microsoft Entra ID for Windows, and a CAS-backed internal application portal that predated WebAuthn by a decade.

The challenge

The customer had a credible MFA programme on paper. In practice they had three problems they wanted addressed before their next ISO/IEC 27001 surveillance audit:

• Phishable second factors. SMS and TOTP remained dominant, and the SOC was logging credible MFA-fatigue and SIM-swap attempts against high-privilege accounts.
• Inconsistent enrolment quality. Roughly 12% of staff were on SMS, 60% on a vendor authenticator app, and the remainder on a mixed bag of hardware tokens accumulated from prior pilots.
• Coverage gaps in their legacy application portal. An internal CAS-backed portal hosted approximately 40 line-of-business applications and had no WebAuthn support at all.

The brief was: deliver phishing-resistant authentication across the whole estate, keep the legacy portal working, and do it inside a single annual budget cycle.

Architecture overview

The design centred on three decisions:

1. Choose a single attestation policy across the estate. Rather than allow any FIDO authenticator, the customer pinned to a small set of AAGUIDs — their issued OnePass Card, the OnePass USB Key for shared kiosks, and a small TPM-platform allow-list for managed laptops.
2. Run a single validation server. The customer’s SaaS estate already used Okta and Entra ID as relying parties. For the legacy CAS portal, we deployed the FIDO Validation Server as an SSO-side authenticator behind CAS, so the portal didn’t need to learn WebAuthn natively.
3. Bind attestation to lifecycle. AAGUID allow-listing only protects you if registration enforces it. Issuance used OnePass platform tooling so every credential was bound to a known hardware lot.

Standards involved

• FIDO2 · CTAP2.1 — authenticator protocol.
• W3C WebAuthn Level 2 — relying-party API.
• Packed attestation with FIDO Metadata Service (MDS) verification at registration.
• NIST SP 800-63B AAL3 — the customer’s target assurance level for privileged accounts.
• OpenID Connect — the bridge to the legacy CAS portal.

Deployment constraints

The constraint set drove every design choice:

• Mixed device fleet. The customer had Windows-managed laptops, BYOD macOS, kiosks for shift-worker logins, and shared field-service tablets. No single authenticator class fit all four.
• Audit-grade attestation. The compliance team wanted evidence that every credential registered against a corporate account was on certified hardware. AAGUID alone is not evidence; attestation chain validation against FIDO MDS is.
• Legacy portal had to keep working. The internal portal was on a multi-year sunset path but couldn’t move first. So the FIDO Validation Server had to slot in as a CAS authenticator without modifying the 40 downstream applications.
• Self-service helpdesk pressure. A single major outage of the recovery flow would cost more than the entire deployment. So recovery had to be in-person and resilient, not online and clever.

Trust model

The threat model the customer wanted hardened was specifically:

• Phishing-resistant primary auth. FIDO2 origin binding gives this for free as long as MITM proxies are detected at the RP. Origin binding handled the bulk of credential-phishing attempts the SOC had been logging.
• SIM-swap and push-fatigue resistance. Eliminated by design once SMS and push are removed from the second-factor catalogue.
• Bring-your-own-authenticator dilution. Mitigated by AAGUID allow-listing + MDS verification — a personal $20 key cannot register against a managed account.
• Lost-device window. Recovery is via in-person re-issuance; the lost credential is revoked at the validation server in real time, and credential revocation propagates to every RP via the existing IdP session-revocation pipeline.

Implementation approach

Delivery was three tracks running in parallel, each owned by a different customer team but with shared architecture review:

Issuance flow

Issuance ran at the customer’s existing IT desk with a small operator console:

1. Employee shows ID; the operator confirms identity from the HR record.
2. The console writes a fresh, hardware-bound FIDO credential to the OnePass Card, registers it against the user’s Okta and Entra accounts (via the IdPs’ admin APIs), and prints the badge artwork on the card surface in the same pass.
3. If the user is in the privileged group, a backup OnePass USB Key is also enrolled and issued under sealed cover for emergency recovery.
4. Operator hands over the card and the optional backup; employee is logged in once at a kiosk to validate the credential.

The whole flow targeted under five minutes per employee. With practice, the IT desk routinely beat that.

Operational considerations

• Helpdesk training mattered more than UX. The vast majority of "FIDO doesn’t work" tickets in the first month were a single confusion: users tapping the card on the laptop’s NFC reader before the relying-party page had finished prompting. The fix was a 10-minute helpdesk video, not a software change.
• Privileged-account recovery is a process, not a feature. The customer adopted an M-of-3 escrow for break-glass codes, audited monthly. Engineering kept the protocol simple so the security team could explain it to auditors.
• Browser/IdP version pinning. WebAuthn behaviour drifted in two relying parties during the rollout (a Chromium change in extension API, an Okta policy change in conditional-access). The lesson logged: pin a minimum browser version in the conditional-access policy, then track upstream changes deliberately.

Integration flow

// Simplified RP-side credential-creation policy
authenticatorSelection: {
  authenticatorAttachment: "cross-platform",  // OnePass Card / USB Key
  residentKey: "preferred",                   // discoverable creds where supported
  userVerification: "required"                // PIN or bio always required
}
attestation: "direct"
extensions:        { credProps: true }
allowedAAGUIDs:    [/* AmbiSecure-issued AAGUIDs only */]
mdsValidation:     true                       // FIDO Metadata Service

The validation server was configured to reject any credential where the AAGUID was outside the allow-list, where attestation chain validation failed against MDS, or where the metadata statement’s certification level didn’t meet the customer’s AAL3 floor.

Lessons learned

1. AAGUID allow-listing without MDS validation is theatre. Without verifying the attestation chain against FIDO Metadata Service, AAGUID alone can be spoofed by self-signed attestations.
2. The legacy bridge mattered more than the modern apps. The Okta / Entra integration was textbook. The CAS bridge was where 60% of the integration effort actually went. Plan accordingly.
3. Issuance is faster than recovery, so design recovery first. Once you know exactly what an employee does when they lose their card on a Friday night, the rest of the system is much easier to design.
4. Print badge + credential on the same card. "Two things" is two things to lose. The OnePass Card form factor halves the loss rate.

Related products and services

• OnePass Platform — the hardware-backed identity platform.
• OnePass Card — smart card + FIDO authenticator.
• OnePass USB Key — FIDO-certified hardware key.
• FIDO Validation Server — deployable WebAuthn RP backend.
• Passwordless enterprise solution — the deployment overview.

Related references & reading

• Implementing FIDO2: A Complete Developer Guide
• Designing Enterprise Passwordless Systems
• Understanding WebAuthn Attestation Objects
• Platform vs Roaming Authenticators
• Reference: WebAuthn COSE key formats
• Tool: AAGUID lookup