Organisations that connect Duo, RSA or another external MFA provider through Conditional Access Custom Controls must migrate to External MFA before 30 September 2026. Microsoft is replacing the legacy Custom Controls approach with an OIDC-based standard that integrates more deeply and is more secure. What changes, which steps are required, and how much time is left?
Any organisation that has connected an external multi-factor authentication provider to Microsoft Entra ID through Conditional Access Custom Controls has a deadline approaching: 30 September 2026. On that date, Microsoft removes the ability to edit or create custom controls. Full retirement, including the deactivation of existing configurations, follows in May 2027.
This affects organisations that have set up a provider such as Cisco Duo, RSA SecurID, Ping Identity, HYPR, or a comparable solution as a second factor via a Conditional Access policy. The Custom Controls method was for years the only way to anchor such external providers in Entra ID. Microsoft is now withdrawing that method in favour of External MFA, an approach based on the OpenID Connect standard that offers considerably more.
Custom Controls were always a temporary bridge. The method worked via a redirect: after entering their password, the user was sent to the external MFA provider, which returned a token to Entra after verification. Entra trusted that token but could not assess what had actually been verified. The result was a black box in the authentication chain.
This had practical limitations. Conditional Access policies using Custom Controls could not be combined with other grant controls such as device compliance or phishing-resistant methods. Sign-in logs showed limited details about the external verification step. And for new Entra features such as authentication context or step-up verification, Custom Controls simply did not work.
External MFA resolves this by integrating the external provider directly as a registered authentication method in Entra via OIDC. Entra now communicates directly with the provider, receives information about which verification method was used, and can use that information in policy decisions. The result is an authentication chain that is transparent, auditable, and combinable.
External MFA is a generally available feature in Entra ID that works via the OpenID Connect standard. You register your external provider in the Entra portal as an External Authentication Method, using an Application ID, a Client ID, and an OIDC Discovery URL provided by the vendor. Entra takes that configuration and sends a request to the provider during an authentication attempt.
The user experience resembles Custom Controls: after the first factor, a verification step follows with the external provider. The difference is under the hood. Entra now receives a structured OIDC response and knows exactly what was verified. In your Conditional Access policy you can specify that External MFA is required, and that control combines seamlessly with device compliance, location filters, or sensitivity controls.
Cisco Duo already has a dedicated External MFA application for Entra ID available that is separate from the old Custom Controls integration. RSA and other major providers take the same approach. For any provider that supports OIDC, the configuration is essentially the same; only the specific Discovery URL and credentials differ.
Not every organisation with external MFA uses Custom Controls. In the Microsoft Entra portal, check under Protection > Conditional Access > Custom controls whether any active controls are listed. If the list is empty, you are not affected by this change.
If one or more controls appear in the list, check which Conditional Access policies use them via the Policies tab of each custom control. Note the policies and the user groups they apply to. This gives you the scope of your migration.
The migration consists of five phases. Phase one is registering your external provider as an External Authentication Method in Entra. Go to Protection > Authentication methods > External MFA providers and add the provider using the Application ID, Client ID, and Discovery URL provided by your vendor in their configuration guide for Entra ID External MFA.
Phase two is creating a parallel Conditional Access policy that requires External MFA, scoped identically to your existing Custom Controls policy. Activate that policy in report-only mode. This lets you see in the sign-in logs which authentication attempts would or would not succeed without touching the existing Custom Controls policy.
Phase three is a pilot migration. Exclude a test group from the existing Custom Controls policy and include that same group in the new External MFA policy. Let the test group sign in for a week and validate the logs. Confirm that the authentication journey proceeds correctly and that the right information is visible in the Entra sign-in logs.
Phase four is the phased rollout. Expand the new policy to larger user groups while simultaneously excluding those groups from the Custom Controls policy. Keep both policies running in parallel until the entire population has been migrated.
Phase five is removing the Custom Controls policy and the custom controls themselves once all users have been migrated. Do this before 30 September 2026, because after that date the configuration can no longer be modified, only viewed.
After 30 September 2026, Microsoft blocks the creation and editing of Custom Controls. Existing configurations continue to function until May 2027, but you can no longer adjust them if something goes wrong. A change in the provider configuration, a new user group that needs protection, or a modification by your vendor can then block the process with no way to intervene.
The practical risk is that a broken Custom Controls configuration after the retirement date cannot be repaired. Organisations still dependent on Custom Controls at that point are locked into a non-editable policy until full decommissioning in May 2027.
Beyond meeting the deadline, External MFA offers concrete advantages over Custom Controls. Conditional Access policies become more granular: you can combine External MFA with device compliance in the same policy, something that was impossible with Custom Controls. Sign-in logs show the complete authentication journey including the external verification step, simplifying incident response and audits. And new Entra features such as authentication context, step-up verification, and Identity Protection integration work with External MFA.
For organisations moving towards a full zero trust architecture, External MFA is the bridge that anchors external MFA providers within the Entra policy framework. The provider becomes a recognised part of the authentication chain rather than an external detour outside the view of your policy engine.
Three actions to start today. First, check in the Entra portal whether your organisation uses Custom Controls and which policies depend on them. Ten minutes of work gives you clarity on the urgency. Second, contact your MFA vendor and ask for the External MFA configuration guide for Entra ID. Most major providers have this documented, and some also offer migration assistance. Third, plan the pilot migration for no later than August, so that you can complete the full rollout well before the 30 September deadline.
Want help mapping your current Conditional Access configuration, planning the migration to External MFA, or validating the new policy? Contact Zarioh for a no-obligation conversation.
