Microsoft Is Closing a Conditional Access Loophole on March 27

The Sign-In That Will Stop Working

Here is a scenario playing out right now in thousands of Microsoft 365 tenants.

A developer on your team uses the Azure CLI daily. They run az login, complete the sign-in, and get back to work — no MFA prompt, no device compliance check, even though your Conditional Access policy requires MFA for all cloud apps. This has been working fine for months. Maybe years.

On March 27, 2026, it stops working that way.

Microsoft is closing a long-standing Conditional Access enforcement gap. Starting that date — with a progressive rollout through June 2026 — Entra ID will begin enforcing CA policies in scenarios that have quietly bypassed them for years. If your tenant is in scope, users and applications that currently sign in without hitting your access controls are about to run into them. Microsoft notified affected tenants via Message Center entry MC1223829.

This post explains exactly what is changing, who is affected, and what you need to do before the deadline.

---

The Loophole Being Closed

To understand the change, you need to understand how the bypass has worked until now.

When a Conditional Access policy targets "All cloud apps" or "All resources", it is supposed to apply to every sign-in. But Entra ID has had an exception: if the policy has one or more resource exclusions, and the client application requests only certain limited OIDC or directory scopes — like openid, profile, or User.Read — the policy is skipped entirely.

The historical reasoning was that these scopes represent authentication and basic directory lookups, not access to business data. A sign-in requesting only openid and profile is just establishing identity, not reading email or writing files. Enforcing device compliance checks against pure authentication flows seemed like unnecessary friction.

The problem is that this reasoning created a real security gap. Many applications request only these limited scopes — including tools your developers and admins use every day — and they have been bypassing your CA policies silently. Your policy said "require MFA for all cloud apps." The reality was "require MFA for all cloud apps, except when an app requests only these scopes and the policy has any resource exclusions."

Microsoft is closing that gap. After March 27, requesting only OIDC or basic directory scopes no longer exempts a sign-in from CA policies that have resource exclusions.

---

Affected Scopes

The following scopes currently trigger the bypass. After March 27, requests using only these scopes will no longer be exempt:

If an application requests only scopes from this list — and your policy targets all resources with at least one exclusion — that sign-in has been bypassing your policy. After March 27, it will not.

---

Who Is Affected

This change does not affect every tenant. Two specific conditions must both be true:

1. You have a Conditional Access policy targeting "All cloud apps" or "All resources"
2. That same policy has at least one resource exclusion configured

If your policies target specific apps instead of all resources, this change does not apply to them. If your policies target all resources but have no exclusions, the bypass never applied — enforcement was already happening for those sign-ins.

Your first step: check Message Center for MC1223829. If that entry appears in your tenant, Microsoft has identified at least one in-scope policy. If it does not appear, you are most likely not affected.

---

What Will Break

For affected tenants, these are the four most common failure scenarios.

1. Azure CLI Sign-Ins

The Azure CLI authenticates using User.Read plus OIDC scopes — exactly the scopes this change targets. If your CA policy requires MFA or a compliant device for all cloud apps, and it has any resource exclusions, Azure CLI sign-ins have been bypassing it entirely.

After March 27, az login will hit your CA policy. If the user's device is not compliant or they have not completed MFA, the sign-in fails.

2. Custom Line-of-Business Applications

Internal applications that request only basic profile details — to display the user's name and email after sign-in — will now be subject to your CA policy. If that policy requires device compliance, users signing in from personal or unmanaged devices will be blocked.

3. Legacy ADAL Applications

Applications still using the Azure AD Authentication Library (ADAL) rather than the modern Microsoft Authentication Library (MSAL) are at particular risk. ADAL was end-of-lifed in December 2024. These apps often request only basic OIDC scopes, and they may not handle the additional authentication challenges that CA enforcement introduces. Expect silent failures or confusing error messages in affected environments.

4. Desktop Client Sign-In Flows

Some Microsoft and third-party desktop client sign-in flows request only directory-level permissions in certain authentication paths. If a flow for Outlook, Teams, or a similar client has been going through the bypass, users may encounter unexpected MFA prompts or authentication failures mid-session, particularly on older client versions.

---

How to Find Out If You Are Affected

Check the Message Center

In the Microsoft 365 admin center, go to Health > Message Center and search for MC1223829. If this message is present, Microsoft has identified at least one CA policy in scope for the change.

Review Your Conditional Access Policies

In the Entra admin center, go to Protection > Conditional Access > Policies. For each policy targeting "All cloud apps" or "All resources", check whether any resource exclusions are configured. Those are your candidate policies.

For each candidate, consider what types of applications it covers and whether any of them are likely requesting only basic OIDC or directory scopes.

Check Usage and Insights

In the Entra admin center, go to Monitoring & health > Usage & insights > Application activity. This report shows which applications are signing in and what CA policies are being applied — or not applied — to them. Applications with no policy applied are candidates for the bypass.

Analyze Sign-In Logs

Go to Monitoring & health > Sign-in logs and filter by the applications you identified. Look at the Conditional Access column. Sign-ins showing "Not applied" status against a policy that should be active are candidates for the bypass.

You can also run this query in Microsoft Graph PowerShell to export recent sign-ins where no CA policy was applied:

Connect-MgGraph -Scopes "AuditLog.Read.All"

Get-MgAuditLogSignIn -Filter "conditionalAccessStatus eq 'notApplied'" -Top 500 |
  Select-Object CreatedDateTime, UserPrincipalName, AppDisplayName, ClientAppUsed |
  Export-Csv "ca-not-applied.csv" -NoTypeInformation

Review the output for applications that should be subject to your CA policies but are not.

---

What to Do Before March 27

1. Confirm whether your tenant is in scope

Check MC1223829 first. If the message is not in your Message Center, no action is required for this specific change.

2. Identify affected applications

Use sign-in logs, the Usage & Insights report, and the PowerShell query above to build a list of applications that may have been relying on the bypass. Prioritize:

• Developer tooling (Azure CLI, PowerShell modules, Microsoft Graph SDKs)
• Internal tools and custom applications built on basic profile scopes
• Any application still using ADAL
• Desktop client applications on older versions

3. Test in staging before the rollout reaches you

If you have a test tenant or a staging environment, replicate your CA policy configuration and test sign-in flows for each identified application. Look for MFA prompts, device compliance failures, or authentication errors that would not have appeared before. The rollout begins March 27 — if you wait for production to discover what breaks, you are already behind.

4. Migrate ADAL applications to MSAL

If you find applications still using ADAL, this change is your forcing function. ADAL was end-of-lifed in December 2024. These applications need to move to MSAL regardless. Doing it now means you can also handle the CA enforcement changes properly in the updated code.

5. Update custom apps to handle claims challenges

Applications that request only basic scopes and are built in-house may need to handle the claims challenge parameter for step-up authentication. When Entra ID returns a claims challenge — indicating that MFA or device compliance is required — your application needs to respond to it gracefully. MSAL libraries handle this natively. ADAL-based code does not.

6. Communicate with your team before the deadline

If Azure CLI or other developer tools are about to start requiring MFA where they did not before, warn your engineers in advance. An unexpected authentication prompt during a production deployment script is not the experience anyone wants.

7. Review whether your CA policy exclusions are still necessary

The existence of resource exclusions in your CA policy is what put you in scope for this change. Use this as a trigger to review each exclusion. If an app was excluded because it was causing authentication issues — has that been resolved? If an exclusion was added as a temporary workaround — has it become permanent without anyone noticing?

Tightening up or removing unnecessary exclusions reduces your attack surface and keeps you out of scope for future enforcement changes.

---

The Bigger Picture

This change illustrates a problem that surfaces repeatedly in Conditional Access management: the gap between what you think your policies are enforcing and what they are actually enforcing.

When you configured your CA policy targeting "All resources" with a few exclusions, you believed you were enforcing MFA everywhere except those specific carve-outs. But the policy was also silently not enforcing against a category of sign-ins you never explicitly accounted for. Your intended baseline and your actual enforcement state were different — and nothing was surfacing that discrepancy.

This is what continuous configuration monitoring is designed to catch. Not just "has this policy been disabled?" but "is this policy behaving the way you intended, given every condition in how the platform evaluates it?"

Enforcement behavior for CA policies is subtle and changes over time — when Microsoft updates the platform, when an admin adds an exclusion, when a new application gets deployed without the right policy coverage. The organizations that discover gaps like this from a Microsoft advisory — not from an authentication failure in production — are the ones that have defined their intended authentication posture as a baseline and continuously verify their tenant against it.

---

TrueConfig monitors your Conditional Access policies and authentication configuration against your defined security baseline. When enforcement behavior changes — whether from a platform update, an admin modification, or a new application entering your tenant — you see the deviation immediately, with full context on what changed. Learn how TrueConfig works

---

Sources

• Microsoft Tech Community, "Upcoming Conditional Access change: Improved enforcement for policies with resource exclusions"
• Help Net Security, "Conditional Access enforcement change coming to Microsoft Entra"
• M365 Message Center Archive, MC1223829
• 4sysops, "Microsoft Entra ID fixes Conditional Access policy bypass"
• AdminDroid, "New Conditional Access Change for Policy Targeting All Resources"