Over the past year I've come across a surprising number of Entra ID tenants that still rely on legacy custom controls for third-party MFA, usually as a stopgap to integrate providers like Duo, Okta or RSA. With external authentication methods (EAM) now officially available in Entra ID, you can finally meet Conditional Access MFA requirements with a third-party solution in a cleaner and more resilient way. The migration isn't a single click, though, and the details decide whether your security posture actually improves or whether you open new gaps.

External authentication methods plug third-party MFA into the Entra ID sign-in

External authentication methods are Microsoft's current way of connecting third-party MFA directly to the Entra ID sign-in flow. Conditional Access (CA) supports them fully, so you no longer need shaky custom controls. The configuration lives in the Entra admin center under Entra ID → Authentication methods → Policies → Add external method. There you can register vendors like Duo, Okta, RSA or your own in-house provider, as long as they support the necessary protocol and the External Authentication Method Provider integration (details on the requirements).

In practice, this means an external MFA vendor can now satisfy the CA 'require MFA' condition on its own, without a fragile custom control in between. Conditional Access treats EAM as a genuine "multi-factor authentication" event, so a policy such as 'require MFA for all users' still works when the second factor comes from EAM. Custom controls are only a stopgap at this point, and Microsoft has been pushing tenants to migrate for a while now (see the docs).

Migrating from custom controls comes with a few pitfalls

On the technical side the migration is quite doable, but every provider has its own quirks. The usual sequence is to register the third-party system as a provider in the Entra admin center and enable it, then switch your Conditional Access policies over to the EAM method. Keep in mind that user registration for the external method usually doesn't happen automatically. Users have to be onboarded in the third-party system so the EAM claim ends up in the Entra ID token.

One mistake I see again and again is leaving the old Entra ID MFA registrations as they are. Users can then sign in with native Entra methods (the Authenticator app, for example) as well as with the external provider. If you want to prevent that, go through the authentication methods policy carefully and adjust it. In tenants with a lot of custom control history, a full audit of existing policies and claims usually pays off, because otherwise weak authentication can slip through unnoticed.

Tip: Plan enough time for proper pilot testing. If registration isn't clean, failed EAM onboarding tends to show up as cryptic errors ("Method not available"). Pilot groups bring the real problems to light early.

EAM satisfies Conditional Access MFA but has clear limits

EAM does fulfil the MFA claim for CA, but there are some limitations I've had to explain to customers more than once:

  • EAM is not phishing resistant (unlike FIDO2 or certificate-based methods) unless the provider adds its own anti-phishing features.
  • Authentications through EAM don't yet appear in all Entra ID reports, so the audit trail is limited.
  • User registration happens externally. Entra ID neither orchestrates nor reports on onboarding to the third-party provider.
  • According to the current announcement, combining EAM with advanced controls (like "require two of..." or "authentication strengths") is limited, so native methods are still the better choice for the most granular CA scenarios.

Without phishing resistance and with only basic reporting, EAM is clearly a bridge and not a long-term target. When you onboard new users, think about going straight to passkeys, FIDO2, or at least Microsoft Authenticator with number matching. That gives you better security and more insight over time.

EAM sets the MFA claim within the authentication flow

From the Conditional Access point of view, EAM sets the MFA claim once the external provider has completed a successful challenge. The sequence looks like this:

sequenceDiagram
    participant User as "[User]"
    participant Entra as "[Entra ID]"
    participant EAM as "[EAM Provider]"
    User->>Entra: "[Sign in]"
    Entra->>EAM: "[Request external factor]"
    EAM-->>User: "[MFA challenge]"
    User-->>EAM: "[Response]"
    EAM-->>Entra: "[Success/failure]"
    Entra->>Entra: "[CA evaluation]"
    Entra-->>User: "[Allow/deny access]"

Figure: Entra ID calls the external authentication method during sign-in.

Because of this, most standard CA policies ("require MFA", country blocks and so on) keep working as long as your third-party provider is healthy. If the EAM vendor has an outage, however, your users are locked out. That's why I always recommend keeping a break-glass admin account with native MFA (see emergency access).

PowerShell shows which users have EAM registered

As of June 2026, Entra ID still doesn't offer detailed reporting on which users have EAM registered as an MFA method. The authentication methods reporting blade gives you a basic overview, but not much more. For anything deeper you'll need PowerShell 7 with the Microsoft Graph PowerShell SDK (Global Reader or Authentication Policy Administrator required):

# PowerShell 7, Microsoft.Graph.AuthenticationMethods module
Connect-MgGraph -Scopes 'UserAuthenticationMethod.Read.All'
Get-MgUserAuthenticationMethod -All
# Look for methods of type external or vendor-specific

The output isn't as detailed as for FIDO2 or Authenticator yet, but for spot checks during a pilot it's usually enough.

Native MFA remains the better long-term option

From what I've seen, EAM makes sense as a transition layer if your third-party MFA still delivers value or a move to native methods isn't realistic in the short term. For new, cloud-centric environments, or wherever security is the priority, phishing-resistant methods (passkeys, FIDO2, certificate-based MFA) are the better choice by a wide margin. They hold up against attacks like AiTM phishing, and they also fit more cleanly into Conditional Access, lifecycle management and compliance reporting. For more on this, read Migrating to the Authentication methods policy in Entra ID.

EAM is a migration tool, not a permanent solution. If you're planning the switch, audit your old custom controls, set up EAM pilot groups and aim for a native, phishing-resistant MFA baseline as the end state.