Conditional Access Custom Controls: External MFA or Entra MFA?

If a Conditional Access policy in your tenant still grants access through a custom control that hands users to Duo or another MFA provider, that grant can go unopened once the provider is wired in, and it now has an end date. Microsoft’s custom controls article opens its notice with “Custom controls are deprecated.” Duo’s own custom control documentation carries the matching notice: “Microsoft will prevent creation of new custom controls in September 2026 as part of the custom controls deprecation process.” The open question for the identity team is which path each policy takes: keep the provider through External MFA, or move those users to Entra’s built-in methods. This guide sets out what each path satisfies, what External MFA still leaves out, and how to move policy by policy with a rollback in place.

What Microsoft Is Retiring, and When

If you are planning around a date, work from Microsoft’s own words, because it has published a month and a season, not a day. The custom controls article reads: “Adding new custom controls and editing existing custom controls will not be allowed starting September 2026. Full retirement is scheduled for early 2027. Start planning your migration now.” Duo’s custom control page says its original Microsoft Azure Active Directory application can no longer be created or edited in Duo after September 30, 2026, and adds: “Existing users of the Duo CA custom control should migrate to Duo External MFA before the Microsoft custom controls retirement date.” Until full retirement, an existing custom control can no longer be edited, so any change to how those policies prompt users goes through the replacement. Microsoft’s separate retirement of its own SMS and voice methods is a different change with its own date, which i3solutions covers in a separate guide.

How to Tell Whether Your Tenant Uses Custom Controls

If the team cannot say whether any policy calls the provider, start with the inventory, because the answer can be zero. Microsoft’s migration guide is direct: “This guide is relevant only if your organization currently uses custom controls. If you don’t use custom controls, no action is needed.” The same guide lists what to record for each affected policy (its name and ID, the users and groups and cloud apps it targets, the custom control provider it references, and its conditions) and publishes a Microsoft Graph PowerShell query that returns the Conditional Access policies whose grant controls carry a custom control. Its advice on scale is worth taking literally: “Large tenants might have dozens or hundreds of Conditional Access policies. Export the results and track migration status per policy to avoid underestimating migration effort.” That export becomes the migration register: one row per policy, the path chosen for it, and the date it moved.

What External MFA Fixes That Custom Controls Could Not

When an internal control or an auditor asks whether sign-ins under these policies count as multifactor authentication, the custom control has been the weak point. Microsoft’s Microsoft-managed policies FAQ states: “Custom controls don’t satisfy multifactor authentication claim requirements. If your organization uses custom controls you should migrate to external authentication methods, the replacement of custom controls.” External MFA changes that result. Duo’s External MFA documentation states: “Duo external MFA is fully recognized as a multifactor authentication method in Entra ID, satisfying MFA policy requirements.” The same page notes that Microsoft took the feature, previously called external authentication methods (EAM), out of preview in early 2026 under the name External MFA, which is why older articles use the other name. If the question behind the migration is which MFA controls your baseline requires, that is answered in MFA and NIST SP 800-53 baselines.

What External MFA Still Does Not Satisfy

If any affected policy uses an authentication strength rather than the plain MFA grant, External MFA will not carry it. Microsoft’s external MFA reference states: “External MFA methods aren’t currently supported with authentication strengths.” It also states: “Grant controls based on authentication strengths, including the built-in MFA strength, aren’t satisfied by the external MFA method.” The migration guide gives the matching instruction for the new policy: “Use the standard Require multifactor authentication grant.”

Two more conditions sit on the provider’s side, in Duo’s External MFA documentation. Users who also use Entra self-service password reset (SSPR) “will need to have at least one of the Microsoft built-in methods that Entra SSPR supports enabled alongside Duo MFA.” Guest and cross-tenant sign-ins are supported only when the Duo method is configured with its Client ID (Guest/Cross-Tenant) value and the users’ OIDs exist as username aliases in Duo, and cross-tenant sign-in also depends on the other tenant trusting MFA claims from the user’s home tenant. Where a policy needs a phishing-resistant strength, the rollout order is its own decision, set out in the i3solutions page on phishing-resistant passwordless sign-in, not part of this migration.

Keep the Provider Through External MFA, or Move to Entra’s Methods

If you have to choose policy by policy rather than once for the whole tenant, decide by user population and by what each policy requires. Use these criteria, in this order:

• Move a policy to Entra’s built-in methods when it requires an authentication strength, because Microsoft’s reference says External MFA does not satisfy one.
• Keep the provider for a population whose policies use Require multifactor authentication and whose users are already enrolled with it.
• Plan a Microsoft method alongside the provider for every user who needs self-service password reset, because Duo states that SSPR needs a Microsoft built-in method enabled.
• Configure the guest and cross-tenant setting before moving any policy that covers guests or users from another tenant.
• List the provider’s other roles in your estate (VPN, RADIUS, non-Microsoft applications) before retiring it, because moving Conditional Access off the provider does not move those. Putting Entra ID in front of RADIUS, Kerberos or header-based applications has its own i3solutions guide on MFA for legacy applications.

Where the provider question sits beside a larger one about which platform owns identity, that decision is set out in the Okta vs Entra ID comparison.

When Keeping Duo Through External MFA Is the Right Call

If your security team built device trust, VPN access and non-Microsoft sign-ins around the provider, replacing it to solve a Conditional Access problem can cost more than it saves. External MFA was built for this case, and Duo’s Entra ID documentation describes it in its own words: “Duo for Microsoft Entra ID External MFA provides an improved authentication experience, streamlined configuration, and fewer Microsoft feature limitations over the legacy custom control for Entra Conditional Access.” Keep the provider when these hold: it already fronts VPN, RADIUS or non-Microsoft applications; the device-trust work lives in it; users are enrolled and a change of prompt is the bigger rollout risk; and the affected policies use Require multifactor authentication, not an authentication strength. In that estate the migration is a registration and a policy change, and the provider users already know stays in place.

Migrating Policy by Policy Without Locking Anyone Out

When the first policy moves, the risk is a user caught by both the old policy and the new one, or by neither. Microsoft’s migration guide sets the sequence, and it is worth following in order:

1. Record the policies whose grant controls use a custom control, as in the policy inventory.
2. Add the provider as an external method in the Authentication methods policy and target it at a test group. The guide adds: “Optionally configure exclude targets for break-glass/emergency accounts.”
3. Confirm in a registration report that the test users are registered for the external method.
4. Create a test Conditional Access policy for the same apps with the Require multifactor authentication grant. The guide says: “Set the policy to Report-only mode initially.” Check the test sign-ins in the sign-in logs, then turn the policy on.
5. In the Microsoft Entra admin center, exclude the test group from the custom control policy, so no user is subject to both.
6. Test sign-in to the protected apps and confirm in the sign-in logs that the external method satisfied MFA, then widen the scope to all users.

Before you remove anything, keep the way back open until the new policy has run cleanly. The migration guide is explicit: “Don’t delete custom control configurations until you confirm the new external MFA policy is stable. Keep the old policy disabled (not deleted) for at least two weeks as a rollback option.” Put together: list every policy whose grant calls a custom control, register the provider as an External MFA method for a test group, run a parallel policy that uses Require multifactor authentication in report-only mode, move the test group across, and keep the old policy switched off, not deleted, for at least two weeks. A policy that needs an authentication strength moves to Entra’s own methods instead.

GCC, GCC High and Government Tenants

If your tenant is in a US government cloud, the provider’s own statements govern what is possible, and Duo’s differ by cloud. For GCC, Duo’s Entra ID Conditional Access page states: “Microsoft’s Government Cloud added support for custom controls for Entra ID conditional access, but the Duo custom control remains unavailable in Entra ID GCC.” For GCC High, Duo’s External MFA page states: “You must subscribe to the Duo Federal Class D High security package. Duo commercial or Duo Federal Moderate plans cannot connect to Microsoft GCC High environments.” Confirm the plan with the provider, and the method’s availability in your cloud with Microsoft, before you schedule the move. If the real requirement in your program is PIV or CAC sign-in, that is a different method with its own i3solutions guide, on PIV and CAC smart cards with Entra certificate-based authentication.

When Not to Keep a Third-Party Provider

If the key policies need an authentication strength, keeping the provider leaves those policies on Entra’s methods anyway, and the provider covers only what is left. Move to Entra’s built-in methods when the key policies need phishing-resistant or other authentication strengths, which External MFA does not satisfy; when the provider does nothing in your estate that Entra’s methods do not already do; when self-service password reset already requires a Microsoft method for a large share of users; or when the provider’s plan cannot reach your cloud, as Duo states for its commercial and Federal Moderate plans in GCC High. And if the inventory finds no policy that uses a custom control, do nothing: the migration guide says “no action is needed.” If sign-in still federates through AD FS, settle that decision first, in the i3solutions guide on moving off AD FS to Microsoft Entra ID.

How i3solutions Approaches the Move

When a custom control migration reaches i3solutions, the work starts from the export of affected policies, so each policy has an owner and a chosen path before anything is switched. The sequence is to inventory the policies, decide provider or Entra per user population, run the parallel policies in report-only mode, then roll out with the old policies kept disabled as the rollback. i3solutions is a Microsoft Systems Integrator with nearly 30 years of experience implementing identity and access management solutions for enterprises in regulated industries. i3solutions implements the Microsoft technology a customer needs, Microsoft Entra ID authentication and Conditional Access included. i3solutions regularly delivers Okta to Microsoft Entra ID migrations for enterprises, detailed in Okta to Entra ID migration services. Delivery is senior and US-based. Ongoing operation after the handover is a separate Application Managed Services engagement with its own scope; the external MFA deployment itself does not replace the internal team, run open-ended, or create vendor lock-in. The configuration work is described in Entra ID configuration and integration services, within identity and access management solutions.