Conditional Access policy blocks ERP users with legacy authentication after MFA enforcement

We rolled out a Conditional Access policy requiring MFA for all ERP application access last week. Since then, about 30% of our users can’t access the ERP system. After investigating, we discovered these users are connecting through clients that don’t support modern authentication - specifically older versions of our ERP mobile app and some third-party integration tools.

The CA policy is straightforward - require MFA for cloud app ‘ERP-Production’. But legacy authentication protocols like basic auth bypass the MFA prompt entirely and just get blocked. We’re seeing authentication failures in the sign-in logs with error code 53003 (blocked by Conditional Access).

We need MFA enforcement for security compliance, but we also need these legacy clients to work until we can upgrade them. The mobile app upgrade is scheduled for Q2, and the integration tools are vendor-managed with no immediate update available. What’s the recommended approach for handling legacy authentication clients while enforcing MFA for modern auth?

The compliance concern is valid. We’re under pressure to maintain both security and user access. Is there a way to enforce MFA for legacy auth somehow, even if the client doesn’t natively support it?

I filtered the logs - seeing mostly ‘Mobile Apps and Desktop clients’ with Exchange ActiveSync and Autodiscover protocols. The ERP mobile app uses basic auth to a REST API. The third-party integration uses OAuth1. Both show as legacy auth in the logs.

You have a few options here, none perfect but workable as interim solutions. You could create an exclusion group in your CA policy for users who need legacy auth access, but that defeats the security purpose. Better approach is to use app passwords for those specific legacy clients - they’re static passwords that bypass MFA because they’re considered a second factor themselves. However, Microsoft is deprecating app passwords gradually.

Another route is to create a separate CA policy that allows legacy auth from specific IP ranges only, like your office network. That way legacy clients work on-premises but are blocked when users are remote.

From a compliance perspective, allowing legacy auth with any exceptions is risky. Most frameworks (SOC2, ISO27001) require MFA for all access. I’d recommend accelerating your mobile app upgrade timeline and working with your vendor to prioritize modern auth support in the integration tools. Document the risk acceptance if you implement any workarounds, and set a firm sunset date.

There’s no way to directly enforce MFA on legacy auth protocols because they fundamentally lack the capability for interactive prompts. However, you can implement a defense-in-depth approach. Use device-based conditional access where legacy clients are only allowed from compliant, enrolled devices. This adds a layer of verification even without true MFA. Also consider using Azure AD Identity Protection risk-based policies to block legacy auth from risky sign-ins automatically.

This is a common challenge during MFA rollouts. The core issue is that legacy authentication protocols (basic auth, OAuth1, etc.) can’t prompt for MFA because they don’t support interactive authentication flows.

First step: Can you identify exactly which legacy protocols are being used? Check your Azure AD sign-in logs and filter by ‘Legacy Authentication’ in the client app field. This will help you understand the scope and prioritize remediation.