Microsoft's External MFA Changes the IAM Equation

The choice that no longer has to be a choice

For years, organizations have faced a structural trade-off in identity and access management. On one side: Microsoft Authenticator and Entra ID, tightly woven into the Microsoft 365 ecosystem and backed by Conditional Access policies that govern who gets in, from where, and under what conditions. On the other: third-party MFA providers like Cisco Duo, Ping Identity, and RSA — mature, cross-platform, and often already embedded in environments that predate an organization's Microsoft investment. Choosing one meant compromising the other.

Microsoft tried to bridge the gap in 2020 with Custom Controls, a mechanism that let Conditional Access policies hand off authentication to a third-party provider. But Custom Controls ran on a parallel track. They didn't connect to the standard "Require MFA" grant control, which meant policies had to be written and maintained differently depending on which MFA method was in play. It was a workaround, not integration.

The result: companies running two conditional access frameworks side by side — one for Microsoft-native MFA, one for everything else — with all the policy drift, audit complexity, and operational overhead that entails.

What changed on March 24, 2026

External Authentication Methods (EAM) reached general availability. Unlike Custom Controls, EAM is built on OpenID Connect — the same protocol that underpins modern identity federation. The flow works like this: Entra ID evaluates a Conditional Access policy and determines that MFA is required. Instead of routing to Microsoft Authenticator, it redirects the user to a third-party provider via OIDC. The provider authenticates the user, returns a signed token, and Entra validates it. The MFA requirement is satisfied the same way it would be with Microsoft Authenticator. No special policy. No parallel track.

What this means for E5 and Microsoft-heavy shops

E5 already includes Entra ID P2, which means Conditional Access, Identity Protection, and Privileged Identity Management are part of the license you're already paying for. EAM doesn't change what E5 includes. What it changes is how much of that investment you can leverage while still using a third-party MFA provider.

EAM separates the policy framework from the MFA method. Before, if you wanted third-party MFA to participate fully in Conditional Access — including risk-based triggers, PIM activation, and sign-in frequency controls — you couldn't. Custom Controls gave you a partial bridge, but it was always a second-class integration. Now the method is decoupled from the engine.

Before EAM, the argument for full IAM platforms from vendors like Okta or Ping was partly about feature parity. You needed their policy engine because Microsoft's wouldn't work with their MFA. That argument weakens when Microsoft's policy engine works natively with third-party credentials. It doesn't eliminate the case for those platforms entirely — there are legitimate reasons to centralize identity management outside of Microsoft — but it removes one of the strongest forcing functions.

Now organizations can right-size: use a third-party provider as the credential and authentication layer, and Entra ID as the policy engine. Whether that translates to actual cost reduction depends on existing contracts, deployment complexity, and whether you need capabilities that sit outside of what EAM covers. But the option is now real in a way it wasn't before.

What EAM still does not cover

Outcomes for security and IT teams

If you're on E5 with Microsoft Authenticator only

If you're running a third-party IAM platform alongside Microsoft

If you're evaluating IAM vendors now

The bottom line

EAM removes the structural choice between Conditional Access and third-party MFA. For the first time, organizations can use Microsoft's policy engine — the one they're already paying for with E5 — and plug in whatever MFA provider fits their environment. That's not a minor configuration change. It's a shift in how the identity market works.

For E5 customers, the cost of adding a third-party MFA layer drops. You no longer need a competing policy engine just to use a competing authenticator. The MFA provider becomes a component, not a platform commitment. That changes vendor leverage and contract negotiations in a meaningful way.

Gaps remain, and they matter. Windows device login is out of scope. Authentication Strengths — Microsoft's framework for phishing-resistant MFA — doesn't recognize external methods. On-prem and hybrid scenarios aren't covered. These aren't edge cases for most enterprises; they're core requirements. Any deployment plan needs to account for them explicitly.

The direction, though, is clear. Microsoft is building the identity policy plane that third parties plug into, rather than competing with them at every layer. If you're renewing an IAM contract in the next 12 months and you're on E5, model what EAM changes before you sign. The math may be different now.

Related

• Okta — Vendor Profile
• CyberArk — Vendor Profile
• Ping Identity — Vendor Profile
• Yubico — Vendor Profile
• Microsoft Sentinel Cost Analysis