Migration path from Conditional Access Custom Control (Duo) to External MFA before Custom Control retirement

Hey! Great question—and you’re right to start planning now. Microsoft’s guidance for customers using Conditional Access custom controls is to migrate them to External multifactor authentication (External MFA) before custom controls reach retirement (full retirement scheduled for early 2027; adding/editing is blocked starting September 2026).

Below is a forum-ready answer that maps closely to the steps you outlined, using the Microsoft migration guide.

Recommended migration approach (high level)

Microsoft’s migration process is essentially:

1. Audit the existing CA policies that use custom controls.
2. Configure the External MFA authentication method policy (provider configuration / targeting).
3. Create a test Conditional Access policy that uses the standard Require multifactor authentication grant (not authentication strength and not the custom control grant).
4. Move test users from the custom control policy to the new external MFA policy.
5. Test sign-ins, then do a phased rollout to all users.
6. After successful rollout, disable and then delete the old custom control policy (with a safety window for rollback).

This is reflected directly in the “Migrate from custom controls to external multifactor authentication” documentation.

Answering your specific questions

1) Is the recommended approach to migrate from CA custom control to External MFA?

Yes. External MFA is the supported replacement for custom controls, and Microsoft calls out key limitations of custom controls that external MFA resolves (for example, full MFA reporting, PIM support, risk-based Conditional Access support, etc.).

2) If the same Duo Azure AD application is used, do you need a new Duo application for External MFA?

The Microsoft documentation you provided focuses on prerequisites like having the Application ID, Client ID, and Discovery URL (OIDC metadata) for the provider’s external MFA configuration. It does not explicitly say whether you must create a new provider application vs. reusing an existing one.

So, based on the docs we have here:

• You can proceed as long as the External MFA authentication method configuration uses the correct Application ID / Client ID / Discovery URL that match your Duo external authentication setup.
• If Duo’s External MFA and Custom Control rely on the same OIDC metadata and identifiers, reuse may work—but that’s something you’d validate during the pilot sign-in testing.

3) Recommended migration sequence (and how it relates to what you proposed)

Your proposed sequence aligns well with the Microsoft “phased rollout plan” and rollout safety steps. Microsoft’s doc includes these concepts:

Pilot / test phase (5–10 users):

• Create the new CA policy using Grant: Require multifactor authentication
• Start in Report-only mode first
• Then enable for the test group
• Exclude test users from the old custom control CA policy to avoid double prompts

Validation:

• Use Sign-in logs and verify the Conditional Access tab shows the new policy applied and that the MFA method appears as the external authentication method.
• Microsoft also suggests using What If to confirm policy evaluation (old policy does not apply; new policy does apply).

Gradual rollout:

• Expand targeting in steps (50–100 users, then department-by-department, etc.)
• Gradually move groups from custom control to external MFA

After migration (cleanup / rollback window):

Microsoft explicitly recommends:

• Once all users are migrated: disable the old custom control CA policy
• Monitor sign-in logs for 1–2 weeks
• Then delete the old CA policy
• And only after stability: remove the custom control definition/config from the tenant
• Important warning: don’t delete until you confirm the new external MFA policy is stable. Keep the old policy disabled for at least two weeks as rollback.

So: Yes, after migration, the old policy should not stay enabled. The guidance is to disable first, verify for 1–2 weeks, then delete.

Limitations / behavioral differences (what we can say from the provided docs)

The migration guide clearly states external MFA addresses these limitations of custom controls:

• CA “Require MFA” grant compatibility
  • Custom controls: ❌ No
  • External MFA: ✅ Yes (native MFA claim)
• Sign-in log accuracy
  • Custom controls: ❌ MFA not reflected
  • External MFA: ✅ Full MFA reporting
• PIM
  • Custom controls: ❌ Not supported
  • External MFA: ✅ Supported
• Risk-based Conditional Access
  • Custom controls: ❌ Not supported
  • External MFA: ✅ Supported
• Intune device registration
  • Custom controls: ❌ Not supported
  • External MFA: ✅ Supported

The specific items you asked about—Conditional Access reporting, PIM, risk-based CA policies, authentication strengths, and user experience—are only partially addressed explicitly in the provided docs:

• We have strong, explicit coverage for reporting/PIM/risk-based CA/auth strengths compatibility (not fully named as “authentication strength,” but the guide warns not to use “Require authentication strength” for external MFA).
• We do not have detailed information here about any nuanced “user experience” differences beyond the troubleshooting note that users might see both prompts if you don’t exclude them properly.

Authentication Strengths specific guidance from the doc

The guide includes an Important note:

• Don’t use Require authentication strength for external MFA.
• Use the standard Require multifactor authentication grant.

(And it mentions external MFA isn’t yet compatible with authentication strength policies.)

Microsoft guidance for Duo custom controls specifically

The provided documents don’t mention Duo specifically beyond the fact that they are an external MFA provider scenario. So we can’t quote Duo-specific Microsoft engineering guidance from the materials you provided.

What we can say is: Microsoft’s general migration guidance for any custom control provider is exactly the plan above, and it’s driven by OIDC provider metadata (Application ID, Client ID, Discovery URL) plus CA policy changes.

Follow-up questions (to tailor the forum response / confirm correctness)

1. In your current setup, does the Custom Control grant block/require MFA for all targeted apps, or only certain apps?
2. Are you using Require authentication strength anywhere today (for that CA policy), or only Custom Control / Require MFA?
3. For the External MFA method, have you enabled the authentication method policy and confirmed the pilot users are included in includeTargets (per the doc’s troubleshooting guidance)?
4. During pilot testing, do you see the new CA policy in Sign-in logs > Conditional Access for the test user, and is the MFA method shown as the external authentication method?
5. Do you currently have any policies that might also prompt for MFA (risk-based CA, identity protection, or other MFA grants) that could cause “double prompts”?

Reference list (all relevant docs from the provided materials)

1. Migrate from custom controls to external multifactor authentication (full migration guide) https://learn.microsoft.com/entra/identity/conditional-access/how-to-migrate-custom-controls-external-mfa
2. External MFA GA announcement (linked from the migration guide content) https://techcommunity.microsoft.com/blog/microsoft-entra-blog/external-mfa-in-microsoft-entra-id-is-now-generally-available/4488926

(Those are the only migration-specific references included in your “Relevant Documentations” section; I did not use other unrelated articles.)

If you want, paste (sanitized) the names of your two CA policies (custom-control one + planned external MFA one) and whether they use Require MFA vs authentication strength, and I can help you validate the migration sequence and the exact “report-only → enable → exclude test users → cleanup” alignment with the Microsoft steps.

Note: This content was drafted with the help of an AI system.

Hello @Durgesh Mishra If the resolution was helpful, kindly take a moment to click on and click on Yes for was this answer helpful. And, if you have any further query do let us know.