Custom Controls Entra ID: Migration to External MFA Before 2026

Introduction: End of Life for Custom Controls Entra ID

If your organization relies on Custom Controls Microsoft Entra ID to integrate third-party MFA providers such as Duo Security, RSA SecurID, or Ping Identity, it is imperative to begin your migration planning now. Microsoft has formalized the deprecation of this feature with a retirement date set for September 30, 2026, and complete end of life in May 2027.

This decision is not trivial: it reflects a deep architectural redesign of the Microsoft Entra identity platform, in favor of standard protocols and native integration into the Conditional Access engine. The designated replacement is the External MFA feature, built on OpenID Connect (OIDC) and designed to address all technical gaps of Custom Controls.

Anatomy of Custom Controls: Understanding Architectural Limitations

Custom Controls were introduced as a workaround solution to inject external MFA providers into the Entra ID authentication process. Their operation was based on an HTTP redirect mechanism: after an initial partial evaluation by Entra ID, the user was redirected to a third-party authentication service, which then returned a validation token to Microsoft.

Authentication Flow with Custom Controls (legacy architecture)

The typical flow of a Custom Control broke down as follows:

1. The user initiates a sign-in to an application protected by Conditional Access
2. Entra ID evaluates Conditional Access policies and detects the Custom Control condition
3. The user is redirected to the third-party MFA provider (e.g., Duo portal)
4. The third-party provider completes verification and returns a signed JSON claim to Entra ID
5. Entra ID validates the claim and grants (or denies) access

This model introduced several critical structural problems:

• Out-of-pipeline evaluation: Conditional Access policies were not re-evaluated after the third-party provider returned, creating a window of opacity in security control enforcement
• Lack of real-time risk signals: Microsoft Entra ID Protection could not correlate risk signals (sign-in risk, user risk) with the current session during the redirect phase
• Incompatibility with Continuous Access Evaluation (CAE): Sessions based on Custom Controls did not benefit from real-time token revocation
• Operational complexity: Each third-party provider implemented its own claim logic, making standardization and auditing difficult

External MFA: OIDC Architecture and Native Integration

External MFA represents a complete redesign of third-party MFA provider integration in Microsoft Entra ID. Unlike Custom Controls, External MFA leverages the OpenID Connect (OIDC) protocol and integrates directly into the Conditional Access evaluation engine as a native platform component.

Authentication Flow with External MFA (modern architecture)

With External MFA, the flow becomes:

1. The user initiates a sign-in
2. Entra ID evaluates all Conditional Access policies, including External MFA requirements
3. Entra ID initiates an OIDC session with the registered external MFA provider
4. The third-party provider completes verification and returns a signed OIDC id_token
5. Entra ID integrates the result into its continuous evaluation, applies session controls, and grants access

This architecture ensures that the entire Conditional Access evaluation chain remains active during and after interaction with the third-party provider.

Technical Advantages of External MFA

• Native participation in the Conditional Access pipeline: sign-in risk policies, authentication strength requirements, and session controls are evaluated consistently, regardless of the MFA provider used
• Standardized OIDC protocol: replacement of proprietary integrations with an industry-wide standard, simplifying maintenance and compliance auditing
• Centralized management in Entra portal: external authentication methods are configured and managed in the same place as native Microsoft methods, in the Authentication Methods panel
• Improved user experience: reduction of unnecessary redirects, smoother authentication journey, decreased help desk tickets related to sign-in failures
• Compatibility with Continuous Access Evaluation: sessions authenticated via External MFA can benefit from real-time token revocation

Technical Comparison: Custom Controls vs External MFA

Configuring External MFA in Microsoft Entra ID

Here are the technical steps to configure External MFA with a compatible OIDC third-party provider.

Prerequisites

• Microsoft Entra ID tenant with P1 or P2 licenses
• Third-party MFA provider supporting External MFA via OIDC (consult vendor documentation)
• Global Administrator or Authentication Policy Administrator access
• Registration of the provider's OIDC application in your tenant

Deployment via Entra Portal

1# Connection with required permissions
2Connect-MgGraph -Scopes "Policy.ReadWrite.AuthenticationMethod"
3 
4# List configured External MFA providers
5$externalProviders = Invoke-MgGraphRequest -Method GET `
6  -Uri "https://graph.microsoft.com/beta/policies/authenticationMethodsPolicy/authenticationMethodConfigurations"
7 
8$externalProviders.value | Where-Object { $_.'@odata.type' -like "*ExternalAuthentication*" } | 
9  Select-Object id, state, displayName

1# Module installation if necessary
2Install-Module Microsoft.Graph -Scope CurrentUser -Force
3 
4Connect-MgGraph -Scopes "Policy.Read.All"
5 
6# Retrieve all CA policies
7$policies = Get-MgIdentityConditionalAccessPolicy -All
8 
9# Filter policies with Custom Controls
10$policiesWithCustomControls = $policies | Where-Object {
11  $_.GrantControls.CustomAuthenticationFactors.Count -gt 0
12}
13 
14foreach ($policy in $policiesWithCustomControls) {
15  Write-Host "Policy: $($policy.DisplayName)" -ForegroundColor Yellow
16  Write-Host "  ID: $($policy.Id)"
17  Write-Host "  Custom Controls: $($policy.GrantControls.CustomAuthenticationFactors -join ', ')"
18  Write-Host "  State: $($policy.State)"
19  Write-Host ""
20}

1# Retrieve sign-in logs to audit External MFA
2Connect-MgGraph -Scopes "AuditLog.Read.All"
3 
4$signInLogs = Get-MgAuditLogSignIn -Filter `
5  "authenticationRequirement eq 'multiFactorAuthentication'" `
6  -Top 100
7 
8$signInLogs | Select-Object UserDisplayName, AppDisplayName, `
9  @{N='MFA Detail'; E={$_.AuthenticationDetails.AuthenticationMethod}} | 
10  Format-Table -AutoSize

Migration Plan: Complete Technical Checklist

Here is a structured migration plan for system administrators and cloud engineers managing this transition.

Phase 1 — Inventory and Assessment (M-12)

• Execute the PowerShell audit script to identify all Conditional Access policies referencing Custom Controls
• Map applications and authentication flows dependent on third-party MFA providers
• Document Custom Control IDs and their associated configurations
• Verify the External MFA roadmap of each third-party provider used in your organization
• Assess licensing requirements (Entra ID P1/P2) for the entire target population

Phase 2 — Design and Preparation (M-9)

• Register the OIDC applications of third-party MFA providers in the Entra ID tenant
• Design the new Conditional Access policy architecture with Authentication Strength
• Define Custom Authentication Strength adapted to your security requirements
• Prepare rollback procedures in case of pilot deployment failure

Phase 3 — Pilot and Validation (M-6)

• Deploy External MFA to a representative pilot group (different OSes, applications, locations)
• Validate critical authentication scenarios: web browser, native clients, legacy applications
• Analyze sign-in logs to detect errors or unexpected behaviors
• Gather user feedback and adjust configuration

Phase 4 — Production Deployment and Deactivation (M-3)

• Progressively deploy External MFA to all users (by waves or department)
• Disable Conditional Access policies based on Custom Controls after validation
• Delete Custom Controls from the tenant once migration is complete
• Document the new architecture and update operational runbooks

Implications for Governance and Compliance

Migration to External MFA also provides opportunities to improve security posture and regulatory compliance:

• NIST SP 800-63B Alignment: External MFA via OIDC better aligns with NIST recommendations on standard authentication protocols
• Enhanced Auditability: External MFA authentication events are fully traced in Entra ID Sign-in Logs and exportable to Microsoft Sentinel or your SIEM
• Zero Trust Compatibility: native integration into Conditional Access strengthens Zero Trust architecture by ensuring continuous policy evaluation at each access point
• Compliance Reporting: centralization of authentication method management in the Entra portal simplifies report generation for audits (ISO 27001, SOC 2, NIS2)

Conclusion

The deprecation of Custom Controls Entra ID marks a structuring step in the evolution of the Microsoft identity platform. Migration to External MFA is not merely a functional substitution: it is an opportunity to modernize your organization's authentication architecture, eliminate technical debt, and align your security posture with contemporary industry standards.

IT teams have two years to plan and execute this transition. Beginning now with inventory, evaluation of providers, and design of the new architecture is the most prudent decision to avoid any disruption as the September 2026 deadline approaches.