FIDO2 & WebAuthn
Status: Final
FIDO2 is the current gold standard for phishing-resistant authentication. Unlike passwords, OTPs, or push MFA, FIDO2 credentials are cryptographically bound to the origin — a forged site cannot receive a valid authentication response. Understanding FIDO2 is essential for both hardening recommendations and for understanding the boundaries of current MFA bypass attacks.
The FIDO2 Stack
FIDO2 is a collective name for two complementary standards:
FIDO2
├── WebAuthn (W3C) — browser/application API
└── CTAP2 (FIDO Alliance) — communication with hardware authenticators
| Component | Role |
|---|---|
| WebAuthn | Web API (navigator.credentials) that browsers expose to web apps |
| CTAP2 | Protocol between the browser/platform and an external authenticator (YubiKey, etc.) |
| Authenticator | The device that stores the private key and signs challenges |
Authentication Flow
Registration
1. Server generates challenge (random bytes) + RP ID (origin's domain)
2. Browser calls navigator.credentials.create()
3. Authenticator:
- Generates a new key pair per credential
- Stores private key (never leaves authenticator)
- Returns: public key + credential ID + attestation
4. Server stores: public key + credential ID (not private key — it never sees it)
Authentication
1. Server sends challenge + RP ID
2. Browser calls navigator.credentials.get()
3. Authenticator:
- Locates credential for RP ID
- Signs (challenge + RP ID + client data) with private key
- Returns: signed assertion
4. Server verifies signature with stored public key
Why FIDO2 Is Phishing-Resistant
The RP ID is cryptographically bound to the origin in the signed assertion. When a user visits a phishing site evil-login.com, the authenticator:
- Sees the RP ID =
evil-login.com - Looks for a stored credential for
evil-login.com - Finds none (credential was registered to
login.microsoftonline.com) - Refuses to authenticate
No credential is sent to the phishing site — the attack fails at the hardware level.
Compare: Push MFA (Okta Verify, MS Authenticator push) — victim approves push notification → MFA is satisfied → attacker gets the token. FIDO2 cannot be social-engineered this way.
Authenticator Types
Platform Authenticators (built-in)
| Platform | Authenticator | Mechanism |
|---|---|---|
| Windows 11 | Windows Hello | TPM-backed key, biometric/PIN |
| macOS | Touch ID | Secure Enclave key |
| iOS / Android | Platform key | Secure Enclave / StrongBox |
Platform authenticators issue Passkeys — synced (iCloud Keychain, Google Password Manager) or device-bound.
Roaming Authenticators (external)
| Device | Notes |
|---|---|
| YubiKey (FIDO2 mode) | Hardware key, USB/NFC/Lightning |
| Google Titan Key | USB-A/C, NFC |
| Feitian keys | Enterprise hardware keys |
Roaming authenticators are device-bound — the key does not leave the hardware token.
Enterprise Deployment (Entra ID / Windows Hello for Business)
Windows Hello for Business (WHfB) is Microsoft's enterprise FIDO2 implementation:
- Key backed by device TPM
- Replaces password for domain/Entra ID authentication
- PIN or biometric unlocks the TPM key
- For AD: uses Kerberos PKINIT with the WHfB certificate
- For Entra ID: uses FIDO2 WebAuthn flow
YubiKey as Entra ID authenticator:
- Register YubiKey as FIDO2 security key in Entra ID
- Satisfies phishing-resistant MFA in Conditional Access policies
Passkeys
Passkeys are synced FIDO2 credentials — a discoverable credential synchronized across a user's devices through a platform authenticator (iCloud Keychain, Google Password Manager, Microsoft account).
| Property | Value |
|---|---|
| Bound to | RP ID (origin) |
| Stored | Encrypted in cloud (iCloud/Google/Microsoft) |
| Sync | Across user's devices |
| Phishing-resistant | Yes — same as hardware FIDO2 |
| Recoverable | Yes — from cloud backup |
Passkeys are the consumer-facing evolution of FIDO2 aimed at password replacement.
Attestation
Attestation is the process by which an authenticator proves it is a genuine device of a specific model/manufacturer. Relevant for enterprise deployments requiring verified hardware.
Types:
- None: no attestation (most consumer deployments)
- Self attestation: authenticator signs with its own key
- Full attestation: CA-signed certificate per device (enterprise hardware keys)
Security Boundaries and Attack Considerations
| Scenario | Is FIDO2 Bypassed? |
|---|---|
| AiTM (Adversary-in-the-Middle) phishing proxy | No — credential is bound to origin; proxy cannot relay the signed response |
| MFA fatigue (push bombing) | No — no push notification in FIDO2 |
| Token theft post-authentication | Yes — if attacker steals the session cookie/token after FIDO2 auth, they reuse that token |
| Platform authenticator on compromised device | Yes — if OS is compromised, attacker can abuse the platform authenticator on behalf of the user |
| Biometric enrollment on shared device | Risk — wrong person's biometric registered |
| SIM swap | Not applicable — FIDO2 does not use SMS |
Key insight: FIDO2 stops the phishing step but not post-authentication token theft. CAE (Continuous Access Evaluation) and short token lifetimes are the complementary controls.
Detection Signals
| Signal | What It Indicates |
|---|---|
Entra Sign-in: authenticationProtocol = fido2 | FIDO2 used — phishing-resistant auth event |
| Failed FIDO2 attempt followed by password attempt | Possible downgrade attempt or wrong device |
| New FIDO2 key registration for privileged account | Monitor closely — could be attacker adding backdoor authenticator |
| MFA method change from FIDO2 to SMS/OTP | Security downgrade — investigate |
Cross-Links
| Topic | Link |
|---|---|
| Passkeys | passkeys |
| Smart Cards | smart-cards |
| MFA Technologies | mfa-technologies |
| MFA Fatigue | mfa-fatigue |
| AiTM Phishing | aitm-phishing |