azureblog.co.uk
← cd ~/posts

Authentication strengths: requiring the right kind of MFA

Requiring MFA treats an SMS code and a passkey as equals. Authentication strengths let you say which methods are good enough for which resources.

2 min read⚠ checked 10 Dec 2025Entra ID · Conditional Access · Passkeys
Part 3 of 7 in Conditional Access from zero
Part 4 of 6 in Passwordless rollout
On this page
  1. The built-in strengths
  2. Where to use which
  3. Why phishing-resistant matters
  4. Building a policy
  5. Roll it out without locking people out

The classic grant control is Require multifactor authentication. It's satisfied by any method the user has, from a text message to a key. Attackers know this, and phishing kits that relay codes and push approvals are now commonplace.

Authentication strengths fix this by letting a policy require specific methods.

The built-in strengths

StrengthWhat it allows
MultifactorAny combination that counts as MFA, the same as the classic control
Passwordless MFAMethods that don't need a password, such as , and Authenticator phone sign-in
MFAOnly methods bound to the real sign-in site: passkeys (FIDO2), Windows Hello for Business and certificate-based authentication

You can also create custom strengths, for example allowing only specific security key models by their AAGUID.

Multifactor authenticationAny MFA combination, including SMS
Passwordless MFANo password needed
Phishing-resistant MFAPasskeys, Windows Hello for Business, certificates
Each strength is a stricter subset of the one above.

Where to use which

  • Admin roles and admin portals: phishing-resistant.
  • Sensitive apps such as finance, HR and remote access: phishing-resistant once users have passkeys.
  • Everything else: multifactor as a baseline, moving to stronger options over time.

Why phishing-resistant matters

Most modern phishing kits sit between the user and the real sign-in page. The user types their password and approves the MFA prompt, and the kit relays both, then steals the session cookie. Codes and push approvals can't tell a real site from a fake one.

Can be relayed

  • SMS and voice codes
  • Authenticator codes (OTP)
  • Push approvals the user taps without checking

Bound to the real site

  • Passkeys (FIDO2)
  • Windows Hello for Business
  • Certificate-based authentication
Why some methods can be relayed and others can't.

Passkeys and Windows Hello are cryptographically tied to the genuine sign-in domain, so a look-alike site gets nothing it can reuse.

Building a policy

  1. Create a Conditional Access policy targeting a pilot group and the apps you want to protect.
  2. Under Grant, choose Require authentication strength and pick Phishing-resistant MFA.
  3. Run it in mode and look for users who'd fail.
  4. Make sure those users can register a qualifying method, then enforce.

Roll it out without locking people out

  • Make sure users have a qualifying method before enforcing. Registration campaigns and temporary access passes help.
  • Use report-only mode to find users who'd fail.
  • Watch for guests. Their methods are registered in their home tenant, so check your cross-tenant trust settings before applying strict strengths to them.
Can I combine an authentication strength with 'Require MFA'?

There's no need. The already requires MFA of the kind you choose; pick one or the other in a policy.

What about guests?

Guests authenticate in their home tenant. Check your cross-tenant access settings to decide whether to trust their MFA before applying strict strengths to them.

This post was last checked against Microsoft's documentation over six months ago. The approach should still hold, but check the linked sources for anything that has changed before you act on it.

Next in Conditional Access from zero · part 4 of 7Named locations: getting IP ranges and countries right in Conditional Access →Next in Passwordless rollout · part 5 of 6Microsoft Authenticator now blocks jailbroken and rooted devices →

Related posts