Entra ID Custom Controls Retirement External Authentication Methods: Migration Guide Before September 2026

Entra ID Custom Controls Retirement External Authentication Methods: What's Changing and Why

The Entra ID Custom Controls retirement external authentication methods deadline is now fixed. Per Microsoft Learn's own Conditional Access documentation, creating new custom controls or editing existing ones stops being possible starting September 2026, with full retirement scheduled for early 2027. A Microsoft 365 Message Center notice, MC1422061 (“Microsoft Entra ID: Retirement of Custom Controls in Conditional Access and migration to External MFA”), confirms the same September 2026 freeze and pins full retirement to May 2027, when custom controls stop being supported entirely. External Authentication Methods — the standards-based capability Microsoft now brands External MFA — is the only supported replacement.

Custom controls were never a mainstream, generally-available Conditional Access feature — Microsoft Learn describes them as "a preview capability" from the start. When a policy used one, a signed-in user's browser redirected to an approved third-party service, completed authentication there, and redirected back to Entra ID, which verified the response before continuing the sign-in flow. That indirection is exactly what's being retired: the same outcome — third-party MFA enforced inside Conditional Access — now runs through a native, GA authentication method instead of a redirect-and-verify handshake.

How Custom Controls Work — and Why External MFA Replaces Them

The retirement isn't cosmetic. Microsoft's own migration guidance lists concrete functional gaps that custom controls have always had, gaps External MFA closes:

Source: Microsoft Learn, "Migrate from custom controls to external MFA in Conditional Access."

Microsoft Learn's custom controls documentation lists the same gap from the other direction: custom controls explicitly can't be used to satisfy Identity Protection's automated MFA requirement, Microsoft Entra self-service password reset, MFA claim requirements, sign-in frequency controls, PIM role activation, Intune device enrollment, cross-tenant trust, or device join. A tenant relying on a custom control for "MFA" has, in practice, been running a look-alike that several other Entra features can't see as MFA at all — which is a meaningful gap next to native methods covered in our review of passwordless MFA registration changes.

There's also a naming wrinkle worth flagging so it doesn't cause confusion mid-migration: the replacement shipped in preview as "external authentication methods," then reached general availability under the name External MFA (External Multifactor Authentication), per Microsoft's GA announcement on the Entra blog. Microsoft Learn, the admin center UI, and Graph API objects (externalAuthenticationMethodConfiguration) still use "external authentication method" terminology internally, so expect to see both names depending on where you're looking.

Detection: Find Every Conditional Access Policy Using Custom Controls

Before touching anything, inventory which Conditional Access policies actually use a custom control today. Per Microsoft's migration guidance, this can be done two ways:

Portal: Sign in to the Microsoft Entra admin center as at least an Authentication Policy Administrator, browse to Protection > Conditional Access > Policies, and review each policy's Grant controls for a custom control reference. For each match, record the policy name and ID, targeted users/groups and cloud apps, the custom control provider referenced, and any conditions (locations, device platforms).

Microsoft Graph PowerShell (faster for large tenants — Microsoft's guidance notes some environments have dozens or hundreds of Conditional Access policies to check):

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 "," }
}

Source: Microsoft Learn, "Migrate from custom controls to external MFA in Conditional Access."

Export the results before you start migrating. If a policy has no custom control reference, per Microsoft's own guidance no action is needed on it — don't spend migration effort on unaffected policies.

Remediation: Migrate to External Authentication Methods Before the Deadline

Once you have the inventory, Microsoft's migration guidance lays out a phased path. Prerequisites first: a Microsoft Entra ID P1 or P2 license, the Authentication Policy Administrator role (Global Administrator also works), Privileged Role Administrator to grant admin consent for the provider's application, and metadata from your external MFA provider — its Application ID, Client ID, and OIDC Discovery URL.

1. Register the external MFA provider. In the admin center, go to Protection > Authentication methods > Policies > Add external method, supply the display name (unchangeable after creation), Client ID, App ID, and Discovery Endpoint, then grant admin consent for the provider's application. The same configuration is available via the Graph API (POST /policies/authenticationMethodsPolicy/authenticationMethodConfigurations with @odata.type: "#microsoft.graph.externalAuthenticationMethodConfiguration") or PowerShell's New-MgPolicyAuthenticationMethodPolicyAuthenticationMethodConfiguration, for teams automating the rollout.
2. Target a test group only — not all users — when enabling the method, and register those test users for the external authentication method before moving on.
3. Build a new Conditional Access policy in Report-only mode that uses the standard Require multifactor authentication grant (not the custom control), scoped to the same cloud apps and conditions as the legacy policy, targeting the test group, and excluding break-glass and emergency access accounts.

🚨 Danger: Microsoft's guidance is explicit that External MFA is not yet compatible with "Require authentication strength" — only the standard "Require multifactor authentication" grant satisfies it. Building the test policy on an authentication-strength requirement will silently fail to work as expected.

4. Verify in Report-only mode first using the sign-in logs' Conditional Access tab, confirm the policy evaluates as expected and the MFA method shows as your external provider, then flip the policy to On.
5. Exclude the test group from the legacy custom-control policy and confirm with the What If tool that only the new policy applies to them, and that test sign-ins are actually challenged by the external provider rather than the custom control.
6. Roll out in phases — test group, then IT/early adopters, then department by department, then all users — expanding both the external MFA method's target group and the new Conditional Access policy's scope at each stage.
7. Retire the legacy policy last, not first. Disable (don't delete) the old custom-control policy and monitor sign-in logs for one to two weeks before deleting it and removing the custom control definition, keeping a rollback path available in case of regressions.

How EtcSec Detects This

EtcSec's Conditional Access checks flag the gap this retirement forces into the open: CA_NO_MFA_REQUIREMENT surfaces cloud apps and user scopes with no Conditional Access policy actually requiring MFA — exactly the state a tenant falls into if a custom-control policy quietly stops functioning and nothing replaces it. MFA_NOT_ENFORCED_ADMINS and MFA_NO_STRONG_METHOD catch privileged accounts and weak-method configurations that a broken or unmigrated custom control can mask, since custom controls never reflected as a native MFA claim in the first place. CA_POLICY_REPORT_ONLY flags policies — including the Report-only test policy this migration recommends — that were never flipped to enforced, so a paused migration doesn't slip through unnoticed.