Entra Custom Controls Retirement: External MFA Migration Guide

Entra Custom Controls Retirement: External MFA Migration Guide

Microsoft Entra ID (formerly Azure AD) is retiring Custom Controls in Conditional Access. Custom Controls retire September 30, 2026, and reach end of life in May 2027 (Microsoft Message Center post MC1422061). If your organization uses Duo, Okta, RSA, Ping, or any other third-party MFA provider integrated through Custom Controls, you need to migrate to the External MFA framework before the deadline — or your Conditional Access policies will silently stop enforcing MFA.

This guide covers the exact timeline, what breaks mechanically, how External MFA differs architecturally from Custom Controls, the step-by-step migration process, the authentication strength gap that affects security-mature organizations, and the testing strategy that prevents accidental lockouts.

What Is the Entra Custom Controls Retirement? (MC1422061)

Custom Controls was a Conditional Access preview feature that allowed organizations to integrate third-party MFA providers as a grant control. When a user triggered a policy requiring MFA via Custom Controls, Entra ID redirected their authentication session to the third-party provider's portal (e.g., the Duo prompt). Once authenticated, the provider passed a JSON-based token back to Entra ID to satisfy the grant.

While widely adopted by enterprises standardized on non-Microsoft MFA solutions, Custom Controls remained in preview for years due to fundamental architectural limitations: it functioned as a redirect wrapper rather than a natively integrated authentication method, and it never registered a true MFA claim within Entra ID's authentication pipeline.

Microsoft is retiring Custom Controls and replacing them with External MFA (also called External Authentication Methods in earlier documentation — same feature across naming revisions), a generally available, OpenID Connect (OIDC)-based integration for third-party MFA providers.

The retirement timeline has two hard dates:

Existing Custom Controls will continue to function until May 2027. But the September 2026 freeze eliminates your ability to adjust anything — your "we'll tweak it later" option disappears eight months before the final deadline.

Organizations not using Custom Controls are not affected and do not need to take action.

The Security Risk: What Breaks After May 2027

This is not a soft deprecation with a graceful fallback. After May 2027, the Conditional Access engine removes Custom Controls from policy evaluation entirely.

Here is the precise failure sequence:

1. A user attempts to access a protected resource (e.g., Exchange Online, SharePoint Online).
2. Entra ID evaluates the applicable Conditional Access policy.
3. The policy's grant control references a Custom Controls requirement.
4. Because Custom Controls have been removed from the evaluation engine, Entra ID ignores the grant requirement.
5. The user is granted access without completing any third-party MFA challenge.

This is a fail-open failure, not a fail-closed one. The policy still exists. It still evaluates. It does not block access. It does not throw an error. It simply stops requiring MFA. Microsoft's documentation on the retirement describes Custom Controls as "no longer supported" after May 2027, but the access consequence is fail-open: unsatisfied grant controls from retired features are bypassed rather than enforced.

The operational impact is that users and administrators will see no change in behavior at sign-in. There is no error message, no forced fallback to Microsoft Authenticator, no alert in the admin center. Successful sign-ins will appear in logs without an MFA record. If your security team monitors sign-in logs for anomalous patterns, they will only detect this if they actively query for MFA-absent authentications to previously MFA-protected resources.

Compliance implications are direct:

• SOC 2 Type II — MFA controls mapped to CC6.1 (Logical and Physical Access Controls) will not be satisfied.
• HIPAA — Technical safeguard requirements (45 CFR § 164.312) for access control may be violated.
• PCI DSS v4.0 — Requirement 8.4 (MFA for all access into the cardholder data environment) will be unmet.
• FedRAMP — IA-2(1) and IA-2(2) controls require MFA for privileged and non-privileged accounts; silent MFA bypass invalidates the control.

Custom Controls vs. External MFA: Architectural Differences and Capability Gaps

External MFA is the GA replacement. The fundamental architectural difference: Custom Controls redirected users to an external portal using a JSON-based callback that never registered the third-party provider as an authentication method within Entra ID's identity store. External MFA registers the provider as a first-class authentication method using OIDC, so it participates natively in the Conditional Access evaluation pipeline — exactly as Microsoft Authenticator or FIDO2 keys do.

The practical consequence: External MFA generates a true MFA claim in the authentication token. Custom Controls never did. This single difference explains every capability gap in the table below.

The sign-in log improvement alone has material operational value: your SOC team can now verify MFA enforcement from Entra sign-in data without relying on the third-party provider's own logs.

The Authentication Strength Gap (Critical for Security-Mature Organizations)

This is the most significant unresolved limitation of External MFA.

Grant controls based on authentication strengths — including the built-in MFA strength, Passwordless MFA strength, and Phishing-resistant MFA strength — are not satisfied by the External MFA method. You must use the standard Require multifactor authentication grant control.

This means organizations that have implemented phishing-resistant MFA enforcement via Authentication Strength policies (requiring FIDO2 security keys or certificate-based authentication) cannot use External MFA to satisfy those policies today.

What affected organizations should do:

• Option 1 — Hybrid enforcement: Keep Microsoft's phishing-resistant authentication methods (FIDO2, CBA) as the primary enforced method via Authentication Strength policies, and use External MFA only for scenarios where FIDO2/CBA are not available. This requires parallel policy design.
• Option 2 — Vendor FIDO2 passthrough: Some third-party identity platforms (e.g., Duo with FIDO2 passkeys) can natively issue phishing-resistant credentials that Entra ID evaluates directly — bypassing the need for External MFA entirely for high-assurance scenarios.
• Option 3 — Wait for Microsoft roadmap: Microsoft has acknowledged this gap. The External MFA team has indicated work is ongoing to support authentication strength satisfaction, but no GA date has been published as of mid-2025.

If your current Conditional Access policies use Authentication Strength grants (not just "Require MFA"), you cannot do a direct Custom Controls → External MFA swap without redesigning those policies. Validate this in your audit before committing to a migration timeline.

Licensing Requirements

External MFA in Conditional Access requires Microsoft Entra ID P1 or P2 licensing. Entra ID Free and Microsoft 365 Business Basic/Standard plans do not include Conditional Access and therefore cannot use External MFA.

Licenses must be assigned to each user who will authenticate via the External MFA method. Guest (B2B) users require licensing in the resource tenant or a qualifying license in their home tenant; verify cross-tenant licensing before enabling External MFA for guest access scenarios.

Vendor Support Status for External MFA

Not all third-party MFA vendors have GA implementations of the External MFA standard. Before starting migration, confirm your vendor's current support status:

GCC High tenants: While Azure Government (GCC High) supports Entra ID External MFA, Duo Federal is not available within FedRAMP High. GCC High customers cannot use Duo for External MFA and must evaluate alternative providers or Microsoft's native MFA.

For each vendor, you need three data points to configure the Entra-side integration:

• App ID: The app registration ID (typically multitenant)
• Client ID: Identifies Microsoft Entra requests to the provider
• Discovery URL: The OIDC metadata endpoint (e.g., https://provider.example.com/.well-known/openid-configuration)

How to Migrate Custom Controls to External MFA (Step-by-Step)

This migration requires a coordinated update between your third-party identity provider and your Entra ID tenant. Execute it in phases to avoid locking out legitimate users or breaking automated service accounts.

Step 1: Audit Existing Custom Control Policies

Before making changes, export the complete state of your Conditional Access policies. Sign in to the Microsoft Entra admin center as at least an Authentication Policy Administrator, then navigate to Protection > Conditional Access > Policies.

Automate the audit with Microsoft Graph PowerShell:

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-Csv -Path ".\CustomControlPolicies.csv" -NoTypeInformation

In the raw policy JSON, the identifying structure is:

"grantControls": {
    "operator": "OR",
    "builtInControls": [],
    "customAuthenticationFactors": [
        "YourLegacyDuoControl",
        "YourLegacyOktaControl"
    ]
}

For each policy containing customAuthenticationFactors, record:

• Policy name, ID, and current state (enabled/disabled/report-only)
• Targeted users and groups (and exclusions)
• Targeted cloud applications
• All conditions (location, device platform, device compliance, sign-in risk)
• Whether the policy also uses builtInControls alongside the custom control

Export to CSV and track migration status per policy. Service accounts and legacy line-of-business applications with dedicated policies are the most commonly missed items.

Step 2: Identify Policies Using Authentication Strength Grants

Run a parallel audit for Authentication Strength grants, as these require separate handling:

Get-MgIdentityConditionalAccessPolicy -All | Where-Object {
    $_.GrantControls -and $_.GrantControls.AuthenticationStrength
} | Select-Object Id, DisplayName, State, @{
    N = "AuthStrengthId"
    E = { $_.GrantControls.AuthenticationStrength.Id }
}

Policies using Authentication Strength grants cannot be migrated directly to External MFA. Flag these separately and refer to the authentication strength resolution paths described above.

Step 3: Configure External MFA with Your Vendor

Retrieve the OIDC metadata (App ID, Client ID, Discovery URL) from your vendor's admin portal. Vendor-specific locations:

• Duo: Duo Admin Portal > Applications > "Microsoft Entra ID: External Authentication Methods"
• Okta: Okta Admin Console > Security > Identity Providers > Add OIDC
• Ping: PingOne Admin Console > Connections > External IDPs
• RSA: RSA Cloud Authentication Service > Applications > Microsoft Entra External MFA
• WatchGuard: WatchGuard Cloud > AuthPoint > Resources > New Resource > OIDC

Step 4: Register the External Authentication Method in Entra

Navigate to Protection > Authentication methods > Policies in the Entra admin center.

1. Select Add external method
2. Enter Display Name, Client ID, App ID, and Discovery Endpoint from your vendor
3. Grant admin consent when prompted (requires Privileged Role Administrator)
4. Under Enable and target, set state to Enabled and target only your test user group
5. Explicitly exclude break-glass/emergency access accounts from the external method scope

You are creating a new Enterprise App registration alongside your existing Custom Controls integration — not modifying it. Both will coexist during the migration period, which is intentional.

Step 5: Create a Parallel Conditional Access Policy for Testing

External MFA and Custom Controls can operate in parallel during migration. Create a new policy rather than modifying the existing one:

• Name: [TEST] Require MFA via External Auth Method
• Users: Test group only (5–10 users; exclude break-glass accounts explicitly)
• Target resources: Same applications as your existing Custom Control policy
• Grant: Require multifactor authentication (standard grant — not Authentication Strength)
• State: Report-only initially

When a user targeted by the new External MFA method signs in for the first time, a registration wizard guides them through enrollment. This is automatic — you do not need a separate registration campaign for users already enrolled in the external provider.

Do not use "Require authentication strength" for External MFA. External MFA methods do not satisfy Authentication Strength grants. The policy will evaluate but users won't be challenged for the external MFA — they'll either fail the policy or satisfy it via another method depending on your configuration.

Step 6: Exclude Test Users from the Old Custom Control Policy

In your existing Custom Control Conditional Access policy, navigate to Users > Exclude and add your test user group. This prevents double-prompting — you do not want users simultaneously hit by the old custom control redirect and the new External MFA challenge.

Step 7: Validate Sign-In Logs During Report-Only Phase

While the new policy is in report-only mode, check sign-in logs to confirm correct evaluation:

In Monitoring > Sign-in logs, filter by your test users and examine each sign-in event:

• Conditional Access tab: Confirm the new policy shows as "Would have succeeded" in report-only results
• Authentication Details tab: Confirm the External MFA method appears in the authentication sequence
• MFA result field: Should show MFA requirement satisfied with the external method listed
• Grant controls applied: Should list "Require multifactor authentication" as satisfied

Key log fields to verify:

• authenticationMethodsUsed: Should include your external provider's method name
• mfaDetail.authMethod: Should reference the external authentication method
• conditionalAccessStatus: Should be notApplied (report-only) then success after enabling

Step 8: Switch On and Validate

Once report-only results confirm correct evaluation for 3–5 business days across your test group, switch the policy state to On. Verify sign-in logs show:

• Successful authentication with the external MFA method
• MFA status recorded as satisfied (not absent)
• No users falling through to the legacy Custom Control policy

Test edge cases explicitly:

• New device enrollment
• Noncompliant device (should be blocked by compliance policies, not bypassed)
• Named location exclusions (VPN, office IP ranges)
• Expired MFA session (re-authentication should trigger external MFA)
• PIM role activation — verify admin users are challenged by External MFA during role activation
• Intune enrollment flow (previously broken with Custom Controls)

Step 9: Phased Rollout

Expand the External MFA method targeting and the new Conditional Access policy scope in lockstep.

Step 10: Decommission Legacy Controls

Do not delete Custom Control policies immediately upon full rollout. Disable the old policy first and monitor sign-in logs for 1–2 weeks to confirm no regressions or missed user populations.

Rollback procedure if External MFA fails before September 2026:

1. Set the new External MFA Conditional Access policy to Disabled
2. Re-enable the original Custom Control policy
3. Remove test users from the exclusion list on the Custom Control policy
4. Verify sign-in logs confirm Custom Control evaluation has resumed
5. Investigate the External MFA failure (typically: misconfigured OIDC metadata, consent not granted, vendor configuration error)

After confirming no regressions, navigate to Protection > Conditional Access > Custom controls and delete legacy configurations. Deleting them before September 2026 prevents them from surviving to the editing freeze date in an ambiguous state.

Note: After September 30, 2026, you cannot modify Custom Controls. If External MFA fails in production after the editing freeze, you cannot re-enable or adjust your Custom Controls fallback. This is why completing migration before September 30, 2026 — not May 2027 — is the correct target date.

Service Accounts and Non-Interactive Workload Identities

Custom Controls-gated access for service accounts and application service principals is a commonly missed migration risk.

Service accounts and automated workloads using legacy authentication protocols (SMTP AUTH, EWS, IMAP) cannot interact with interactive OIDC prompts. They will fail silently or generate authentication errors if scoped into External MFA Conditional Access policies.

Resolution options by workload type:

Audit service principal sign-ins separately from user sign-ins:

Connect-MgGraph -Scopes "AuditLog.Read.All"
 
# Get service principal sign-ins for the last 30 days
Get-MgAuditLogSignIn -Filter "signInEventTypes/any(t: t eq 'servicePrincipal')" -Top 1000 |
    Where-Object { $_.ConditionalAccessStatus -ne "notApplied" } |
    Select-Object AppDisplayName, ServicePrincipalName, ConditionalAccessStatus, CreatedDateTime |
    Export-Csv ".\ServicePrincipalSignIns.csv" -NoTypeInformation

Service principals that currently hit Custom Controls-based policies and are not remediated before May 2027 will either fail open (if the policy simply required the custom control) or fail closed (if the policy also required device compliance or other enforceable grants). Audit and resolve before migration.

Testing: Three Highest-Risk Failure Scenarios

1. Admin lockout. If Global Admin or Authentication Policy Admin accounts are scoped into the new External MFA policy but have not completed registration, they will be locked out on next sign-in. Maintain at least two break-glass, cloud-only Global Administrator accounts excluded from all Conditional Access policies — both old and new. Store credentials in a physically secured location offline. If the External MFA OIDC integration fails, break-glass accounts are the only path back into tenant administration.

2. Service account failures. Automated service accounts cannot complete interactive OIDC challenges. Any service account included in External MFA policy scope will fail. Audit and explicitly exclude all service principals before expanding scope beyond test users.

3. PIM activation disruption. Custom Controls never supported PIM role activation. If your PIM policies previously required Microsoft Authenticator as fallback, administrators accustomed to that flow will now see the External MFA challenge instead. Validate PIM activation explicitly with test admin users before full rollout.

Use Conditional Access What If to pre-validate policy assignment:

1. Navigate to Protection > Conditional Access > What If
2. Select a test user, target application, and sign-in conditions
3. Confirm the old Custom Control policy does not apply to the test user
4. Confirm the new External MFA policy does apply and shows "Require multifactor authentication" in grant controls

What You Should Do This Week

The September 30, 2026 editing freeze is the operative deadline — not May 2027. After September 30, you cannot create, modify, or adjust any Custom Control configuration. Any migration that is not complete by that date must be completed while locked out of any configuration changes.

Immediate action plan:

1. Run the PowerShell audit to export every Conditional Access policy using customAuthenticationFactors — and separately export every policy using Authentication Strength grants
2. Identify Authentication Strength policies that cannot be directly migrated to External MFA and plan remediation separately
3. Confirm vendor External MFA support — verify your MFA vendor has a GA External MFA implementation and that your tenant's cloud (commercial vs. GCC High) is supported
4. Retrieve OIDC metadata (App ID, Client ID, Discovery URL) from your vendor's admin portal
5. Set an internal migration deadline of August 1, 2026 — this gives two months of buffer before the September editing freeze
6. Configure External MFA in a test group and validate sign-in log output before expanding scope
7. Resolve service account dependencies — identify every service principal currently hitting Custom Controls-gated policies and implement appropriate alternatives
8. Communicate to security and help desk teams — the authentication method will change, and help desk staff need to understand what the new External MFA prompt looks like to support users

The risk of waiting until 2027 is not just the deadline — it is that after September 30, 2026, any production incident in your Custom Controls integration cannot be mitigated through configuration changes. You will be operating a deprecated, frozen authentication mechanism with no ability to adjust it.

Reference Links

• Microsoft Learn: External authentication methods in Microsoft Entra ID
• Microsoft Learn: Configure an external authentication method
• Microsoft Learn: Migrate from Custom Controls to External Authentication Methods
• Microsoft Learn: Conditional Access grant controls
• Cisco Duo: Microsoft Entra ID External Authentication Methods
• Microsoft Message Center: MC1422061 (requires tenant admin access)