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 prepar...
Updated Mar 17, 2026
Version 3.0
entra id
identity security
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

     

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

      Windows Azure Active Directory, application ID: 00000002-0000-0000-c000-000000000000

      Is a default application in each Entra tenant that is used to in Conditional Access evaluation of the low-privilege scopes that are affected by this change

      (openid, profile, user.read, etc)

       

      Excluding that app would (to my understanding) effectively "nullify" / "cancel out" this change, and keep the behavior as it was before the change. Which obviously is NOT a recommended path forward, but could perhaps work as a workaround until you have a better fix in place that allows.

      Please note that excluding this app may also remove MFA requirement from any older/legacy self-developed apps that are still using the "Azure AD Graph API" instead of the "Microsoft Graph" API

      (Azure AD Graph API is currently deprecated and slowly being retired, so ideally there should not be anything using it anymore)

      --

      After further investigation into my previous thought on option3 i realize it wont work as CA is additive and the "most restrictive" condition wins, which in that case would be the MFA, not the grant access from the new policy, so dont mind that option, i kind of wrote that out of my head thinking it would apply in a reversed order for some reason.

      -