The problem with “strong” authentication
Most organizations think they have strong authentication because they enabled MFA. They have not. Here is what attackers do to bypass common MFA methods:
Attack SMS OTP Auth App Push Notif WHFB HSK
─────────────────────────────────────────────────────────────────────────
Phishing (fake login) ✅ Steal ✅ Steal ✅ Fatigue ❌ ❌
SIM swap ✅ Steal ❌ ❌ ❌ ❌
MFA fatigue (push spam) N/A N/A ✅ Accept ❌ ❌
Man-in-the-middle proxy ✅ Relay ✅ Relay ✅ Relay ❌ ❌
Real-time phishing kit ✅ Relay ✅ Relay ✅ Relay ❌ ❌
Token theft (session) ✅ ✅ ✅ ✅* ✅**Token theft is a post-authentication attack, mitigated by token binding and CAE (Continuous Access Evaluation), not by the authenticator itself.
The key insight: SMS, authenticator apps, and push notifications are all phishable. An attacker with a real-time phishing proxy (like Evilginx2 or Modlishka) sits between the user and the real login page, captures the OTP or push approval, and replays it instantly.
Phishing-resistant authenticators — Windows Hello for Business (WHFB) and FIDO2 Hardware Security Keys (HSK) — are fundamentally different. They cannot be phished because the credential is cryptographically bound to the origin (the real website URL). A fake login page gets nothing useful.
How phishing resistance works: the FIDO2 protocol
Both WHFB and hardware security keys use the FIDO2/WebAuthn protocol. Here is why it is unphishable:
Registration (one-time setup)
1. User visits login.microsoftonline.com
2. Server sends a challenge + its origin (login.microsoftonline.com)
3. Authenticator creates a key pair:
- Private key → stored in TPM (WHFB) or security key (HSK)
- Public key → sent to server
4. Private key is BOUND to this specific originAuthentication (every login)
1. User visits login.microsoftonline.com
2. Server sends a challenge
3. Browser passes the challenge + ACTUAL page origin to authenticator
4. Authenticator checks: does the origin match what was registered?
- login.microsoftonline.com → ✅ signs the challenge
- login-microsoftonline.com → ❌ refuses (different origin)
- evilproxy.attacker.com → ❌ refuses (different origin)
5. Signed challenge is sent to server
6. Server verifies with stored public keyThe critical difference: the authenticator verifies the origin independently. Even if the user clicks a phishing link and types their username on a fake page, the authenticator will not sign a challenge for the wrong domain. The private key never leaves the device.
Phishing proxy flow with traditional MFA:
User → fake-login.com → real-login.com → MFA prompt → User enters OTP → Attacker captures OTP ✅
Phishing proxy flow with FIDO2:
User → fake-login.com → real-login.com → FIDO2 challenge → Authenticator checks origin → MISMATCH ❌Windows Hello for Business (WHFB)
WHFB turns the user’s Windows device into a phishing-resistant authenticator using the built-in TPM (Trusted Platform Module).
How it works
┌──────────────────────────────────────────┐
│ Windows Device │
│ │
│ ┌──────────────┐ ┌─────────────────┐ │
│ │ Biometric │ │ TPM 2.0 │ │
│ │ (Face/Print) │→│ Private Key │ │
│ │ or PIN │ │ (never leaves)│ │
│ └──────────────┘ └────────┬────────┘ │
│ │ │
│ Signs challenge │
│ bound to origin │
└──────────────────────┬───────────────────┘
│
▼
Entra ID / AD FS
verifies signature
with stored public keyAuthentication factors with WHFB:
- Something you have — the device with its TPM-stored private key
- Something you are — biometric (face recognition, fingerprint)
- Or something you know — PIN (device-local, not transmitted)
The PIN is not a password. It never leaves the device, is not sent to any server, and only unlocks the local TPM key. A stolen PIN is useless without the physical device.
Deployment with Entra ID
# Intune: Enable WHFB via device configuration profile
# Settings Catalog → Windows Hello for Business
# Key settings:
# Use Windows Hello for Business: Enabled
# Use a Trusted Platform Module: Required
# Minimum PIN length: 6
# Biometrics: Enabled
# Use certificate for on-premises authentication: Enable (hybrid)Conditional Access policy to require WHFB:
{
"displayName": "Require phishing-resistant MFA",
"conditions": {
"applications": {
"includeApplications": ["All"]
},
"users": {
"includeUsers": ["All"]
}
},
"grantControls": {
"operator": "OR",
"builtInControls": [],
"authenticationStrength": {
"id": "00000000-0000-0000-0000-000000000004"
}
}
}The authentication strength ID 00000000-0000-0000-0000-000000000004 is the built-in “Phishing-resistant MFA” policy in Entra ID, which allows only WHFB and FIDO2 security keys.
WHFB deployment models
Cloud-only:
Device → Entra ID → Done
Simplest. No on-premises infrastructure needed.
Hybrid (certificate trust):
Device → Entra ID + AD → Certificate → On-prem resources
For orgs with on-premises Active Directory and resources.
Hybrid (cloud Kerberos trust):
Device → Entra ID → Cloud Kerberos → On-prem resources
Newer model. No PKI infrastructure needed.
Recommended for new hybrid deployments.Hardware Security Keys (HSK)
For scenarios where WHFB is not available — shared devices, non-Windows platforms, privileged accounts that need a separate physical factor.
FIDO2 security key options
Key Interface Biometric Price Best for
────────────────────────────────────────────────────────────────────
YubiKey 5 NFC USB-A + NFC No ~$50 Most users
YubiKey 5C NFC USB-C + NFC No ~$55 Modern laptops
YubiKey Bio USB-C Fingerprint ~$95 High-security
YubiKey 5 Nano USB-A (tiny) No ~$50 Always-in laptop
Feitian BioPass USB-A/C Fingerprint ~$60 Budget biometric
Google Titan USB-C + NFC No ~$30 Google ecosystem
SoloKeys USB-A/C No ~$30 Open sourceRegistration flow
// WebAuthn registration (browser-side)
const credential = await navigator.credentials.create({
publicKey: {
challenge: serverChallenge,
rp: {
name: "Contoso",
id: "login.contoso.com" // Origin binding happens here
},
user: {
id: userId,
name: "alice@contoso.com",
displayName: "Alice"
},
pubKeyCredParams: [
{ alg: -7, type: "public-key" }, // ES256 (ECDSA P-256)
{ alg: -257, type: "public-key" } // RS256 (RSA)
],
authenticatorSelection: {
authenticatorAttachment: "cross-platform", // Security key
residentKey: "required", // Discoverable credential
userVerification: "required" // PIN or biometric
},
attestation: "direct"
}
});Enterprise deployment at scale
# Entra ID: FIDO2 security key restriction policy
fido2_policy:
enabled: true
allow_self_service_setup: true
enforce_attestation: true
key_restrictions:
enforcement_type: "allow" # Only allow specific keys
allowed_aaguids:
# YubiKey 5 Series
- "cb69481e-8ff7-4039-93ec-0a2729a154a8" # YubiKey 5 NFC
- "ee882879-721c-4913-9775-3dfcce97072a" # YubiKey 5C NFC
- "d8522d9f-575b-4866-88a9-ba99fa02f35b" # YubiKey Bio
# Feitian
- "77010bd7-212a-4fc9-b236-d2ca5e9d4084" # BioPass FIDO2Key lifecycle management
Provision → Admin distributes keys or users self-register
2 keys per user (primary + backup)
Store backup in a safe location
Active use → Daily authentication
Key PIN protects against theft
Track last-used timestamps
Lost/stolen → User reports via self-service portal
Admin disables key in Entra ID immediately
Backup key used until replacement arrives
Replacement → New key registered
Old key credential revoked
Attestation ensures only approved models
Off-boarding → All keys deregistered from the user's account
Physical keys returned and factory resetConditional Access: enforcing phishing resistance
The real power comes from Conditional Access policies that require phishing-resistant methods:
Policy: "Require phishing-resistant MFA for all users"
├── Applies to: All users
├── Target: All cloud apps
├── Grant: Require authentication strength → Phishing-resistant MFA
└── Effect: Only WHFB and FIDO2 keys can authenticate
Policy: "Require phishing-resistant MFA for admins — always"
├── Applies to: Directory roles (Global Admin, etc.)
├── Target: All cloud apps
├── Conditions: Any location, any device
├── Grant: Require authentication strength → Phishing-resistant MFA
├── Session: Sign-in frequency → Every time
└── Effect: Admins must tap their key on every login
Policy: "Block legacy authentication"
├── Applies to: All users
├── Target: All cloud apps
├── Conditions: Client apps → Legacy authentication clients
├── Grant: Block access
└── Effect: No IMAP, SMTP, POP3 — these bypass MFA entirelyPhased rollout strategy
Phase 1 (Week 1-2): Admins and IT staff
→ Require phishing-resistant MFA for privileged roles
→ Distribute 2 security keys per admin
→ Enable WHFB on IT devices
Phase 2 (Week 3-6): High-value targets
→ Finance, HR, Legal, C-suite
→ Security keys for shared device users
→ WHFB for personal device users
Phase 3 (Week 7-12): All employees
→ WHFB auto-enrollment via Intune
→ Security keys available on request
→ Legacy MFA methods disabled
Phase 4 (Ongoing): External/guest users
→ Require FIDO2 for partner access
→ Passkeys for customer-facing appsWHFB vs Hardware Security Keys: when to use which
Scenario WHFB HSK
──────────────────────────────────────────────────
Personal Windows device ✅ Optional
Shared/kiosk Windows device ❌ ✅
macOS / Linux / ChromeOS ❌ ✅
Mobile-only users ❌ ✅ (NFC)
Privileged admin accounts ✅ ✅ (both!)
Frontline workers (shared PCs) ❌ ✅
Remote workers on managed devices ✅ Backup
High-security environments ✅ ✅ (both!)
Users who lose things ✅ 🤷 (expensive)
Budget-conscious org ✅ 💸 ($50/user × 2)Best practice: WHFB as the primary method for Windows users + a hardware security key as backup. For non-Windows or shared devices, hardware security keys are the primary method.
The ROI of phishing resistance
Average cost of a successful phishing attack: $4.76M (IBM 2025)
Cost of deploying WHFB to 1,000 users: $0 (built into Windows)
Cost of 2 YubiKeys per 1,000 users: $100,000
Phishing success rate before: 12-30% of targeted users
Phishing success rate with FIDO2: 0%
The math is not complicated.Beyond cost avoidance:
- Faster logins — biometric or tap vs typing OTP codes
- No password resets — passwordless eliminates the #1 helpdesk call
- Compliance — meets NIST AAL3, CISA zero-trust, EU NIS2 requirements
- User satisfaction — faster, simpler authentication
Common objections and answers
“What if users lose their security key?” → Every user gets 2 keys. Backup in a drawer. Emergency TAP (Temporary Access Pass) in Entra ID for key replacement.
“WHFB PIN is just a password.” → No. The PIN never leaves the device, is not transmitted over the network, and only unlocks the local TPM. Stealing the PIN is useless without the physical device.
“Our legacy apps don’t support FIDO2.” → Use Entra ID Application Proxy or SSO federation. The user authenticates to Entra with FIDO2, and Entra handles the legacy protocol translation.
“It’s too expensive.” → WHFB is free on Windows 10/11 with TPM. One prevented breach pays for 10,000 security keys.
My take
Phishing is the number one initial access vector for breaches. Not zero-days, not sophisticated exploits — just fake login pages. Every organization that has not deployed phishing-resistant authenticators is choosing to leave their front door open.
WHFB and FIDO2 security keys are not future technology. They are available today, work with Entra ID, Azure AD, Okta, Google Workspace, and most modern identity providers. The deployment complexity is manageable, and the security improvement is categorical — not incremental.
Start with your admins this week. Expand from there. There is no good reason to wait.
Implementing zero-trust authentication for your organization? Get in touch for identity security consulting, phishing-resistant MFA rollout, and Conditional Access architecture.
