Microsoft has set a ticking clock for every organization using third-party multifactor authentication (MFA) with Entra ID Conditional Access. Starting September 30, 2026, you will no longer be able to add or edit custom controls—the mechanism that currently links Duo, Okta, and similar providers to Entra. Full retirement follows in May 2027, but the practical cut-off for change management is that September date. If your identity team hasn’t begun migrating to the new External MFA framework, now is the time.

What Actually Changes for Your Organization

Custom controls have been the glue connecting external MFA providers to Entra Conditional Access for years. They are now deprecated and being replaced by External MFA (previously called External Authentication Methods), a feature that reached general availability earlier this year.

The critical difference is how each method interacts with Entra’s policy engine. A custom control redirects a user to the third-party service but does not tell Entra that MFA was fulfilled in a native way. External MFA, by contrast, satisfies the standard Require multifactor authentication grant directly. That means sign-in logs reflect the MFA event correctly, risk-based Conditional Access works, and integrations like Privileged Identity Management (PIM) and Intune device registration—which never worked with custom controls—become supported.

The timeline leaves no ambiguity. From September 30, 2026, you cannot create new custom controls or modify existing ones. Existing controls will continue to function until the final retirement in May 2027, but they become frozen. If your application landscape changes, if you need to add new user groups, or if your MFA provider alters its integration, you will not be able to update the policy. Any troubleshooting or adjustment will be impossible without a migration path already in place.

What It Means for You—Split by Role

For Identity and Access Administrators

If your tenant currently uses custom controls, you must lead a migration project. The good news is that External MFA is not a radical departure. It still works with the same providers, but the configuration changes from a per-policy custom control to a tenant-wide authentication method registration followed by standard Conditional Access policies that use the “Require MFA” grant.

Your to-do list is long, but not technically complex: inventory every policy that references a custom control, work with your MFA vendor to get their External MFA metadata, register that provider as an external authentication method in Entra, craft replacement policies, and then migrate users in phases. The trickiest part will be avoiding a double-prompt scenario—if a user is still targeted by the old custom control policy and the new MFA policy simultaneously, they’ll get two MFA challenges.

Microsoft’s documentation stresses that large tenants may have dozens or even hundreds of Conditional Access policies. Exporting and tracking migration status per policy is essential to avoid underestimating effort.

For End Users

In a well-managed migration, users should notice little change. They’ll still see a prompt from their existing MFA provider—Duo, Okta, or whatever they use—when signing into Office 365 or other protected apps. The difference will be that Entra correctly logs the MFA event, which may reduce unexpected re-prompts and improve support when something goes wrong.

For Developers and Application Owners

Applications relying on custom controls for authentication flows won’t break, but any automation or scripts that depend on the old policy structure should be updated. If you have custom code that reads Conditional Access policies or sign-in logs, test the new response formats during the pilot phase.

How We Got Here

Custom controls were always a stopgap. They let Entra admins call an external provider as part of a sign-in flow, but the integration was shallow. Microsoft’s own documentation highlights the shortcomings: the MFA claim was not native, sign-in logs showed generic custom-control events rather than specific MFA methods, and several advanced Entra features—risk-based Conditional Access, PIM, Intune device registration—simply didn’t work with them.

In 2023, Microsoft announced External Authentication Methods in public preview, later renamed External MFA, promising a more native experience. The GA release earlier this year came with a clear migration timeline and a stark warning: custom controls are on the way out. This fits a broader pattern of Entra security tightening, including the mandate for MFA for all admin portals and stronger default Conditional Access policies.

The Windows Forum discussion among Entra admins has echoed one key point: don’t treat this as a last-minute project. The September 2026 editing freeze means you cannot afford to wait until 2027 to adapt. The deadline community conversations repeatedly highlight is not the retirement date, but the loss of editability.

What to Do Now: A Practical Migration Plan

You cannot just flip a switch. The migration requires methodical preparation, and Microsoft recommends starting with a thorough audit.

1. Inventory Your Custom Control Policies

Use the Entra admin center or Microsoft Graph PowerShell to list every Conditional Access policy that uses a custom control. For each, note the targeted users, groups, cloud apps, conditions, and the specific provider. Microsoft provides a handy PowerShell snippet:

Connect-MgGraph -Scopes "Policy.Read.All"
Get-MgIdentityConditionalAccessPolicy -All | Where-Object {
    $_.GrantControls -and
    (@($_.GrantControls.CustomAuthenticationFactors) | Where-Object {
        $_ -is [string] -and $_.Trim().Length -gt 0
    }).Count -gt 0
} | Select-Object Id, DisplayName, State, @{
    N = "CustomAuthFactors"
    E = { ($_.GrantControls.CustomAuthenticationFactors | Where-Object {
        $_ -is [string] -and $_.Trim().Length -gt 0
    }) -join "," }
}

Export the results and track progress policy by policy.

2. Get Your Provider Ready

Confirm with your MFA vendor that they support External MFA in production. You’ll need three pieces of information:
- Application ID (App ID): The provider’s app registration ID in Microsoft Entra (typically multitenant).
- Client ID: Identifies Entra requests to the provider.
- OIDC Discovery URL: The HTTPS endpoint for OpenID Connect metadata (e.g., https://provider.example.com/.well-known/openid-configuration).

Not every provider has completed the transition. If yours hasn’t, put pressure on them or have a contingency plan. Microsoft’s documentation clearly states that custom controls cannot be edited after September 2026, so a lagging vendor could leave you stuck.

3. Register the External Authentication Method

In the Entra admin center (or via Graph), go to Protection > Authentication methods > Policies and add a new external method. Provide the required metadata and grant admin consent for the provider’s application. Initially, target only a small test group—do not enable for all users.

This step does not touch your existing Conditional Access policies. It merely tells Entra about the provider and allows users to register for it.

4. Register Test Users

Ensure your pilot users are registered for the external method. You can check registration status with PowerShell or in the admin center, and register them manually if necessary. If you enabled the preview earlier, users might already be registered; verify this.

5. Create a Replacement Conditional Access Policy

This is the core of the migration. Build a new Conditional Access policy that mirrors the scope of your existing custom control policy but uses the standard Require multifactor authentication grant instead of a custom control. Do not use “Require authentication strength”—External MFA does not yet support authentication strength policies.

Set it to Report-only mode initially. Use the What If tool to confirm that the new policy would apply correctly and that the old custom control policy would not also apply to your test users (you’ll later exclude them from the old policy).

6. Pilot and Validate

Move a small group of test users out of the old custom control policy (by excluding them) and enable the new policy for them. Have them sign into targeted apps from different devices, browsers, and network conditions. Check the sign-in logs to confirm:
- The MFA result shows success.
- The authentication method is your external MFA provider (not “custom control”).
- The new Conditional Access policy evaluated and granted access.

Test failures too: revoked sessions, provider timeouts, and network interruptions. Document what the user sees, which logs you have, and how you’d roll back.

7. Roll Out in Phases

Microsoft’s guidance recommends a phased approach:
1. Phase 1: Test group (5–10 users)
2. Phase 2: IT or early adopters (50–100 users)
3. Phase 3: Department by department
4. Phase 4: All users, then remove the old custom control policy.

At each phase, expand the targeting of both the external MFA authentication method and the replacement Conditional Access policy. Monitor sign-in logs continuously.

8. Remove the Old Custom Control Policy

Once all users are migrated and you’ve gone 1–2 weeks without issues, disable the old custom control policy. Do not delete it immediately; keep it disabled as a rollback safety net. Only delete it after your organization’s change management window has passed and you are confident in the new setup.

Outlook: A More Coherent MFA Future

After May 2027, custom controls will stop working entirely. Any tenant still relying on them will face authentication failures. The External MFA framework is the permanent replacement, and it brings Entra’s MFA capabilities in line with modern zero-trust expectations. We can expect Microsoft to tighten integration further—support for authentication strengths is a likely next step—and to continue phasing out legacy workarounds.

One wildcard is vendor readiness. Not all third-party MFA providers may have production-ready External MFA integrations by the 2026 edit freeze. If you depend on a smaller or slower vendor, your risk is higher. The prudent move is to start early, test thoroughly, and have a fallback plan, even if that plan means switching providers.

The Windows Forum community has been clear-eyed about the timeline: treat September 30, 2026, as your change-control deadline, not a retirement reminder. The migration itself is not technically daunting for a well-prepared identity team, but it requires diligent planning and an understanding that after that date, custom controls are set in stone. Don’t find yourself stuck in 2027 with an uneditable, unsupported authentication dependency.