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

Question

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

Durgesh Mishra 40

We recently completed an authentication migration from:

ADFS + Duo MFA
To Microsoft Entra ID + Duo MFA

Current configuration:

Domain is being migrated from Federated to Managed authentication.
Duo is integrated with Microsoft Entra ID using the Azure Active Directory application in Duo.
Conditional Access policy currently uses a Custom Control named RequireDuoMfa.
The Custom Control was created using the Duo OIDC metadata (Client ID, App ID, Discovery URL).
Sign-ins are currently being enforced through the Conditional Access Custom Control and are working successfully.

We have also configured Cisco Duo MFA under:

Protection → Authentication Methods → External MFA

using the same App ID, Client ID, and Discovery URL from the Duo Azure Active Directory application, but the External MFA method is currently disabled and not targeted to users.

After reviewing the Microsoft documentation regarding the retirement of Conditional Access Custom Controls in early 2027, we would like to understand the recommended migration path.

Questions:

1. Is Microsoft's recommended approach to migrate from:
	Conditional Access Custom Control (RequireDuoMfa)
	to External MFA (External Authentication Method)

2. If the same Duo Azure Active Directory application is already configured for both Custom Control and External 		  MFA, is a new Duo application required or can the existing application be reused?

3. What is the recommended migration sequence?
	Enable External MFA for a pilot group
	Create a new Conditional Access policy using "Require multifactor authentication"
	Exclude the pilot users from the existing Custom Control policy
	Validate sign-ins
	Gradually migrate all users

4. After migration, should the old Custom Control Conditional Access policy be disabled and removed entirely?

5. Are there any known limitations or behavioral differences between:
	Duo Custom Controls
	Duo External MFA (External Authentication Method)

particularly regarding:

	Conditional Access reporting
	PIM
	Risk-based Conditional Access policies
	Authentication Strengths
	User experience during migration

6. Is there any Microsoft guidance for organizations currently using Duo Custom Controls and planning migration before the Custom Control retirement in early 2027?



Any guidance from the Microsoft Entra engineering team or product group would be appreciated.

Rukmini 42,675 Reputation points Microsoft External Staff Moderator

2026-06-18T16:59:12.31+00:00
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:

Audit the existing CA policies that use custom controls.

Configure the External MFA authentication method policy (provider configuration / targeting).

Create a test Conditional Access policy that uses the standard Require multifactor authentication grant (not authentication strength and not the custom control grant).

Move test users from the custom control policy to the new external MFA policy.

Test sign-ins, then do a phased rollout to all users.

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)

In your current setup, does the Custom Control grant block/require MFA for all targeted apps, or only certain apps?

Are you using Require authentication strength anywhere today (for that CA policy), or only Custom Control / Require MFA?

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)?

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?

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)

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

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. Please verify the information before relying on it for decision-making.

1 answer

Your answer

Answer 1

Microsoft’s recommended approach is to migrate from Conditional Access custom controls (such as RequireDuoMfa) to external multifactor authentication (External Authentication Method) and use the standard Require multifactor authentication grant in Conditional Access.

1. Target state and control model

External MFA is the strategic replacement for custom controls:

External MFA does satisfy the Conditional Access Require multifactor authentication grant via a native MFA claim.
External MFA provides:
- Accurate MFA reflection in sign-in logs.
- Support for Privileged Identity Management (PIM).
- Support for risk-based Conditional Access.
- Support for Intune device registration.
Custom controls are deprecated and scheduled for retirement in early 2027 and do not satisfy the built-in MFA requirement.

Therefore, the target is:

Move from a CA policy that grants access via Custom control (RequireDuoMfa)
To a CA policy that grants access via Require multifactor authentication, satisfied by the configured external MFA method (Duo).

2. Application reuse vs. new application

The documented external MFA configuration requires:

App ID (application registration ID in Microsoft Entra ID).
Client ID.
Discovery endpoint (OIDC metadata URL).

These are the same elements used by the custom control integration. The documentation does not require or recommend a separate application when moving from custom controls to external MFA. The same provider application can be used for both during the migration period, and custom controls and external MFA can operate in parallel while migration is in progress.

3. Recommended migration sequence

The documented migration flow aligns closely with the sequence described in the question. A recommended sequence is:

Audit existing custom control policies
- Identify all Conditional Access policies that use the Duo custom control (RequireDuoMfa), including targeted users, apps, and conditions.
Configure external MFA (Duo) as an authentication method
- In Microsoft Entra admin center:
  - Go to Protection → Authentication methods → Policies.
  - Select Add external method / Add method → External Authentication Method.
  - Provide Display Name, Client ID, App ID, and Discovery Endpoint (Duo OIDC metadata).
  - Grant admin consent when prompted.
  - Under Enable and target, set Enabled and initially target only a test/pilot group (not all users). Optionally exclude break-glass accounts.
Create a new test Conditional Access policy requiring MFA
- Go to Protection → Conditional Access → Policies → + New policy.
- Assignments:
  - Users: pilot/test group only.
  - Exclude: break-glass/emergency accounts.
- Target resources:
  - Same apps as the existing Duo custom control policy.
- Conditions:
  - Optionally mirror the existing custom control policy (locations, device platforms, client apps, etc.).
- Grant:
  - Grant access.
  - Check Require multifactor authentication.
  - Do not use Require authentication strength; external MFA does not satisfy authentication strength-based grants.
- Start in Report-only mode.
Verify report-only behavior
- Have a pilot user sign in to a targeted app.
- Check Protection → Sign-in logs → Conditional Access tab:
  - Confirm the new policy shows as Report-only: Not applied or Report-only: Success.
  - Confirm the MFA method is listed as the external authentication method (Duo).
Enable the new CA policy
- Change the policy from Report-only to On.
Exclude pilot users from the existing custom control policy
- Open the existing custom control CA policy.
- Under Users → Exclude, add the pilot/test group.
- Save the policy.
Verify policy assignment with What If
- Use Protection → Conditional Access → What If:
  - Select a pilot user and a target app.
  - Confirm:
    - The old custom control policy does not apply.
    - The new MFA policy does apply.
Validate sign-ins and user experience
- Validate that pilot users are prompted by Duo via external MFA and that access is granted as expected.
Phased rollout
- Follow a phased rollout plan:
  - Phase 1: Test group (5–10 users).
  - Phase 2: IT/early adopters (50–100 users).
  - Phase 3: Department-by-department.
  - Phase 4: All users.
- Gradually expand:
  - External MFA authentication method targeting (include more groups/all users).
  - CA policy scope (from pilot group to all users).
Retire the custom control policy
- After all users are migrated and stable:
  - Disable the old custom control CA policy.
  - Monitor sign-in logs for 1–2 weeks to confirm no regressions.
  - Delete the old custom control policy.
  - Remove the custom control definition from the tenant.
- Do not delete the custom control configuration until the external MFA policy is confirmed stable; keep the old policy disabled as a rollback option during the observation period.

4. Known limitations and behavioral differences

The documentation highlights several differences between custom controls and external MFA:

Conditional Access “Require MFA” grant
- Custom controls: do not satisfy the built-in Require multifactor authentication grant.
- External MFA: does satisfy the Require multifactor authentication grant via a native MFA claim.
Sign-in log accuracy
- Custom controls: MFA is not reflected as a native MFA event in sign-in logs.
- External MFA: full MFA reporting is available; external MFA appears as the MFA method in sign-in logs.
Privileged Identity Management (PIM)
- Custom controls: not supported.
- External MFA: supported and can be used to satisfy mandatory MFA requirements for Azure and admin portals.
Risk-based Conditional Access
- Custom controls: not supported.
- External MFA: supported; external MFA can be used in policies that rely on risk-based controls.
Intune device registration
- Custom controls: not supported.
- External MFA: supported.
Authentication strengths
- External MFA does not satisfy grant controls based on authentication strengths (including the built-in MFA strength). Policies must use Require multifactor authentication, not Require authentication strength, when relying on external MFA.
Parallel operation during migration
- Custom controls and external MFA methods can operate in parallel during migration. The recommended pattern is to:
  - Create a new CA policy using Require multifactor authentication.
  - Include a test group in the new policy and exclude it from the custom control policy.
  - Once validated, move all users to the MFA-based policy and set the custom control policy to Off.

5. Guidance specific to organizations using Duo custom controls

The general guidance for customers using external providers via custom controls (such as Duo) and planning migration before custom control retirement is:

Configure the external MFA provider as an external authentication method using the provider’s OIDC metadata (App ID, Client ID, Discovery URL).
Create a parallel set of Conditional Access policies that use Require multifactor authentication instead of the custom control grant.
Test with a subset of users by:
- Including them in the external MFA method policy and the new CA policy.
- Excluding them from the custom control policy.
After validation, include all required users in the MFA-based policy, then move the custom control policy to Off and eventually remove it.

This approach aligns with Microsoft’s documented migration guidance and prepares the environment for the retirement of custom controls in early 2027.

References:

Share via

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

Recommended migration approach (high level)

Answering your specific questions

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

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

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

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

Authentication Strengths specific guidance from the doc

Microsoft guidance for Duo custom controls specifically

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

Reference list (all relevant docs from the provided materials)

1 answer

1. Target state and control model

2. Application reuse vs. new application

3. Recommended migration sequence

4. Known limitations and behavioral differences

5. Guidance specific to organizations using Duo custom controls

Your answer