You have rolled out Windows Hello for Business (WHfB) and FIDO2 keys. Great - but enabling a phishing-resistant method does not require anyone to use it. A user can still authenticate to your most sensitive app with a password and an SMS code, because nothing forces the stronger method. The control that closes that gap is a Conditional Access authentication strength, and it is how you turn "we support phishing-resistant auth" into "you cannot touch this resource without it."
The problem: supporting a method is not requiring it
Enabling WHfB or FIDO2 in the Authentication methods policy makes those methods available. It does not make them mandatory for any particular resource. So your finance app, your privileged admin portal, your crown-jewel data - all of it can still be reached with whatever MFA combination a user happens to have, including weak, phishable ones like password plus SMS. Availability without enforcement is a false sense of security.
Why it happens: strengths sit on top of the methods policy
An authentication strength is a Conditional Access grant control that specifies exactly which combinations of authentication methods satisfy access to a resource. It builds on the Authentication methods policy: that policy decides what users can register and use tenant-wide; the strength decides what they must use for a specific, scoped scenario - a sensitive app, a risky sign-in, an out-of-network access.
The three built-in strengths
Microsoft ships three built-in strengths you cannot modify (they are updated automatically as new methods appear). What matters is which methods each accepts:
| Method combination | MFA | Passwordless MFA | Phishing-resistant MFA |
|---|---|---|---|
| FIDO2 security key | ✓ | ✓ | ✓ |
| Windows Hello for Business or platform credential | ✓ | ✓ | ✓ |
| Certificate-based authentication (multifactor) | ✓ | ✓ | ✓ |
| Microsoft Authenticator (phone sign-in) | ✓ | ✓ | |
| Temporary Access Pass | ✓ | ||
| Password + something the user has | ✓ | ||
| SMS sign-in / Password alone |
The key line for this series: Windows Hello for Business is one of exactly three methods that satisfy the built-in Phishing-resistant MFA strength - alongside FIDO2 keys and multifactor certificate-based auth. Require that strength on a resource and you have mandated phishing-resistant auth, and WHfB is a first-class way to meet it.
How to verify
Test with a pilot account in the target group. Attempt to reach the protected resource with a weak method (password + SMS) - access should be denied with a message that a stronger method is required. Then authenticate with WHfB or a FIDO2 key - access should be granted. In the Entra Sign-in logs, the Conditional Access tab shows the authentication-strength policy as Satisfied (or not), with the method that satisfied it.
The fix: require the strength on a resource
Create a Conditional Access policy and, in the grant controls, choose Require authentication strength → Phishing-resistant MFA:
For finer control, build a custom authentication strength under Authentication methods › Authentication strengths - for example, allow only FIDO2 and even pin a specific key model by AAGUID. You can verify the built-in definitions programmatically:
Proof it worked
Success is a denied sign-in on password+SMS and a granted sign-in on WHfB/FIDO2 for the same user and resource, with the Sign-in logs naming the strength policy and the satisfying method. Your sensitive resources now demand phishing-resistant auth; everything else keeps its lighter policy.
References
- Conditional Access authentication strengths (built-in definitions)
- Create and manage custom authentication strengths
- Conditional Access grant controls
- Enable passkeys (FIDO2) in Microsoft Entra ID
Script for this post is in Daily-Tasks.