Microsoft has quietly removed one of the biggest identity-management frictions for enterprise customers: the inability to cleanly use third-party MFA providers inside Microsoft Entra ID without sacrificing policy control. The company's new External MFA capability, built on OpenID Connect (OIDC), represents a significant shift in how organizations can integrate third-party authentication while maintaining Microsoft's Conditional Access policies.

This change addresses a longstanding complaint from security teams who wanted to use specialized MFA providers like Duo, Okta Verify, or PingID but couldn't do so without losing the granular policy enforcement that Microsoft Entra ID provides. Previously, organizations faced a binary choice: use Microsoft's built-in MFA with full policy control or implement third-party MFA through custom controls that bypassed Microsoft's policy engine entirely.

The new External MFA feature changes this equation fundamentally. Organizations can now integrate third-party MFA providers while Microsoft Entra ID continues to enforce Conditional Access policies. The identity platform handles the policy evaluation, then redirects users to the external MFA provider for authentication before returning them to complete the sign-in process.

Technical Implementation Details

Microsoft's implementation uses the OpenID Connect protocol, specifically the Authorization Code Flow with PKCE (Proof Key for Code Exchange). This OAuth 2.0 extension provides better security for public clients like mobile apps and single-page applications. The architecture maintains Microsoft Entra ID as the policy decision point while delegating the actual MFA challenge to external providers.

When a user attempts to access a protected resource, Microsoft Entra ID evaluates all Conditional Access policies as it normally would. If MFA is required, instead of presenting Microsoft's own MFA challenge, the system redirects the user to the configured external MFA provider. After successful authentication, the provider returns an OIDC token that Microsoft Entra ID validates before completing the sign-in.

This approach preserves the entire Conditional Access policy framework. Organizations can still use risk-based policies, device compliance requirements, location restrictions, and all other policy controls that Microsoft Entra ID offers. The only difference is where the MFA challenge occurs.

The Custom Controls Dilemma

The announcement comes with significant implications for organizations currently using custom controls for MFA integration. Microsoft has confirmed that custom controls for MFA scenarios will be retired in 2026. This gives organizations approximately two years to migrate from custom controls to the new External MFA approach.

Custom controls have been a workaround solution that many enterprises implemented out of necessity. These controls allowed third-party MFA integration but came with critical limitations. Most importantly, when using custom controls, Microsoft Entra ID's Conditional Access policies don't apply to the MFA step itself. The identity platform essentially treats the custom control as a "black box" that either passes or fails, without visibility into what happened during authentication.

This architectural limitation meant organizations sacrificed granular policy enforcement for third-party MFA compatibility. Security teams couldn't apply different MFA requirements based on user risk, device state, or application sensitivity when using custom controls. The policy evaluation happened before the custom control, and the result was simply a binary pass/fail.

Migration Considerations and Timeline

With the 2026 retirement date for custom controls, organizations need to begin planning their migration strategies now. The two-year timeline provides reasonable runway for most enterprises, but migration complexity will vary based on several factors.

Organizations using simple custom control implementations with major MFA providers will likely find straightforward migration paths. Microsoft is working with leading MFA vendors to ensure compatibility with the External MFA feature. Companies using niche or custom-built MFA solutions may face more complex migration scenarios that require additional development work.

The migration process involves several key steps. First, organizations must configure their external MFA provider to support OIDC integration with Microsoft Entra ID. Next, they need to create authentication strength policies in Microsoft Entra ID that reference the external MFA provider. Finally, they must update their Conditional Access policies to use these new authentication strength policies instead of custom controls.

Microsoft recommends starting with pilot deployments for specific user groups or applications before rolling out the changes organization-wide. This phased approach allows security teams to validate the integration, monitor for issues, and adjust configurations as needed before full deployment.

Security and Compliance Implications

The External MFA feature maintains Microsoft's security model while expanding integration options. Because Microsoft Entra ID continues to handle policy evaluation, organizations don't lose any security capabilities. All the risk detection, session management, and policy enforcement features remain intact.

For compliance purposes, this architecture provides clearer audit trails. Since Microsoft Entra ID manages the entire authentication flow, organizations get unified logs that show both policy evaluation and MFA completion. This contrasts with custom controls where the MFA step appears as a single event without detailed context.

The OIDC-based approach also improves security in several ways. It uses standard protocols with proven security properties rather than proprietary integration methods. The Authorization Code Flow with PKCE provides strong protection against authorization code interception attacks. And because Microsoft validates the OIDC tokens returned by external providers, organizations get assurance that the MFA challenge was completed successfully.

Enterprise Impact and Use Cases

This change particularly benefits organizations in regulated industries or those with complex security requirements. Financial institutions, healthcare providers, and government agencies often need to use specialized MFA solutions that meet specific regulatory requirements while maintaining strong access controls.

Companies with existing investments in third-party MFA infrastructure now have a path to leverage those investments without compromising on Microsoft Entra ID's policy capabilities. Organizations that standardized on particular MFA vendors before adopting Microsoft 365 can now integrate their preferred solutions more cleanly.

The feature also supports hybrid identity scenarios. Organizations with on-premises applications protected by third-party MFA can now extend similar protection to cloud applications through a consistent policy framework. This helps bridge the gap between legacy and modern authentication approaches.

Limitations and Considerations

While the External MFA feature addresses major integration challenges, organizations should be aware of several limitations. The feature currently requires the external MFA provider to support OIDC, which may exclude some legacy systems. Integration complexity varies by provider, and some custom configurations may not translate directly from custom controls.

Performance considerations also matter. Adding an external redirect for MFA adds latency to the authentication flow. Organizations should test the impact on user experience, particularly for latency-sensitive applications. The additional network hop to the external provider also introduces another potential point of failure that needs monitoring.

Cost implications exist too. While Microsoft isn't charging extra for the External MFA feature itself, organizations may incur additional licensing costs from their MFA providers. Some providers charge based on authentication volume, and moving more authentications through their systems could increase costs.

Looking Ahead to 2026

The retirement of custom controls in 2026 represents more than just a technical migration. It signals Microsoft's commitment to standardizing authentication integration through modern protocols. The move away from proprietary custom controls toward standards-based OIDC integration reflects broader industry trends toward interoperability and security standardization.

Organizations should view the two-year migration window as an opportunity to reassess their overall authentication strategy. Rather than simply replicating existing custom control configurations, security teams should consider whether they're using the right MFA solutions for their current needs. The migration to External MFA provides a natural point to evaluate whether existing third-party MFA investments still make sense or whether Microsoft's native MFA capabilities have evolved sufficiently to meet requirements.

Microsoft's documentation indicates that the company will provide detailed migration guidance and tools as the 2026 deadline approaches. Early adopters who migrate sooner will benefit from longer operational experience before the custom controls retirement takes effect. They'll also have more time to refine their configurations and address any integration challenges that emerge.

The External MFA feature represents a pragmatic solution to a real-world enterprise problem. By preserving policy control while enabling third-party integration, Microsoft has addressed one of the most persistent complaints from large organizations trying to balance security requirements with practical constraints. The two-year migration timeline provides reasonable accommodation for organizations to adapt while maintaining security posture during the transition.

As enterprises continue to navigate complex identity and access management challenges, features like External MFA demonstrate how cloud identity platforms can evolve to meet diverse organizational needs without compromising security fundamentals. The move toward standards-based integration while maintaining centralized policy control sets a pattern that will likely influence future identity platform developments across the industry.