Skip to content

Field note

Conditional Access Resource Exclusions: 2026

The risky response is to weaken a broad access policy because one small application fails. First prove whether the tenant and authentication flow are actually in scope.

Published11 Jul 2026

Updatedyesterday

Read time4 min. 820 words.

Microsoft started an enforcement change on 15 June 2026 for a narrow Conditional Access scenario.

It affects policies targeting All resources when those policies contain one or more resource exclusions. Under the older behaviour, some client applications requesting only OpenID Connect scopes or a limited set of directory scopes could avoid enforcement of those policies. Microsoft is closing that gap.

After the change reaches a tenant, those sign-ins can receive the access controls configured in the policy, such as MFA or a compliant-device requirement.

Quick answer

Most organisations do not need to change anything.

Review is worthwhile if all three are true:

  1. You have a Conditional Access policy targeting All resources.
  2. That policy excludes one or more resources.
  3. A custom or specialist application requests only the affected limited scopes.

Microsoft says affected tenants receive Microsoft 365 Message Center guidance. Start there, then use policy configuration and sign-in logs to prove the impact.

Why this can look like a random app failure

The application itself may not have changed. The same authentication request can now be evaluated by a policy that previously was not enforced for that limited-scope flow.

The result depends on your policy. A user might see:

  • an MFA prompt
  • a compliant-device requirement
  • a blocked sign-in
  • an application error if the client does not handle a Conditional Access claim challenge correctly

That last case is important. A client can be permitted in principle but still fail because it does not know how to respond to the challenge.

Do not solve that by immediately excluding more resources or users. An exclusion can hide the symptom while widening the policy gap.

Confirm whether your tenant is affected

Use a short evidence-led review:

  1. Find the relevant Message Center post for your tenant.
  2. Export policies targeting All resources.
  3. Record every resource exclusion and why it exists.
  4. Identify registered applications that request only the affected scopes.
  5. Review recent sign-in logs for those applications.
  6. Compare the applied policies, result, resource and authentication details.
  7. Test with a controlled user and device that represent the real access path.

The sign-in log matters more than an application display name. Conditional Access protects access to a resource, and different client applications can request the same target resource. Record the resource and policy evaluation shown in the log.

What to ask an application owner

If a custom application fails, the owner or developer should be able to answer:

  • Which scopes does the application request?
  • Which resource appears in Entra sign-in logs?
  • Can the application process Conditional Access claim challenges?
  • Does it support MFA and device-compliance challenges in this flow?
  • Is there a current Microsoft identity library or vendor update available?
  • What test proves normal and exception paths still work?

Microsoft provides developer guidance for handling Conditional Access claims. A product that cannot handle the challenge may need an application update rather than a tenant-wide policy exception.

A controlled fix path

Work from the smallest verified cause.

If the app handles the challenge

No change may be needed. Confirm successful sign-in, capture the applied policy result, and close the review.

If the app needs an update

Test the supported update with a pilot group. Validate sign-in from the device states and locations that matter, not only from an administrator's managed laptop.

If a temporary exception is unavoidable

Make it explicit:

  • name the affected application and business process
  • scope the exception as narrowly as the platform allows
  • record the risk owner
  • set an expiry date
  • monitor use
  • keep a dated remediation task

Avoid broad user exclusions. Privileged accounts and emergency-access accounts need their own deliberate design; they should not become a convenient test bypass.

Evidence to collect

Keep a compact change record with:

Message Center noticeConfirms tenant-specific communication
Policy exportShows All resources targeting and exclusions
Sign-in log sampleShows resource, result and applied policies
Application scope listConfirms whether the limited-scope case applies
Pilot resultsProves the supported access paths work
Exception recordGives any residual risk an owner and end date

This is a small change with a narrow audience. Treating it precisely avoids two bad outcomes: ignoring a real application dependency, or weakening Conditional Access across the tenant to fix a problem that was never in scope.

If the review finds unexplained exclusions or policies nobody owns, use the Entra ID and Conditional Access consultancy to turn them into a controlled policy set.

References

Related notes

Need help mapping this to your own tenant, controls, or assessment timeline?