Replace Conditional Access custom controls with external MFA in Entra ID

To keep third-party MFA working after Conditional Access custom controls retire, add your provider as an external MFA method in the Microsoft Entra Authentication methods policy, change each affected Conditional Access policy to use the standard Require multifactor authentication grant, and move users across group by group before deleting the custom control. Since September 2026 you can no longer create or edit custom controls, and full retirement is scheduled for early 2027, with message center post MC1422061 giving May 2027. External MFA also produces a real MFA claim, so it works with Privileged Identity Management, risk-based Conditional Access and Intune device registration, which custom controls never supported.

Who this is for and what you will have at the end

This guide is for administrators whose Conditional Access policies use a custom control to send users to a third-party MFA service such as Duo. If none of your policies has a custom control under Grant, no action is needed.

At the end you will have:

• An inventory of every Conditional Access policy that references a custom control.
• Your provider registered as an external MFA method with admin consent granted.
• A pilot group signing in through external MFA under a policy that requires MFA.
• A phased plan to move everyone else, and a safe order for removing the custom control.

Why custom controls are being retired

A custom control redirects the user to an external service and, when that service reports success, lets the Conditional Access flow continue. Microsoft Entra ID never treated the result as MFA. Microsoft documents that custom controls can't be used with:

• ID Protection automation that requires multifactor authentication
• Self-service password reset
• Satisfying multifactor authentication claim requirements
• Sign-in frequency controls
• Privileged Identity Management
• Intune device enrollment
• Cross-tenant trusts
• Joining devices to Microsoft Entra ID

External MFA closes most of these gaps. Microsoft's migration guide compares them:

Timeline

Because editing a custom control means deleting it and creating a new one, and creation is no longer allowed, don't delete a custom control you still depend on. Keep it unchanged until the migration is finished.

Prerequisites

• Microsoft Entra ID P1 or P2.
• Authentication Policy Administrator to configure the external MFA method.
• Privileged Role Administrator (or higher) to grant admin consent to the provider's application.
• Conditional Access Administrator to create and edit the Conditional Access policies.
• From your provider: the Application ID (usually a multitenant app registration), the Client ID that identifies requests from Microsoft Entra ID, and the OIDC Discovery URL, which must use https and end with /.well-known/openid-configuration.
• A pilot security group and your emergency access accounts identified.

Values from Duo

Duo's documentation calls its application Microsoft Entra ID: External MFA; applications created before March 2026 keep the old name, Microsoft Entra ID: External Authentication Methods. After you authorize it in the Duo Admin Panel, the application page shows the Client ID, Discovery Endpoint and App ID to copy into Microsoft Entra ID. Duo documents a separate Client ID (Guest/Cross-Tenant) value for tenants that need guest or cross-tenant users. Other providers publish equivalent values in their own setup guides.

Step 1: Inventory policies that use custom controls

In the Microsoft Entra admin center, browse to Entra ID > Conditional Access > Policies and review the Grant controls of each policy. For each policy that uses a custom control, record its name and ID, targeted users and groups, targeted apps, the custom control it references and any conditions such as locations or device platforms.

Microsoft publishes a Graph PowerShell query that finds them for you:

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 result and track migration status per policy. In larger tenants the number of affected policies is easy to underestimate.

Step 2: Add the external MFA method

1. Sign in to the Microsoft Entra admin center as at least an Authentication Policy Administrator.
2. Browse to Entra ID > Authentication methods and select Add external MFA. Older documentation shows this as Add external method on the Policies page.
3. Enter the Name, Client ID, Discovery Endpoint and App ID from your provider. Users see the name in the method picker, it must be unique, and it can't be changed later.
4. Request admin consent and sign in with an account that holds at least Privileged Role Administrator. Review the permissions the provider's application requests and select Accept.
5. Under Enable and target, enable the method and include only your pilot group at first. Exclude emergency access accounts.
6. Select Save.

If you can't grant consent yet, you can save the method but not enable it. Once enabled, any sign-in with the method fails if the provider application lacks consent.

The same configuration in PowerShell

Microsoft documents a Graph PowerShell equivalent, which needs Policy.ReadWrite.AuthenticationMethod:

Connect-MgGraph -Scopes "Policy.ReadWrite.AuthenticationMethod"
 
$params = @{
    "@odata.type"        = "#microsoft.graph.externalAuthenticationMethodConfiguration"
    displayName          = "Contoso External MFA"
    state                = "enabled"
    appId                = "<provider-app-registration-id>"
    openIdConnectSetting = @{
        clientId     = "<provider-client-id>"
        discoveryUrl = "https://provider.example.com/.well-known/openid-configuration"
    }
    includeTargets       = @(
        @{
            "@odata.type" = "microsoft.graph.authenticationMethodTarget"
            id            = "<test-group-object-id>"
            targetType    = "group"
        }
    )
}
 
New-MgPolicyAuthenticationMethodPolicyAuthenticationMethodConfiguration -BodyParameter $params

Admin consent for the provider's application is still required.

Step 3: Register the pilot users

Users in scope can register in three ways:

• Security info: at https://mysignins.microsoft.com/security-info, select Add sign-in method, choose External Auth methods and complete the provider's challenge.
• Registration wizard at sign-in: users who have other methods may need I want to set up a different method > External Auth methods.
• Administrator: in Users > All users, open the user, select Authentication methods > Add authentication method > External authentication method, pick the method and save. The user doesn't need to register again.

Check what a pilot user has registered:

Connect-MgGraph -Scopes "UserAuthenticationMethod.Read.All"
 
Get-MgUserAuthenticationMethod -UserId "adele@contoso.com" |
    Format-Table Id, @{ N = 'Type'; E = { $_.'@odata.type' } }

Users enabled for external MFA aren't included in the authentication method registration reports, so use this per-user check or Microsoft's group report script from the migration guide rather than the Registration tab.

Step 4: Create the replacement Conditional Access policy

1. In Entra ID > Conditional Access > Policies, select New policy and name it, for example Pilot - Require MFA via external MFA.
2. Under Users, include the pilot group and exclude emergency access accounts.
3. Under Target resources, select the same apps as the custom control policy.
4. Mirror any conditions from the old policy, such as client apps, device platforms or locations.
5. Under Grant, select Grant access and Require multifactor authentication.
6. Set the policy to Report-only and select Create.

Don't use Require authentication strength for these users. External MFA isn't compatible with authentication strengths, including the built-in MFA strength, so a strength-based policy can't be satisfied by it. The same applies to any risk policy you build with an authentication strength, as described in migrating Entra ID Protection risk policies to Conditional Access.

New policies can take up to a few hours to take effect because of caching and replication. Have a pilot user sign in, then open Sign-in logs, find the sign-in and check the Conditional Access tab for the new policy's report-only result. When it looks right, edit the policy and change it from Report-only to On.

Step 5: Move the pilot group off the custom control

A user in both policies has to satisfy MFA and the custom control, and is sent to the provider twice. Avoid that:

1. Open the existing custom control policy.
2. Under Users > Exclude, add the pilot group and save.
3. In Entra ID > Conditional Access, open What If, select a pilot user and a target app, and run it. The custom control policy must not apply; the new MFA policy must.

Then test real sign-ins: from a new device or browser, from a noncompliant device and from a blocked location if your policies use those conditions, and with an expired MFA session. In the sign-in logs you should see a successful MFA result, your external method as the authentication method, and the new policy granting access.

Step 6: Roll out and remove the custom control

Microsoft suggests four phases:

For each phase, add the next groups to the external MFA method's targets, add them to the MFA policy and exclude them from the custom control policy. For the last phase, target all users:

Connect-MgGraph -Scopes "Policy.ReadWrite.AuthenticationMethod"
 
$configId = "<external-mfa-configuration-id>"
$params = @{
    "@odata.type"  = "#microsoft.graph.externalAuthenticationMethodConfiguration"
    includeTargets = @(
        @{
            "@odata.type" = "microsoft.graph.authenticationMethodTarget"
            id            = "all_users"
            targetType    = "group"
        }
    )
}
 
Update-MgPolicyAuthenticationMethodPolicyAuthenticationMethodConfiguration `
    -AuthenticationMethodConfigurationId $configId `
    -BodyParameter $params

When everyone is migrated:

1. Disable the custom control Conditional Access policy.
2. Monitor sign-in logs for one to two weeks.
3. Delete the custom control policy.
4. Delete the custom control definition from the Custom controls list in Conditional Access. A control can only be deleted when no policy uses it.

Keep the old policy disabled, not deleted, for at least two weeks as a rollback option.

Behaviour changes users will notice

• Method picker: if system-preferred authentication is enabled and users have other methods, those appear first and users must choose the external method. Duo's guide lists optional steps, such as turning off the registration campaign, system-preferred MFA or Microsoft Authenticator, if you want Duo to be the only option.
• Sign-in frequency: unlike custom controls, external MFA honours sign-in frequency, so users are sent back to the provider when MFA freshness requires it. Microsoft discourages very frequent reauthentication.
• Windows 10 setup: Windows 10 doesn't support external MFA during the out-of-box experience, so devices set up with an identity that has only external MFA fail. Microsoft's answer is Windows 11.
• Bypass in Duo: Duo documents that users who would bypass Duo, for example through bypass status or a policy that allows access without 2FA, get an error and can't finish signing in. Review Duo bypass rules before rollout.
• Password reset: Duo notes that SSPR users still need at least one built-in Microsoft method enabled.

Troubleshooting

Microsoft Entra ID caches the provider's discovery metadata and keys and refreshes the cache every 24 hours, so a provider-side key change can take time to be picked up. It also abandons an authentication attempt about five minutes after redirecting to the provider. For any error, keep the Correlation ID from the error page for support.

Checklist

• Every custom control policy found and recorded.
• Custom controls left untouched until migration completes.
• External MFA method added, consented, enabled for the pilot group.
• Pilot users registered and verified.
• Replacement policy uses Require multifactor authentication, not an authentication strength.
• Pilot excluded from the custom control policy; What If confirms the result.
• Phased rollout completed and external MFA targeted at all users.
• Custom control policy disabled, monitored, then deleted with the control definition.

For how third-party MFA fits a wider access design, see the zero trust remote access architecture.

References

• Migrate from custom controls to external MFA in Conditional Access
• Custom controls in Microsoft Entra Conditional Access
• How to manage external MFA in Microsoft Entra ID
• Microsoft Entra external MFA method provider reference
• Overview of Conditional Access authentication strengths
• MC1422061: Retirement of Custom Controls in Conditional Access and migration to External MFA
• Duo for Microsoft Entra ID External MFA