What Is an External Authentication Method (EAM)?

Your organization standardized on a third-party MFA provider years ago: a hardware-token vendor, a behavioral-biometric product, a regional smart-card scheme. Then you moved identity to Microsoft Entra ID, and the question became how to keep that provider in the loop without bolting it on through a brittle federation hack. For years the answer was Conditional Access custom controls, a redirect that Entra could not actually reason about. The external authentication method is the supported replacement.

An external authentication method (EAM) is a feature in Microsoft Entra ID that lets a third-party provider satisfy the multi-factor requirement during sign-in, integrated as a first-class authentication method over OpenID Connect. Microsoft renamed the feature to External MFA at general availability in March 2026, keeping the EAM acronym in the documentation, the API type, and the admin UI. This guide covers what an EAM is, the OIDC flow that drives it, how it differs from the custom controls it retires, the claims that decide whether MFA is satisfied, and what a blue team should log. It is written for the people who configure the policy and read the sign-in logs: identity engineers, SOC analysts, and DFIR responders.

What is an external authentication method?

An external authentication method is a way to register an external MFA provider as a selectable authentication method inside Microsoft Entra ID, so the provider handles the second factor while Entra stays the identity control plane. Entra completes the first factor (typically the password), determines that another factor is required, redirects the browser to the external provider, and then validates the token the provider returns. If the token checks out, the MFA requirement is satisfied and Entra issues its own token to the user.

The point is that Entra keeps full policy evaluation and the final access decision. The external provider does not become the identity provider and does not issue the session. It proves possession or inherence of a second factor and reports the result back. Microsoft's own glossary for the feature puts it plainly: an external MFA method is "an authentication method from a provider other than Microsoft Entra ID that is used as part of authenticating a user." Entra remains the thing that grants or denies access.

That distinction matters operationally. Because the EAM is a registered method, it shows up in the Authentication methods policy alongside built-in methods like the Authenticator app, FIDO2, and certificate-based authentication. It is scoped to groups, enabled or disabled, and chosen by the user in the method picker, exactly like a native method. There is no separate parallel system to reason about. The provider is a participant in the standard Entra MFA flow, not a detour around it.

How an EAM works: the OIDC flow

An EAM is implemented on top of OpenID Connect, using the OIDC implicit flow with response_type=id_token and response_mode=form_post. The provider must publish three public endpoints: an OIDC Discovery endpoint at /.well-known/openid-configuration, an authorization endpoint, and a jwks_uri where Entra can fetch the public keys to verify token signatures. The sequence at sign-in:

1. The user signs in with a first factor (for example, a password) to an app protected by Entra ID.
2. Entra determines a second factor is required, usually because a Conditional Access policy demands MFA.
3. The user picks the external MFA method from the method picker.
4. Entra redirects the browser to the provider's authorization endpoint with a POST, passing an id_token_hint: a short-lived, expired-on-issue token that identifies the user and tenant.
5. The provider validates that the id_token_hint came from the configured Entra tenant, then reads its claims (oid and tid uniquely identify the user and tenant).
6. The provider performs whatever authentication it wants: a push, a token tap, a biometric check. It may call Microsoft Graph for more user detail.
7. The provider redirects back to Entra with a signed id_token carrying the required claims.
8. Entra validates the token's signature against the provider's published keys and checks the claims.
9. If validation succeeds, the MFA requirement is satisfied and Entra completes the sign-in.

Two design choices are worth flagging. The id_token_hint is deliberately issued in an expired state so it cannot be replayed as an authentication token; it is a hint, not a credential. And Entra caches the provider's discovery metadata and keys, refreshing roughly every 24 hours, so providers rolling signing keys must publish the new key and keep signing with the old one until the cache turns over (Microsoft suggests treating the window as up to two days).

The claims that decide whether MFA is satisfied

Entra does not take the provider's word that "the user authenticated." It checks two claims in the returned id_token: acr (the authentication context class) and amr (the authentication method). Together they prove the second factor was a genuinely different type from the first.

Entra sorts every method into one of three factor types, the classic categories:

The acr value the provider returns states which factor type was used, for example possessionorinherence. Entra then maps the amr method to its type and confirms it complements the first factor. If the first factor was a password (knowledge), the second has to be possession or inherence. A provider that returns a knowledge-only method to satisfy a knowledge-based first factor does not meet the requirement, and Entra fails the sign-in. This is what keeps an EAM honest: the provider can run any flow it likes, but the math of two distinct factor types is enforced by Entra, not trusted from the provider.

One current limitation falls out of this design. EAMs are validated against the Require multifactor authentication grant control, not against Conditional Access authentication strengths. A policy that demands a specific strength (say, phishing-resistant MFA) is not satisfied by an external method today. If your policies are built on authentication strengths, that is a gap to plan around.

EAM vs. custom controls: what it replaces

Before EAMs, the only supported way to fold a third-party provider into Conditional Access was a custom control: a JSON-defined redirect that sent the user to an external service and accepted a pass/fail back. Custom controls worked, but they were opaque. Entra could not see what method was used, could not record it as a registered authentication method, and could not reason about the result beyond "the control was satisfied." They predate the standards-based extensibility that EAMs use.

Microsoft is retiring custom controls. The two can run in parallel during migration, but adding new custom controls and editing existing ones is blocked starting September 30, 2026, with full end of life in May 2027. The recommended migration is to stand up a parallel Conditional Access policy that uses the Require multifactor authentication grant instead of the custom control grant, test it on a subset of users excluded from the custom-control policy, and switch the custom-control policy to Off once the MFA policy is confirmed satisfied by the EAM.

The blunt version: custom controls asked an outside service a yes/no question and believed the answer. An EAM makes the outside service prove, in a signed token Entra verifies, that a second factor of the right type actually happened.

Why organizations use an EAM

The feature exists for a specific shape of problem: you want Entra as the identity plane but you cannot or will not drop an existing third-party authenticator.

• Keep an investment in a specialized provider. Hardware tokens, smart cards, behavioral biometrics, or a regional authentication scheme that Entra does not offer natively can keep serving as the second factor without leaving Entra's policy engine.
• Meet sector or sovereignty requirements. Regulated environments sometimes mandate a specific accredited authenticator. An EAM lets that authenticator satisfy MFA while access decisions stay in Entra.
• Migrate off custom controls cleanly. Organizations already federating a provider through custom controls have a supported, time-boxed path off a deprecated feature.
• Centralize policy without re-platforming MFA. Conditional Access, sign-in frequency, and reporting stay in one place; the second factor is the only piece that lives outside.

What an EAM is not: it is not adaptive authentication and it does not add risk scoring of its own. Entra's Conditional Access policies still decide *when* MFA is required, based on signals like risk level, location, and device state. The EAM only changes *what* satisfies the second factor. Risk-based decisioning lives in Conditional Access and Identity Protection, not in the external method.

Risks and operational caveats

An EAM adds a dependency outside your identity provider. Treat it as one.

• The provider is a single point of failure. If the external service is down, or its application loses consent, or its app registration is deleted, users scoped to that method cannot complete MFA and sign-in fails. Plan a fallback method and monitor the provider's availability.
• Consent and registration are load-bearing. Granting admin consent to the provider's application requires a privileged role, and a method saved without consent cannot be enabled. Deleting or under-permissioning that app silently breaks every sign-in that depends on it.
• Authentication strengths are not satisfied. As above, EAMs meet Require multifactor authentication but not authentication-strength grants. A phishing-resistant-strength policy will not accept an external method today.
• Sign-in frequency is a usability and security knob. Redirecting users to the external provider too often trains them to approve prompts reflexively, which raises phishing and MFA-fatigue risk. Microsoft's own guidance is to align reauthentication with intent, not to over-prompt.
• Stale identity hygiene compounds. Orphaned and duplicate accounts that linger through poor offboarding become harder to reason about when a second factor lives in an external system. Method registration state has to be managed, including admin-side registration and de-registration for recovery.
• Windows 10 OOBE is unsupported. An external MFA-only identity cannot complete the Windows 10 out-of-box setup experience, and Microsoft has no plans to add it. Windows 11 is required for that path.

What blue teams should log and watch

An EAM is a new edge in the authentication path, which means new telemetry and new failure modes worth a detection.

Sign-in logs. Entra sign-in logs record the authentication method used and whether MFA was satisfied. A sudden rise in MFA failures scoped to the external method usually points at the provider, not the user: expired or rotated signing keys, lost app consent, or a discovery-endpoint outage. The error strings are specific (AADSTS50012 for failed external-token signature verification, AADSTS900491 for a missing service principal) and make good detection content.

Method registration changes. Adding, deleting, or re-scoping an external method, or changing the provider's app consent, are high-value audit events. An attacker who can register or weaken an authentication method can undercut MFA for a population of users. Alert on changes to the Authentication methods policy and on consent grants to the provider application.

Token validation errors. The id_token returned by the provider is validated on signature, issuer, audience, and claims. Clusters of validation failures with the same kid (key ID) typically mean a key-rollover timing problem; clusters tied to one tenant or correlation ID are worth a closer look. Capture the Correlation ID Entra emits on error; it ties the whole flow together across systems.

The factor-type check is a control, treat its failures as signal. A sign-in that fails because the provider returned a same-type factor is not just a misconfiguration; it can indicate a provider behaving unexpectedly. Wire those failures into the SIEM rather than letting them disappear into help-desk tickets.

Frequently Asked Questions

What is an external authentication method in Microsoft Entra ID?

An external authentication method (EAM) is a Microsoft Entra ID feature that lets a third-party provider satisfy the multi-factor requirement during sign-in. It is registered as a selectable authentication method over OpenID Connect, so the external provider handles the second factor while Entra keeps full policy evaluation and the final access decision. Microsoft renamed it External MFA at general availability in March 2026.

How does an EAM work?

Entra completes the first factor, decides MFA is required, and redirects the user to the external provider with a short-lived id_token_hint over the OIDC implicit flow. The provider authenticates the user with its own method and returns a signed id_token. Entra validates the token's signature and its acr/amr claims, and if the second factor is a different type from the first, the MFA requirement is satisfied.

What is the difference between an EAM and Conditional Access custom controls?

Custom controls are a legacy, opaque redirect: Entra sends the user to an external service and trusts a pass/fail answer, with no visibility into the method used. An EAM is a registered authentication method whose result Entra validates and logs, including factor-type enforcement via acr/amr claims. Custom controls are deprecated, with edits blocked from September 30, 2026, and EAM is the supported replacement.

Does an EAM replace Microsoft Entra as the identity provider?

No. The external provider only supplies and proves the second factor. Microsoft Entra ID stays the identity control plane: it evaluates Conditional Access policy, validates the returned token, and issues the session. The EAM changes what satisfies MFA, not who makes the access decision.

Does an EAM satisfy Conditional Access authentication strengths?

Not currently. External authentication methods satisfy the Require multifactor authentication grant control but are not honored by authentication-strength grants, including the built-in MFA strength. Policies relying on a specific strength, such as phishing-resistant MFA, are not met by an EAM today, so plan policy design around that limitation.

What protocol does an EAM use?

OpenID Connect (OIDC), built on OAuth 2.0. Entra uses the OIDC implicit flow with response_type=id_token and response_mode=form_post. The provider must expose an OIDC Discovery endpoint ending in /.well-known/openid-configuration, an authorization endpoint, and a jwks_uri that publishes the signing keys Entra uses to verify the returned token.

What should a SOC monitor for an EAM?

Watch Entra sign-in logs for spikes in MFA failures tied to the external method (often a provider key-rollover or lost-consent problem, with errors like AADSTS50012 or AADSTS900491), and audit any change to the Authentication methods policy or to the provider application's admin consent. Because the external provider is a single point of failure and a method-registration change can weaken MFA for many users, both deserve alerting.

The bottom line

An external authentication method lets Microsoft Entra ID use a third-party MFA provider as a first-class, OIDC-based authentication method, while Entra keeps policy evaluation and the access decision. It replaces the deprecated custom controls with something Entra can actually verify: a signed token whose acr/amr claims prove a second factor of the right type, instead of a yes/no answer taken on trust.

It is generally available, it is the migration path off custom controls before their September 2026 edit cutoff and May 2027 end of life, and it does exactly one job: deciding what satisfies the second factor. It does not do risk scoring, it does not satisfy authentication strengths yet, and it introduces an external dependency that a blue team has to monitor. Treat the provider as a single point of failure, alert on method-registration and consent changes, and the EAM becomes a clean way to keep a specialized authenticator inside a modern identity plane.