Authentication strengths in Conditional Access: requiring the right MFA in the right place
Requiring "MFA" says nothing about the method used: a text message and a FIDO2 security key satisfy the same control. Authentication strengths let Conditional Access specify which methods are acceptable, and enforce phishing-resistant MFA where it matters most.
Built-in strengths
Entra ID provides three predefined authentication strengths, which cannot be modified:
| Strength | Principle |
|---|---|
| Multifactor authentication strength | Any combination of methods that satisfies MFA, including text message or voice call. |
| Passwordless MFA strength | Passwordless methods such as Microsoft Authenticator phone sign-in, Windows Hello for Business or passkeys. |
| Phishing-resistant MFA strength | Origin-bound methods: FIDO2 passkeys, Windows Hello for Business, platform credentials, multifactor certificate-based authentication. |
The exact list of included methods changes as new methods arrive; check the current Microsoft documentation.
Custom strengths
A custom strength lets you choose exactly which combinations are allowed. Advanced options let you restrict FIDO2 keys to specific models by AAGUID, or certificate-based authentication to specific issuers or policy identifiers. This is useful to accept, for administrators, only hardware keys issued by the organisation.
Requiring phishing-resistant MFA for administrators
The priority use case is to target admin roles in a Conditional Access policy and require the phishing-resistant strength. For a successful rollout:
- Make sure every administrator has registered an eligible method before enforcement;
- Use a Temporary Access Pass to bootstrap passkey registration without relying on a weaker method;
- Start in report-only mode and review the sign-ins that would fail;
- Exclude the emergency access accounts, which are protected by other means;
- Combine with PIM: an authentication context requiring the phishing-resistant strength when the highest roles are activated.
Targeting roles is not always enough. A policy targeting directory roles only applies to PIM-eligible assignments once the role is active. Also protecting dedicated admin accounts through a group, or requiring the strength at activation, prevents a session obtained with a weak method from being used to activate a role.
Guests and cross-tenant access
For a B2B guest, MFA can be performed in your tenant or in their home tenant. Guests cannot register phishing-resistant methods in your tenant: for a guest to satisfy such a strength, your cross-tenant access settings must trust MFA performed in their home tenant, and that tenant must use a suitable method. Guests signing in with an email one-time passcode or a personal Microsoft account generally cannot meet it. Check the current Microsoft documentation for the methods supported for external users.
Common mistakes
- Combining "Require multifactor authentication" and "Require authentication strength" in the same policy, which is not possible: you have to pick one;
- Enforcing a strength for all users without a prior registration campaign;
- Forgetting shared devices or workstations where phishing-resistant methods are not available.
In the tenants we audit, administrator MFA still often relies on push notifications, or even text messages.
What an audit checks
- Policies requiring a phishing-resistant strength for privileged roles, and their state.
- The methods administrators have actually registered.
- The contents of custom strengths and any AAGUID or issuer restrictions.
- Cross-tenant trust granted to partner tenants' MFA.
- Exclusions and their justification.