Blog Post

Microsoft Entra Blog
3 MIN READ

Upcoming Conditional Access change: Improved enforcement for policies with resource exclusions

Swaroop Krishnamurthy's avatar
Swaroop Krishnamurthy
Icon for Microsoft rankMicrosoft
Jan 28, 2026

We’re strengthening how Microsoft Entra Conditional Access is enforced for a narrow set of authentication flows to improve your security posture.

In alignment with Microsoft’s Secure Future Initiative, we are taking the following proactive security measures for defense-in-depth. Please review the changes and take any required actions to prepare.

Note: We’ve adjusted the rollout timeline, with enforcement now starting on May 13, 2026. To support a smooth transition, customers will receive additional details and guidance through Microsoft 365 Message Center messages.

What is changing?

  • Today, when a user signs in through a client application that requests only OIDC scopes or a limited set of directory scopes, Conditional Access policies that target All resources are not enforced if the policy has one or more resource exclusions.
  • After this change, Conditional Access policies that target All resources will be enforced for these sign-ins, even when resource exclusions are present. This ensures that policies are consistently applied regardless of the scope set requested by the application. Read more about this change.

When will you see this change?

We’ve adjusted the rollout timeline, with enforcement now starting on May 13, 2026. To support a smooth transition, customers will receive additional details and guidance through Microsoft 365 Message Center messages.

Who will be affected by this change?

This change only affects tenants that have a Conditional Access policy targeting All resources with one or more resource exclusions, and these tenants will be notified through M365 Message Center messages. Tenants without this policy configuration will not be impacted.

How will this affect your organization?

When a user signs in through a client application that requests only the scopes listed above, they may now receive Conditional Access challenges (such as MFA or device compliance) where previously they were allowed access without enforcement. The specific challenge depends on the access controls configured in your policies that target All resources or explicitly target Azure AD Graph as the resource.

What do you need to do to prepare?

✔ Most customers: No action required

Most applications request additional scopes beyond the scopes listed above and are already subject to Conditional Access enforcement. In such cases, there is no change in behavior. We’re working with popular software vendors where updates may be needed to ensure their applications handle Conditional Access challenges appropriately.

⚠ Apps registered in your tenant and requesting only these scopes: Review recommended

If you have custom applications that are intentionally designed to request only the scopes listed above, evaluate whether they can handle Conditional Access challenges such as MFA or device compliance.

If they already handle Conditional Access challenges: no changes are required. If they do not, updates may be needed. Refer to the Microsoft Conditional Access developer guidance on how to update your application appropriately.

-Swaroop Krishnamurthy

 

Additional resources 

Learn more about Microsoft Entra

Prevent identity attacks, ensure least privilege access, unify access controls, and improve the experience for users with comprehensive identity and network access solutions across on-premises and clouds.

Updated Mar 17, 2026
Version 3.0
entra id
identity security

10 Comments

  • povlhp's avatar
    povlhp
    Copper Contributor
    Apr 07, 2026

    Already active here on some CA rules. This is the worst decision from Microsoft in a long time.

    We have tens of thousands of floor workers with no MFA method. They use some custom Microsoft apps, and we tried to use custom Apps fully, with permissions and everything, and acting as the signed in user.

    It seems that for those users (and for B2B users) we will have to drop MFA by default, as we can't exempt individual apps, and maybe move to enforcing MFA on specific apps only if that will work ? Or strip Microsoft Graph from MFA requirement for most users. This really will lower security.

    I can see one more workaround, a Custom Multifactor Strength, that includes password (aka single factor), targeting some users. But if we need to put it on Microsoft Graph, things are really bad.

    Please show me the considerations/user story for floor employees, accessing a custom application from a personal device at home, no MFA - no access to company confidential data (say a non-public intranet) - We generally require MFA for other things. And some floor workers might have mail where we require MFA - so they would be MFA ready. Do you think we can/will micromanage group memberships to control this ? 

    How about B2B ? Some have higher permissions and directory roles, they need phishing resistant MFA, others needs just a password. Again our security will then depend on our ability to micromanage groups ? rather than exempt the few apps with low security requirements ?

  • SIVASELVARAJ's avatar
    SIVASELVARAJ
    Copper Contributor
    Mar 25, 2026

    Running into a challenge with the new Conditional Access behavior for “All cloud apps” + exclusions.

    Consider a scenario where organizations exclude apps like Microsoft Intune Company Portal (Linux), Jamf Pro macOS enrollment, and Azure AD connectors for Jamf (macOS login / enrollment flows) from CA policies (e.g., device compliance or MFA).

    With the new behavior, sign-ins are still impacted.

    The reason: Conditional Access now evaluates all resources involved in the request, not just the primary app. These flows depend on Microsoft Graph (e.g., openid, profile, User.Read), and since Graph isn’t excluded, the policy is enforced.

    This introduces challenges for common scenarios:

    • Device enrollment (Jamf Pro, Intune, macOS - login)
    • Platform-specific flows (Linux, macOS)
    • Cases where exclusions were previously used to prevent onboarding devices for compliance enrollment.

    Curious how others are approaching this:
    What’s the recommended design pattern to support these enrollment/login flows without weakening Conditional Access posture by exluding primary resources such as Microsoft Graph and Windows Azure Active Directory?

     

    • c14g-Services's avatar
      c14g-Services
      Copper Contributor
      Mar 31, 2026

      Ouch, I think TD Synnex just started rolling this out and borked ALL of their sharepoint shares.  Heads should be rolling at Microsoft AND Synnex for this one. I lost thousands of dollars today because I can't download something I NEED from their sharepoint site and they aren't willing to send the xlsx file like everyone else does in the world. They just lost my future business. I wonder how much this eff up will cost them from other clients leaving.

  • pfasser's avatar
    pfasser
    Brass Contributor
    Feb 23, 2026

    Hello all, in AVD environment you need to disable MFA for the storage account used for profile management: https://learn.microsoft.com/en-us/azure/storage/files/storage-files-identity-auth-hybrid-identities-enable?tabs=azure-portal%2Cintune#disable-multifactor-authentication-on-the-storage-account

    When you are configuring the storage file setup, it automatically creates the Entra application with the following API permission:

     

     

     

     

     

    How is this change affecting the profile management service?

    • kimpa's avatar
      kimpa
      Copper Contributor
      Apr 08, 2026

      From what i understand, which may be wrong, this will be our options for any app/resource exclusions using "low privilege permissions" moving forward, including AVD storageAccounts.

      1. Remove app exclusion from "main" MFA policy, this will then require MFA (not applicable for AVD)
      2. Alternatively exclude the "Windows Azure Active Directory" app from the CA policy (this effectively cancels the new change, lowering/resetting security to "pre-change")
      3. Create a separate CA policy "grant access, no MFA" for resources affected by the change, and leave the old "all resources" policy in place, without exclusions (i.e. remove old "app/resource exclusions from the "main" policy)
      4. (this option only feasible on self-develope applications) Add additional API permissions in the scope for the token request, and the same permissions on the affected appregistration resource (i.e. something more stringent than openid, profile, user.read), thus also "overriding" this new change (extraced from MS learn article: "There is no change in behavior when a client application requests a scope beyond those listed previously, as illustrated in the following examples.")

       

      I think for AVD, and possibly other apps that only require "openid, profile, user.read", option 3 should be the best way forward. 

      The evaluation of CA should then compile all policies during evaluation and apply the rules that trigger closest to the resource being evaluated, in this case it should be the resources with individual targets in the policy created in point 3. In this way, the "all resources"/"main" policy is filtered out of that evaluation and the policy in point 3 takes effect. 

      This is currently a hypothesis on top of my head and will of course need to be fully evaluated and validated before it can be presented as a viable solution...

      With that said it may provide some options to test and verify to get every app up and running again post this new CA "low-priv permissions" evaluation change.

      • povlhp's avatar
        povlhp
        Copper Contributor
        Apr 08, 2026

        For now I asked developers to to refactor their code, and make 2 login buttons - each with their app registration. One for internal users, and one for the external nonMFA.

        Since it was activated for us around March 20 (the announcement), we are in a bit of a hurry. The May 13th does niot apply to us it seems.

        What is the "Windows Azure Active Directory" app ? Will excluding that really work ? What are the side effects ? Will I disable MFA from more than just the excluded apps ?

        BTW: How will 3 work ? If I have MFA on all apps in another ? 

        I have User.Read and User.Read.All triggering the MFA

         

    • JonasBack's avatar
      JonasBack
      Steel Contributor
      Mar 17, 2026

      Also wondering about this since it’s the most common exclude we see.

  • Rafal_Fitt's avatar
    Rafal_Fitt
    Steel Contributor
    Jan 29, 2026

    You can identify applications affected by this enforcement change

    https://learn.microsoft.com/en-us/entra/identity/conditional-access/concept-conditional-access-cloud-apps?tabs=powershell#how-to-identify-applications-affected-by-the-low-privilege-scope-enforcement-change