On May 13, 2026, Microsoft begins rolling out a Conditional Access enforcement change that a lot of tenants are going to feel. The Message Center notice (MC1223829) sounds mild: “Improved enforcement for policies with resource exclusions.” The reality is that a known bypass path through OIDC-only and directory-only token requests is closing, and policies you thought were scoped a specific way are about to start blocking authentication flows they previously ignored.
If you run desktop estates that lean on Entra-joined devices, Windows Hello for Business, LAPS, Intune Company Portal, macOS Platform SSO, or any custom line-of-business agent that authenticates against Graph with limited scopes, you have roughly four weeks to audit before rollout starts. This post walks through what is actually changing, who is affected, how to query your tenant for the exact policies and sign-ins at risk, and how to stage a remediation plan that does not break laptop enrollment on a Monday morning.
What’s actually changing in MC1223829
Today, when a client application authenticates with Entra ID and requests only OIDC scopes (openid, profile, email, offline_access) or a narrow set of directory-only scopes, the token broker has a subtle behavior: Conditional Access policies that target All resources but include resource exclusions are not evaluated against that request. The sign-in goes through without ever checking MFA, device compliance, or session controls that the policy would otherwise enforce.
That gap exists because, historically, Entra could not always tie a lightweight token request to a specific resource, so policies scoped to “all resources minus X” had no single resource to test against and the engine skipped them. Security researchers and pentesters have documented the bypass for years. Microsoft originally communicated a March 27, 2026 enforcement date, then pushed it to May 13, 2026 with a staged rollout over several weeks to give tenants more time to prepare.
After the change, a sign-in requesting only those limited scopes is evaluated against any “All resources” policy regardless of whether the policy has exclusions. If the user or device does not meet the policy’s conditions, the request gets a Conditional Access challenge. For interactive flows, that means an MFA prompt or a device compliance check. For non-interactive flows, such as a background service using a refresh token, the request can fail outright with AADSTS50076 or AADSTS53003.
Which sign-ins are in scope
The scopes that trigger the old bypass, and therefore the new enforcement, fall into three buckets:
- OIDC scopes:
openid,profile,email,offline_access. These are requested during the initial authentication handshake by almost every modern sign-in flow, but some clients never upgrade to a resource-specific token and sit permanently on OIDC-only. - Directory scopes requested via the Graph resource:
User.Read,User.ReadBasic.All, and a few other lightweight directory reads that some custom apps request without also requesting a higher-value Graph scope. - Certain broker and credential-registration flows: Windows Hello for Business provisioning and macOS Platform SSO credential registration, plus some MDM enrollment callbacks that historically authenticated with minimal scopes.
Microsoft’s published guidance is that most mainstream apps (Outlook, Teams, OneDrive, the Intune Company Portal, the Microsoft 365 Admin app) will not behave differently because they quickly escalate to resource-specific tokens. The apps that will behave differently are custom line-of-business clients, identity-adjacent third-party agents like Jamf Connect and Duo’s Windows Logon, and homegrown PowerShell tooling that uses Microsoft.Graph.Authentication with no resource specified.
Why desktop engineering teams should care
The instinct is to treat this as an identity team problem. It is not, for three reasons.
First, device enrollment is in the blast radius. Autopilot and Intune enrollment flows involve several lightweight token exchanges before a device is fully joined. If you have a “Require MFA for all apps” policy with an exclusion list that includes your enrollment service principal, a policy that was silently skipped on the lightweight leg may now fire and request MFA on a device that has no logged-in user to tap a prompt. Microsoft has confirmed that the Intune enrollment service is explicitly exempted, but custom profile variants and third-party MDM agents are not guaranteed to be.
Second, Windows Hello for Business provisioning runs through the exact credential-registration path that gets stricter in May. If your Conditional Access posture requires compliant device for password reset or security info registration, your users may hit a chicken-and-egg situation where they cannot provision WHfB on a new laptop because they have not yet satisfied device compliance on that same laptop.
Third, the sign-in logs you’ll rely on to diagnose failures live in Entra, not Intune. Help-desk tickets that start with “I can’t sign in to my new laptop” will need a practitioner who can cross-reference Entra sign-in logs against Intune device records while running Conditional Access what-if simulations in parallel. That’s a desktop engineering skill now.
Audit workflow: find the policies and apps at risk
The audit has three phases: inventory policies, inventory sign-ins, and triage the intersection. All of it runs through Microsoft Graph.
Phase 1: inventory Conditional Access policies with exclusions
Connect with Policy.Read.All and Directory.Read.All and pull every policy that targets All resources while carrying any kind of exclusion. The exclusions can be at the resource level, the application level, or in the included/excluded user filter.
Connect-MgGraph -Scopes "Policy.Read.All","Directory.Read.All","AuditLog.Read.All","Application.Read.All"
$policies = Get-MgIdentityConditionalAccessPolicy -All
$atRisk = $policies | Where-Object {
$_.Conditions.Applications.IncludeApplications -contains 'All' -and
(
$_.Conditions.Applications.ExcludeApplications.Count -gt 0 -or
$_.Conditions.Users.ExcludeUsers.Count -gt 0 -or
$_.Conditions.Users.ExcludeGroups.Count -gt 0
)
}
$atRisk | Select-Object DisplayName, State,
@{N='ExcludedApps';E={$_.Conditions.Applications.ExcludeApplications -join ','}},
@{N='ExcludedUsers';E={$_.Conditions.Users.ExcludeUsers -join ','}},
@{N='ExcludedGroups';E={$_.Conditions.Users.ExcludeGroups -join ','}} |
Export-Csv -Path .\ca-policies-with-exclusions.csv -NoTypeInformationThe output is your list of policies whose behavior could change. For each one, ask two questions: does this policy’s grant control (like “require MFA” or “require compliant device”) make sense to apply on OIDC-only sign-ins, and are the exclusions there for a real operational reason or because someone was diagnosing an issue in 2022 and never cleaned up?
Phase 2: pull sign-ins that used limited scopes
Sign-in logs carry the list of scopes requested. You can query the interactive and non-interactive logs from Graph for any sign-in in the last 30 days that touched only the scopes the change applies to.
$lookback = (Get-Date).AddDays(-30).ToString('yyyy-MM-ddTHH:mm:ssZ')
$signIns = Get-MgAuditLogSignIn -Filter "createdDateTime ge $lookback and status/errorCode eq 0" -All `
-Property id,createdDateTime,userPrincipalName,appDisplayName,appId,resourceDisplayName,authenticationRequirement,conditionalAccessStatus,clientAppUsed,scopes
$limitedScope = $signIns | Where-Object {
$_.ResourceDisplayName -in @('Microsoft Graph','Windows Azure Active Directory') -and
(
($_.Scopes -split ' ') -notcontains 'Directory.Read.All' -and
($_.Scopes -split ' ') -notcontains 'Mail.Read'
)
}
$limitedScope | Group-Object AppDisplayName, AppId |
Select-Object Count, Name |
Sort-Object Count -Descending |
Export-Csv -Path .\limited-scope-signins.csv -NoTypeInformationThe CSV ranks every client app that is authenticating with OIDC-only or directory-only scopes in your tenant. Any app in the top 20 that is not owned by Microsoft, Apple, or your known vendor list deserves investigation before May 13.
Phase 3: intersect and prioritize
Cross-reference the policy list and the sign-in list. For each app in the limited-scope list, check whether it appears in the ExcludedApps field of any at-risk policy. If it does, that app was using the bypass path. After May 13, those sign-ins will be evaluated against the policy.
$atRiskApps = $atRisk | ForEach-Object {
foreach ($app in $_.Conditions.Applications.ExcludeApplications) {
[PSCustomObject]@{
PolicyName = $_.DisplayName
ExcludedAppId = $app
}
}
}
$limitedScope | ForEach-Object {
$match = $atRiskApps | Where-Object ExcludedAppId -eq $_.AppId
if ($match) {
[PSCustomObject]@{
AppName = $_.AppDisplayName
AppId = $_.AppId
User = $_.UserPrincipalName
PolicyName = $match.PolicyName
SignInTime = $_.CreatedDateTime
}
}
} | Export-Csv -Path .\bypass-in-use.csv -NoTypeInformationThe final CSV is your remediation backlog. Every row represents a real sign-in that is about to start getting evaluated against a policy that previously skipped it.
Remediation patterns
The fix depends on the intent of the original exclusion.
If the exclusion existed to avoid breaking an app that genuinely cannot satisfy MFA (a headless service account, a network appliance pulling user data), move the app to a workload identity policy instead of a user-scoped one, or switch the service to a managed identity or certificate-based authentication that does not go through the interactive CA path.
If the exclusion existed because the app used to fail on device compliance (common with early versions of Duo and Jamf Connect), upgrade to a current version that handles CA challenges correctly and then remove the exclusion entirely. Both vendors published compatibility notes in Q1 2026.
If the exclusion is a temporary troubleshooting artifact, remove it. You can use the Conditional Access what-if tool in the Entra admin center to confirm that removal does not break any legitimate sign-in.
For the edge cases that cannot be resolved before May 13, Microsoft is publishing a tenant-level opt-out capability that retains the old behavior for up to 90 days past the rollout. Details on the opt-out switch are expected in a future Message Center post. Do not design your remediation plan around the opt-out. Use it only as an emergency pressure-release valve for apps that are actively breaking in production.
Testing changes without breaking production
Before touching any policy, take a backup. Conditional Access does not have a native version history, so the backup is your rollback.
$policies = Get-MgIdentityConditionalAccessPolicy -All
$policies | ConvertTo-Json -Depth 10 |
Out-File ".\ca-backup-$(Get-Date -Format yyyyMMdd).json"Then test changes in report-only mode first. Set the policy state to enabledForReportingButNotEnforced, wait 48 hours, and review the sign-in logs filtered by that policy. The conditionalAccessStatus property on each sign-in will show reportOnlyFailure or reportOnlySuccess, which tells you exactly what would have happened if the policy were live. Only flip the state to enabled after the report-only pass comes back clean.
If you manage policies as code (a pattern I strongly recommend for any tenant above a few hundred seats), stage the changes in a dev tenant first and push to production through your normal pipeline. The Microsoft Graph PowerShell SDK can apply policy JSON idempotently with New-MgIdentityConditionalAccessPolicy and Update-MgIdentityConditionalAccessPolicy.
Caveats and gotchas
A few things are worth flagging.
The rollout is gradual over “several weeks” according to Microsoft’s published guidance. That means tenants will flip at different times between May 13 and early June. If you have a dev tenant and a prod tenant, they may not flip in the same window. Build your monitoring to catch increases in Conditional Access-driven failures in both.
The change does not affect policies that target specific cloud apps rather than All resources. If all your critical policies are scoped to specific Office 365 and Intune apps rather than to All resources, you are not in scope for this particular change. Check regardless, because “All resources” policies have a habit of sneaking into tenants during security audits.
Sign-in logs only go back 30 days in the standard retention. If you want historical analysis, export to a Log Analytics workspace now and query KQL instead of Graph. SigninLogs | where TimeGenerated > ago(90d) | where ConditionalAccessStatus != "success" is a useful starting point for the wider posture review.
Finally, the Conditional Access what-if tool does not yet reflect the post-May-13 behavior. If you run a what-if simulation today, it will show the current bypass-friendly evaluation, not the enforced one. Microsoft has said the what-if tool will be updated before May 13, but until then, your best predictor of post-change behavior is an enabled report-only policy.
Conclusion
MC1223829 is not a routine change. It closes a documented bypass that many tenants have, accidentally or deliberately, depended on for years. The practical work between now and May 13, 2026 is mechanical. Inventory your All-resources policies that carry exclusions. Identify the apps riding the limited-scope path. Then either remove the exclusion outright or upgrade the client to one that handles Conditional Access challenges cleanly.
If you manage an endpoint fleet of any size, get your Conditional Access audit onto a sprint board this week. The fix is not hard. The probl