Phishing-resistant authentication hinges on a simple principle: the authenticator must cryptographically verify the origin it's communicating with. Standard MFA methods like TOTP fail this test. A user can be tricked into entering a valid code on a malicious site, which is then proxied to the real service in an Adversary-in-the-Middle (AiTM) attack. FIDO2, leveraging the WebAuthn and CTAP2 protocols, directly counters this threat.

During registration with a relying party like Entra ID, the authenticator (a security key or a platform authenticator like Windows Hello) generates a new public-private key pair specifically for that origin. The origin is a combination of protocol, hostname, and port. The public key is sent to Entra ID and associated with the user's account, while the private key is stored securely on the authenticator and is marked as non-exportable. The private key never leaves the device.

During authentication, Entra ID sends a challenge (a random nonce). The browser's WebAuthn API forwards this challenge and the current origin to the authenticator via the CTAP2 protocol. The authenticator checks its internal storage for a private key associated with that specific origin. If a match is found, it signs a data structure containing the challenge and the origin data with the corresponding private key. This signed assertion is sent back to Entra ID, which verifies it using the user's stored public key. An adversary's site will have a different origin, so the authenticator will not find a matching key and the authentication will fail before any secrets are revealed. This cryptographic binding of the credential to the origin is what makes it phishing-resistant.

Windows Hello for Business (WHfB) functions as a platform authenticator, achieving its security through deep integration with the device's hardware, specifically the Trusted Platform Module (TPM). It's not just a PIN or biometric gesture; it's a key-based authentication system where the private key is protected by the TPM.

When a user provisions WHfB, the process is similar to FIDO2 registration. The Windows client generates an asymmetric key pair. The private key is generated within and protected by the TPM's security boundary. This key is device-bound and non-exportable. The user's gesture (PIN or biometric) doesn't travel over the network; it simply unlocks the private key within the TPM for a signing operation. The public key is registered with Entra ID.

When deploying phishing-resistant MFA, architects must decide between hardware-bound credentials and synced passkeys. Hardware-bound keys, like FIDO2 security keys or WHfB with a TPM, offer the highest level of security by ensuring the private key never leaves a specific piece of hardware. This prevents key cloning or exfiltration. However, it introduces lifecycle management challenges. If a user loses their laptop or security key, the credential is lost and must be re-provisioned.

Synced passkeys, stored in a password manager or a platform's keychain (like Apple's iCloud Keychain), prioritize convenience and recoverability. The passkey is synced across a user's trusted devices, making it resilient to single-device loss. While the underlying cryptography is the same as hardware-bound keys, the security model shifts. The protection of the private key now depends on the security of the passkey provider's ecosystem and the user's account recovery settings for that provider. This can be a viable and user-friendly option, but it requires trusting the provider's synchronization and security mechanisms. The choice depends on the organization's threat model and user base.

Understanding these architectural differences allows for a nuanced deployment of phishing-resistant credentials tailored to specific security and usability requirements.