Phishing-Resistant Authentication: The Regulatory Baseline Boards Cannot Ignore

Why Legacy MFA Is Dead

In 2024 and 2025, adversary-in-the-middle (AiTM) phishing kits like EvilGinx, Modlishka, and Muraena moved from proof-of-concept to commodity tooling. These kits proxy the entire authentication session - including the MFA prompt - between the victim and the legitimate identity provider. The user completes MFA. The attacker captures the resulting session token. Push notifications, SMS OTPs, and TOTP codes are all equally vulnerable because they authenticate the user to the IdP, not the user to a specific origin.

Microsoft's own telemetry reported that token theft attacks increased over 100% year-on-year in their 2025 Digital Defence Report. The response from every major framework - NIST 800-63B, CISA Zero Trust Maturity Model, and the UK NCSC - is the same: deploy phishing-resistant authentication that cryptographically binds the credential to the origin.

In the Microsoft ecosystem, that means two options: FIDO2 security keys and Windows Hello for Business (WHfB).

How Phishing Resistance Works

Both FIDO2 and WHfB use asymmetric cryptography bound to origin. During registration, a public-private key pair is created. The private key never leaves the authenticator (hardware key or TPM). During authentication, the identity provider sends a challenge that includes the origin (e.g., login.microsoftonline.com). The authenticator signs the challenge only if the origin matches what was registered.

An AiTM proxy sitting at login-microsoftonline.evil.com sends a challenge with its own origin. The authenticator refuses to sign because the origin does not match. The attack fails at a cryptographic level, not a human judgment level.

FIDO2 Security Keys: Characteristics

FIDO2 keys (YubiKey 5 Series, Feitian BioPass, Google Titan) are external hardware authenticators that communicate via USB, NFC, or Bluetooth.

Strengths:

• Platform-independent - Works on Windows, macOS, Linux, iOS, Android, and ChromeOS. Critical for organisations with mixed device fleets.
• No device dependency - The credential lives on the key, not the device. Users can authenticate from any machine, including shared workstations and kiosks.
• Physical possession requirement - The key must be physically present and touched/biometrically activated, providing strong proof of presence.
• Shared device scenarios - Ideal for frontline workers, call centres, and healthcare environments where multiple users share a single device.

Deployment Considerations:

• Cost - Enterprise-grade keys cost £40-£80 each. Budget for two per user (primary + backup). For a 500-person organisation, that is £40,000-£80,000 in hardware alone.
• Logistics - Keys must be physically distributed, registered per-user, and replacements provisioned when lost. Build a key management process before deployment.
• User friction - Users must carry a physical object. Loss rates typically run 5-10% annually.
• Registration - Users register keys in the Entra ID Security Info portal or via bulk provisioning using the FIDO2 provisioning APIs.

Entra ID Configuration:

Navigate to Entra ID > Security > Authentication methods > FIDO2 security key. Enable and scope to target groups. Set attestation enforcement to "Required" to restrict to approved key manufacturers. Configure key restrictions:

Enforce key restrictions: Yes
Restrict specific keys: Allow
AAGUIDs: [list your approved manufacturer GUIDs]

Windows Hello for Business: Characteristics

WHfB uses the device's Trusted Platform Module (TPM) to store the private key, authenticated via biometric (face/fingerprint) or a device-specific PIN.

Strengths:

• Zero additional hardware cost - Uses existing device TPM chips. No keys to purchase or distribute.
• Superior user experience - Face recognition or fingerprint is faster than inserting a USB key.
• No physical object to lose - The credential is bound to the device.
• Seamless SSO - Integrates natively with Windows sign-in, providing a single gesture for both device unlock and Entra ID authentication.

Deployment Considerations:

• Device-bound - The credential only works on the device where it was registered. If the device is unavailable, the user cannot authenticate with WHfB. You must plan a secondary method.
• Windows-only for device sign-in - While WHfB can be used as a passkey in browsers cross-platform via QR code linking, the core device sign-in experience is Windows-only.
• Hardware requirements - Requires TPM 2.0, which is mandatory for Windows 11 but may be absent on older hardware. Biometric sensors (IR camera for face, fingerprint reader) are needed for biometric unlock.
• Cloud Kerberos Trust - The recommended deployment model for hybrid environments. Eliminates the need for certificate infrastructure or key trust with domain controllers.

Configuration via Intune:

Create a Windows Hello for Business policy under Devices > Configuration > Create > Settings catalog:

Use Windows Hello for Business: Enable
Require Security Device (TPM): Yes
Minimum PIN Length: 6
Facial Features Use Enhanced Anti-Spoofing: Yes
Enable PIN Recovery: Yes

For Cloud Kerberos Trust, deploy via Group Policy or Intune: Use cloud trust for on-premises authentication: Enabled.

Decision Framework for Regulated Environments

| Factor | FIDO2 Keys | WHfB | |--------|-----------|------| | Shared/kiosk devices | Excellent | Not suitable | | Cost sensitivity | Higher upfront | Minimal | | User experience | Good (physical tap) | Excellent (biometric) | | Mixed OS estate | Excellent | Windows-primary | | Regulatory evidence | Physical key audit trail | TPM attestation logs | | Disaster recovery | Backup key in safe | Temporary Access Pass | | Frontline/shift workers | Ideal | Poor (device-bound) |

For financial services under DORA, the typical recommendation is FIDO2 keys for privileged administrators (strong physical possession evidence for regulators) and WHfB for the general knowledge-worker population (superior user experience, lower cost).

For healthcare with shared workstations, FIDO2 is the only viable option.

For professional services firms with a homogeneous Windows fleet, WHfB with Cloud Kerberos Trust provides the best balance of security and usability.

Conditional Access Authentication Strength

Regardless of which authenticator you choose, enforce it via Conditional Access Authentication Strength policies rather than legacy per-user MFA settings:

1. Navigate to Entra ID > Security > Authentication methods > Authentication strengths
2. Create a custom strength requiring "FIDO2 security key" and/or "Windows Hello for Business"
3. Reference this strength in your Conditional Access policies under Grant > Require authentication strength

This ensures users cannot fall back to push notifications or SMS when accessing regulated resources. Emergency access accounts should use strong passwordless methods such as FIDO2 security keys and be tested regularly from designated secure workstations.

The Transition Path

Do not attempt a big-bang migration. Deploy in waves:

1. Pilot (2 weeks): IT team and security team register FIDO2 keys and WHfB. Validate SSO, VPN, and application compatibility.
2. Privileged users (4 weeks): All Global Admins, Exchange Admins, SharePoint Admins, and Intune Admins must use phishing-resistant MFA. Enforce via CA policy scoped to directory roles.
3. General population (8 weeks): Roll out WHfB via Intune autopilot. Enforce authentication strength for all cloud apps. Monitor sign-in logs for fallback authentication methods.
4. Decommission legacy MFA (2 weeks): Disable SMS, voice, and push notification methods in the Authentication Methods policy. Remove legacy per-user MFA settings via PowerShell:

Get-MgUser -All | ForEach-Object {
    Update-MgUser -UserId $_.Id -Authentication @{
        PhoneMethods = @()
    }
}

The goal is a tenant where every human authentication uses a cryptographically origin-bound credential. That is the baseline. Everything else is legacy.