Microsoft Entra External MFA: Migrate Before September 30, 2026

Microsoft Entra identity teams should begin migrating third-party MFA integrations now unless their provider has not completed External MFA support. September 30, 2026—not the May 2027 end-of-life date—is the practical change-control deadline: Microsoft says existing custom controls cannot be added or edited from September 30, 2026, and they reach end of life in May 2027.
Microsoft Learn’s migration guidance confirms that External MFA is generally available and replaces the custom-control model. As WindowsForum users discussing the retirement have emphasized, the important operational change is not merely a new authentication option. External MFA lets third-party authentication participate in Entra’s standard Conditional Access MFA decision, while the old provider-specific controls are approaching an editing freeze.

Treat September 30 as the Change-Control Deadline​

The distinction between end of life and loss of editability matters. May 2027 is the final retirement milestone, but September 30, 2026 is when custom controls become frozen configuration.
A control may require changes because an application portfolio expands, an acquisition introduces new user populations, exclusions need redesigning, or the provider changes its integration. After the cutoff, administrators cannot assume they will be able to repair the old configuration by editing or recreating its custom control.
The recommended decision is therefore conditional but not neutral: migrate before September 30 if the provider is ready and the tenant can complete a controlled pilot. Wait only when the provider cannot supply a supported External MFA integration or testing has identified a specific blocker with an owner and remediation plan.
WindowsForum’s coverage of broader Conditional Access changes reinforces the need for deliberate planning. Recent user discussions have focused on tighter enforcement, more consistent resource coverage, administrative MFA, and tenant registration requirements. Those changes are not evidence that a particular External MFA deployment will work, but they show why identity teams should avoid carrying an uneditable authentication dependency into an increasingly policy-driven environment.
This is not a last-week portal task. Microsoft identifies Entra ID P1 or P2 licensing, appropriate administrative roles, provider information, application consent, and Conditional Access configuration as prerequisites. Organizations should verify the precise least-privileged roles required for their tenant and task against current Microsoft documentation rather than assuming a named role assignment from an older runbook.

Translate the Grant Control, Not Just the Provider​

A custom control and External MFA are not interchangeable grant-control labels.
For the replacement policy, administrators use Require multifactor authentication under Grant. External MFA can satisfy that standard Conditional Access requirement and allow Entra to recognize that MFA was completed. By contrast, the old custom-control model redirects the user to the third-party service without integrating the result into Entra in the same native way.
Microsoft’s supplied migration material supports translating the provider-specific custom control to Require multifactor authentication. It does not establish how every External MFA provider or deployment interacts with authentication-strength policies. Do not redesign authentication-strength requirements based on an assumption; validate that question separately against the provider’s current Microsoft-supported implementation and the latest Entra documentation.
Conditional Access evaluates every applicable policy. Consequently, the migration must account for overlapping assignments so that pilot users are not unintentionally subjected to both the old custom control and the new MFA requirement.
A controlled sequence is:

1. Inventory every Conditional Access policy that references the custom control, including users, groups, resources, locations, platforms, conditions, and exclusions.
2. Obtain the provider’s production External MFA information and complete the required application-consent process.
3. Configure the external method for a limited pilot population.
4. Create a separate Conditional Access policy that reproduces the intended scope of the old policy but uses Require multifactor authentication.
5. Evaluate the proposed assignments and conditions before enforcement. Report-only evaluation, sign-in logs, and Conditional Access planning tools can be used where available, but administrators should confirm their current behavior in Microsoft documentation.
6. Enable the new policy for the pilot while ensuring the old custom-control policy does not also target those users.
7. Test representative sign-ins, failures, exclusions, and recovery actions.
8. Expand assignments in controlled groups only after the results match the intended policy design.

The exact portal navigation can change, so the runbook should point to Microsoft’s current External MFA and Conditional Access instructions rather than relying on a permanent menu path.

Confirm Prerequisites Before Starting the Pilot​

The following table separates Microsoft-stated prerequisites from the operational state needed for a reversible migration.

Prerequisite	What must be ready	Basis
License	Entra ID P1 or P2 for the affected deployment	Microsoft prerequisite
Required roles	Appropriate administrative access for authentication-method configuration, provider consent, and Conditional Access changes	Microsoft prerequisite; verify the current least-privileged roles for each task
Provider metadata	Production application ID, client ID, and HTTPS OIDC discovery endpoint, plus required tenant consent	Microsoft External MFA setup information
Pilot group	A limited, identifiable population representing important user and application paths	Recommended change-control practice
New grant control	A separate policy using Require multifactor authentication	Microsoft migration model
Rollback state	Old policy retained, assignments documented, and a tested way to remove the pilot from the new policy	Recommended change-control practice

The pilot group should be large enough to exercise the real environment but small enough to reverse safely. Include representative employees, administrators where appropriately controlled, guests, devices, applications, network locations, and exception paths. Do not infer that one successful employee sign-in proves that every collaboration or administrative workflow is ready.

Provider Readiness Decides Whether “Now” Really Means Now​

The presence of an External MFA option in Entra does not prove that a particular provider has a production-ready integration. Microsoft’s setup information calls for an application ID, client ID, an HTTPS OIDC discovery endpoint, and the required tenant consent.
Ask the provider to confirm that its production service supports Entra External MFA rather than relying on its legacy custom-control compatibility or preview documentation. The provider should be able to supply the required configuration and an accountable production support route.
Detailed claims about token fields, issuer behavior, authorization endpoints, signing-key overlap, or Microsoft metadata caching should come from current Microsoft and provider documentation. They should not be inserted into a migration runbook as universal requirements without verification.
Provider interruption, denied authentication, timeout, and signing-certificate change should nevertheless be included as test scenarios. The same applies to troubleshooting across Entra and provider records. These are prudent dependency tests, not claims that Microsoft guarantees a particular failure mode or telemetry-correlation workflow.
For each scenario, record:

• What the user sees.
• Which support team owns the first response.
• What logs are available.
• How the pilot is paused.
• How users are returned to the previous assignment.
• Who approves resumption.

That evidence is more useful than a generic statement that the integration “supports OIDC.”

Design Exceptions and Rollback Before Enforcement​

Exception handling should be explicit before the pilot. Test emergency-access identities, service and automation identities, guests, tenant-to-tenant collaboration, administrative workflows, and applications that may use noninteractive authentication.
These are recommended test categories, not Microsoft-documented predictions about how every External MFA provider will behave. A successful result depends on the tenant’s assignments, applications, authentication flows, and provider implementation.
For each exceptional identity, determine whether it performs interactive sign-in, which policies apply, and whether an existing exclusion remains justified. If a flow cannot complete the new requirement, assign an owner to modernize it, redesign the policy scope, or approve a narrow and documented exception.
Emergency-access handling also needs a tenant-specific procedure. Verify exclusions and access through controlled testing, but do not assume a particular exclusion mechanism or emergency workflow is universally prescribed for External MFA. The objective is to prevent both accidental lockout and an undocumented bypass that survives the migration.
Rollback should operate at the pilot-assignment level rather than through an improvised tenant-wide change. Keep the old policy available during the reversible phase, document every assignment change, and ensure pilot users are covered by exactly the intended policy set.
If the pilot fails:

1. Stop further expansion.
2. Remove or disable the new policy assignment for the affected pilot population.
3. Restore the documented old-policy assignment where appropriate.
4. Confirm the resulting policy evaluation and perform a controlled sign-in.
5. Record the failure, owner, and retest criteria.

After production migration, disable the old policy before deleting it. Monitor for a locally approved validation period based on the organization’s sign-in volume, support coverage, and risk tolerance. Microsoft’s supplied material does not establish a universal one-to-two-week monitoring period, so that duration should be governed by the organization’s change process.

Use a Deadline Runbook​

A practical runbook puts irreversible actions last:

1. Confirm P1 or P2 licensing, appropriate administrative access, provider production support, and required consent.
2. Export or otherwise preserve the custom-control policy inventory and document every assignment and exception.
3. Record the existing state needed for rollback.
4. Configure External MFA for a limited test population using current Microsoft and provider instructions.
5. Create the replacement policy with Require multifactor authentication.
6. Evaluate policy scope before enforcement and resolve unintended overlaps.
7. Test browsers, devices, network conditions, revoked sessions, administrative workflows, guests, exceptions, provider interruption, and recovery.
8. Expand by controlled groups while reviewing Entra sign-in evidence and available provider records.
9. Complete migration with enough time to investigate failures before custom controls become uneditable.
10. Disable the old policy only after the new configuration is stable; delete it only after the organization’s validation and rollback requirements have been met.

This sequence preserves options. It also responds directly to the concern raised in WindowsForum’s External MFA discussion: the move is valuable because it removes a longstanding divide between third-party MFA and Entra’s standard MFA policy control, but only if teams migrate while they can still manage the old configuration.

Frequently Asked Questions​

Can existing custom controls continue working after September 30, 2026?​

Microsoft’s precise timeline is that existing custom controls cannot be added or edited from September 30, 2026, and reach end of life in May 2027. That statement should not be expanded into a guarantee about uninterrupted operation during the intervening period.

Does External MFA satisfy a normal Conditional Access MFA requirement?​

Yes. External MFA is designed to satisfy the standard Require multifactor authentication grant after Entra validates the external provider’s response.

Can External MFA satisfy an authentication-strength policy?​

The supplied Microsoft material does not establish that point. Validate authentication-strength compatibility against current Microsoft documentation and the provider’s supported implementation rather than assuming equivalence with the standard MFA grant.

Should the old policy be deleted as soon as users migrate?​

No. Retain a reversible state during rollout, disable the old policy after the replacement is stable, and delete it only after the organization’s approved validation period. Do not rely on a universal one-to-two-week rule.

When is waiting justified?​

Waiting is justified when the provider does not yet support production External MFA or a controlled pilot reveals a documented blocker. The blocker should have an owner, remediation plan, and completion date.
For ready providers, the goal is straightforward: finish discovery, pilot, policy translation, exception testing, and rollback validation while custom controls can still be managed. Treat the September milestone as change control—not merely another retirement reminder.

---

References​

1. Primary source: learn.microsoft.com
   
   

   Migrate from custom controls to external MFA in Conditional Access - Microsoft Entra ID | Microsoft Learn

   Learn how to migrate from custom controls to external multifactor authentication in Microsoft Entra Conditional Access.

   learn.microsoft.com
2. Independent coverage: techcommunity.microsoft.com
   
   https://techcommunity.microsoft.com/blog/microsoft-entra-blog/microsoft-entra-id-security-updates-what-organizations-need-to-do-now/4522024/replies/4538036
3. Primary source: WindowsForum
   
   

   Microsoft Entra External MFA (OIDC): Policy Control Kept, Custom Controls Retire 2026 | Windows Forum

   Microsoft has quietly removed one of the biggest identity-management frictions for enterprise customers: the inability to cleanly use third-party MFA...

   windowsforum.com