azureblog.co.uk
← cd ~/posts

External MFA is GA: third-party MFA without giving up Conditional Access

Entra ID now officially supports external MFA providers, with Entra still evaluating policy and risk. It's the proper replacement for custom controls.

2 min read⚠ checked 25 Feb 2026Entra ID · Security · What's new
On this page
  1. What's better than custom controls
  2. Moving over
  3. Testing before you switch
  4. Planning for the future

Some organisations have a good reason to use a third-party provider: an existing investment, specialist hardware tokens, or regulatory requirements. Until now, the main way to plug one into Entra was custom controls in , which had real limitations. Most importantly, Entra didn't treat the result as genuine MFA.

UserEntra IDExternal MFA providerSigns in with password1Conditional Access requiresMFARedirects to provider3Completes provider's challenge4Returns MFA result5Access granted; MFA recordedin sign-in log6
With external MFA, Entra stays in charge of the policy decision.

External MFA, now generally available, makes a third-party provider a proper authentication method. Entra still evaluates Conditional Access and risk, and the external provider performs the second factor.

What's better than custom controls

  • Completing external MFA satisfies an MFA requirement in Conditional Access, like any other method.
  • It's configured in the authentication methods policy, alongside your other methods.
  • Sign-in logs show the external method, so troubleshooting isn't guesswork.

Custom controls (old)

  • Didn't satisfy 'Require MFA'
  • Configured as a special control in Conditional Access
  • Hard to see in logs

External MFA (now)

  • Counts as MFA in Conditional Access
  • Lives in the authentication methods policy
  • Shows clearly in sign-in logs

Moving over

  1. Check your provider supports Entra external MFA.
  2. Set it up as a method in the authentication methods policy and target a pilot group.
  3. Update Conditional Access policies that reference the custom control so they require MFA instead.
  4. Retire the custom control once everyone has moved.
Worth asking: is the third-party provider still needed? With now built into Entra, some organisations will find they can retire it entirely.

Testing before you switch

  • Pilot with IT users who can tell you exactly what they saw.
  • Check sign-in logs show the external method in the authentication details.
  • Test the edge cases: mobile apps, desktop Office apps, and the first sign-in on a new device.
  • Keep the old custom control in place for everyone else until the pilot is clean.

Planning for the future

External MFA is useful while you depend on a third-party provider. But adding Entra-native passkeys gives you sign-in with one fewer system to run and pay for. Many organisations will use external MFA as a bridge while they adopt passkeys.

Can users have external MFA and Entra methods at the same time?

Yes. External MFA is one method in the authentication methods policy, so users in scope can also register Entra-native methods such as passkeys.

Does external MFA count as phishing-resistant?

Check how your provider and Entra classify it before using it with that require phishing resistance. Don't assume a hardware token makes the whole flow phishing-resistant.

What happens if the provider is down?

Users who only have the external method can't complete MFA. Keep excluded and consider a second registered method for critical users.

Sources

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.

Related posts