Conditional Access enforcement changes May 13: check your exceptions now

Most Conditional Access policies targeting all cloud apps have been silently skipping enforcement for years. Not for excluded apps. For apps that were never excluded at all: apps that should have required MFA, but didn’t, because Microsoft’s policy evaluation had a gap.

Starting May 13, 2026, that gap closes. If you have app exclusions in a Conditional Access policy targeting all resources, this is worth reading.

Conditional Access is the feature in Microsoft 365 that controls when a user needs to verify their identity before signing in. Think of it as the rulebook: sign in from an unknown device, prove it is you. Sign in from a foreign country, same. The problem is that rulebook has had a hole in it.

What has been bypassing your policies all along?

Apps that request only basic sign-in information could bypass a Conditional Access policy even when they should have fallen under it. These are not apps on an exclusion list. They are apps that were never excluded, that should have been enforced, but weren’t, because Microsoft’s evaluation skipped the check when the requested data scope was minimal enough.

The specific OAuth scopes that triggered this bypass differ by client type. For confidential clients (web apps, services), sign-ins requesting only openid, profile, email, offline_access, User.Read, User.Read.All, User.ReadBasic.All, People.Read, People.Read.All, GroupMember.Read.All, or Member.Read.Hidden were skipping enforcement. For native clients and SPAs, the bypass applied to openid, profile, email, offline_access, User.Read, and People.Read.

The bypass is reproducible and leaves no obvious trace in your sign-in logs. Anyone who understands how OAuth scopes work can craft a sign-in request that hits only basic profile data and bypasses MFA on any tenant with this policy pattern. From May 13, Conditional Access applies consistently regardless of what scopes an app requests. Microsoft detailed this change in the Entra ID blog and notified affected tenants via MC1223829.

The rollout started May 13 and is phased over several weeks. Not every tenant is switched at the same time. If you haven’t been affected yet, you will be.

What is the highest-risk scenario?

Scripts, scheduled tasks, and legacy integrations that authenticate non-interactively.

These sign-ins request minimal scopes by design. A PowerShell script calling Graph, an Azure CLI pipeline, a line-of-business app using stored service account credentials: all of them request only what they need, which is often just User.Read or openid. That is exactly the scope range that has been bypassing Conditional Access.

Today they pass silently. After the rollout reaches your tenant, they will not prompt for MFA. They will fail.

No error dialog, no retry, no fallback. Whatever they were automating simply stops. If that describes anything in your environment, that is your first priority.

Are you affected?

Most organisations will not be. The diagram below walks you through the three conditions. If all three apply, it is worth reviewing your setup.

Check all three of the following:

1. Your Conditional Access policy targets All resources (formerly All cloud apps)
2. You have configured resource exclusions: specific apps that are exempt from the policy
3. Non-excluded apps exist where sign-ins request only limited basic information

If all three are true, sign-ins to non-excluded apps that were silently bypassing enforcement will now be checked. Users will get an MFA prompt where they didn’t before.

Check your Message Center first. Microsoft has already notified affected tenants. Search for MC1223829 in the Microsoft 365 admin center. If that message is in your inbox, your setup meets these conditions.

What should you check right now?

Run the automated check

Tenant Wizards has published a PowerShell script that audits your tenant directly. It lists all relevant CA policies sorted by state, detects legacy authentication sign-ins that will break after enforcement, and outputs an HTML report you can save or share. Requires the Microsoft Graph PowerShell SDK and delegated permissions. No app registration needed.

Get-CAEnforcementReport.ps1 on GitHub

If you prefer to check manually, the steps below cover the same ground.

Review your policies

Open the Entra ID admin center and navigate to Security, Conditional Access, Policies. Look for any policy where the target is set to “All resources” and one or more apps are excluded at the same time. No such combination? You can stop here.

Check whether affected apps can handle MFA

Modern applications support MFA by default. To test: sign in to a potentially affected app from an unfamiliar network or a private browser session from a different device. If you are asked to verify your identity and it completes successfully, the app handles it fine. If the login hangs or fails, it does not.

For third-party integrations, check the vendor documentation for “modern authentication” or contact their support team. For older in-house apps or legacy systems: these cannot handle an MFA challenge at all. They will not prompt. They will fail silently. Treat those as the highest priority to review.

Prioritise automation and scripts

Any script or scheduled task that authenticates non-interactively is in scope. Go through your environment and identify everything that signs in with stored credentials.

For each one, you have three options:

1. Move it to a service principal with a proper app registration. Service principals are excluded from user-scoped Conditional Access by default and the right long-term solution for automation.
2. Add the app explicitly to your exclusion list with a documented reason and a review date.
3. Accept that it will break and plan accordingly.

Option 1 is the correct answer for anything running in production. Option 2 is acceptable short-term if you document it. Option 3 is only acceptable if the automation is genuinely expendable.

Check specific environments if applicable

If you use device management through Intune or Jamf, or run Azure Virtual Desktop, verify those connection flows too. The chance of impact is small, but worth a few minutes before the rollout reaches your tenant.

What should you check after the rollout?

Monitor your sign-in logs

A few days after the rollout, open sign-in logs in the Entra admin center. Filter on Conditional Access results and look for unexpected blocks or new MFA prompts. This points you directly to any app that needs attention.

Tenant Wizards has published a monitoring script for after the 13th. It identifies which CA policies are in scope, queries sign-in logs for those policies only, and cross-checks results against the week before May 13 to filter out sign-ins that were already being enforced before the change. What remains is what genuinely changed. Exports as an HTML report with CA failures and MFA-required sign-ins grouped by application, with the enforcing policy shown per entry.

Get-CAEnforcementMonitor.ps1 on GitHub

What happens if you don’t act?

For most users: nothing dramatic. They will be prompted for MFA where they weren’t before, call the helpdesk confused, and the issue resolves itself once they complete the prompt. A few tickets, some noise, resolved within minutes.

For automation, scripts, and legacy integrations that cannot handle MFA challenges: those will fail outright. No prompt, no fallback. If that describes anything in your environment, act before the 13th.

Received the Message Center notification?

Then Microsoft detected that your tenant is potentially in scope. Work through the steps above and make any adjustments before the 13th if needed.

Fifteen minutes of checking now saves a queue of helpdesk tickets later.

Is your Conditional Access actually enforcing what you think it is?

This change makes many environments genuinely more secure, because many of them were not as secure as they appeared. If your tenant matches the conditions above, your Conditional Access policy has not been fully enforced for apps outside your exclusion list. Sign-ins that should have required MFA to access your environment did not require it.

That is not something you can address retroactively. You cannot go back and require MFA for sign-ins that already happened. But you can make sure the policy means what you think it means from this point forward.

It is also a good moment to review your Conditional Access configuration more broadly. Any account or app that sits outside your policies is worth confirming is intentional. Exceptions that were created quickly and never reviewed are the most common reason a policy looks complete on paper but leaves gaps in practice. A policy covering all users with no exceptions is harder to bypass than one with twenty exclusions nobody remembers adding.

If you make this a habit after every Microsoft enforcement change, you spend less time firefighting and more time knowing your tenant is actually in the state you think it is.