Phishing-resistant authentication, deployed.
What it actually takes to roll FIDO2 across an enterprise — the policy decisions, the architecture, the recovery flow, and the operational realities that decide whether the programme succeeds.
What FIDO2 buys you
- Phishing resistance by construction. Origin binding refuses authentication to the wrong domain. Adversary-in-the-middle proxies don’t harvest a usable credential.
- No shared secret. The RP holds your public key. There’s no password database to leak.
- Hardware-bound private key. Generated on-chip, never leaves the authenticator. Key extraction is hard.
- Attestation-pinnable. You can enforce that only your hardware registers against your accounts.
The deployment architecture
| Layer | What it does |
|---|---|
| Authenticator | OnePass Card / USB Key / Bio Card. Holds the private key in a secure element. |
| IdP | Okta / Entra ID / Ping / CAS. The relying party for the SaaS estate. WebAuthn-enabled. |
| Validation server | The relying party for internal applications that don’t speak WebAuthn natively. |
| Lifecycle | Issuance, rotation, recovery, revocation, audit log. |
AAGUID policy
AAGUID is the identifier for the authenticator model. A FIDO2-capable IdP can refuse to register any authenticator that isn’t on a pre-approved list. The policy must be paired with FIDO Metadata Service (MDS) verification at registration; otherwise AAGUIDs can be spoofed by self-signed attestations.
- Decide your allowed authenticator classes (your issued OnePass cards, your issued OnePass USB keys, optionally a small TPM-platform allow-list).
- Pin AAGUIDs at the IdP’s WebAuthn configuration.
- Enable MDS validation.
- Document the policy in your CPS / security policy.
Recovery
The biggest failure mode of a FIDO programme. Recovery has to be at least as strong as initial issuance — otherwise recovery becomes the phishing target.
- Sealed backup credential issued at the same time as the primary. User goes to IT desk on loss, breaks seal, logs in, gets re-issued.
- M-of-N break-glass for privileged accounts that can’t wait for in-person.
- No SMS, no email-link recovery. Either of those reintroduces the credential FIDO is replacing.
Common deployment mistakes
- AAGUID without MDS — spoofable; not a real policy.
- Allowing personal-bought keys to register — dilutes the attestation story.
- SMS as a recovery factor — vector for SIM-swap.
- Push approval as second factor — vulnerable to push-fatigue.
- No backup credential — helpdesk floods on first major outage.
- Online-only validation with no offline path for kiosks — gates fail during backend outages.
Related on the AmbiSecure site
Planning a FIDO rollout?
The first call is engineering — your IdP, your application catalogue, your recovery posture. The first deliverable is a deployment plan, not a deck.