{ "id": "36747b8e-fea7-4248-afb9-cabd281df92d", "created_at": "2026-04-06T00:08:42.302516Z", "updated_at": "2026-04-10T03:21:11.343458Z", "deleted_at": null, "sha1_hash": "6f0803944b2d156b9746d2a833dd809d783bf052", "title": "Manage users excluded from Conditional Access policies - Microsoft Entra ID Governance", "llm_title": "", "authors": "", "file_creation_date": "0001-01-01T00:00:00Z", "file_modification_date": "0001-01-01T00:00:00Z", "file_size": 740105, "plain_text": "Manage users excluded from Conditional Access policies -\r\nMicrosoft Entra ID Governance\r\nBy OWinfreyATL\r\nArchived: 2026-04-05 20:44:21 UTC\r\nIn an ideal world, all users follow the access policies to secure access to your organization's resources. However,\r\nsometimes there are business cases that require you to make exceptions. This article goes over some examples of\r\nsituations where exclusions could be necessary. You, as the IT administrator, can manage this task, avoid oversight\r\nof policy exceptions, and provide auditors with proof that these exceptions are reviewed regularly using Microsoft\r\nEntra access reviews.\r\nNote\r\nA valid Microsoft Entra ID P2 or Microsoft Entra ID Governance, Enterprise Mobility + Security E5 paid, or trial\r\nlicense is required to use Microsoft Entra access reviews. For more information, see Microsoft Entra editions.\r\nLet's say that as the administrator, you decide to use Microsoft Entra Conditional Access to require multifactor\r\nauthentication (MFA) and limit authentication requests to specific networks or devices. During deployment\r\nplanning, you realize that not all users can meet these requirements. For example, you could have users who work\r\nfrom remote offices, not part of your internal network. You could also have to accommodate users connecting\r\nusing unsupported devices while waiting for those devices to be replaced. In short, the business needs these users\r\nto sign in and do their job so you exclude them from Conditional Access policies.\r\nAs another example, you might be using named locations in Conditional Access to specify a set of countries and\r\nregions from which you don't want to allow users to access their tenant.\r\nUnfortunately, some users might still have a valid reason to sign in from these blocked countries/regions. For\r\nexample, users could be traveling for work and need to access corporate resources. In this case, the Conditional\r\nAccess policy to block these countries/regions could use a cloud security group for the excluded users from the\r\npolicy. Users who need access while traveling, can add themselves to the group using Microsoft Entra self-service\r\nGroup management.\r\nAnother example might be that you have a Conditional Access policy blocking legacy authentication for most of\r\nyour users. However, if you have some users that need to use legacy authentication methods to access specific\r\nresources, then you can exclude these users from the policy that blocks legacy authentication methods.\r\nNote\r\nMicrosoft strongly recommends that you block the use of legacy protocols in your tenant to improve your security\r\nposture.\r\nhttps://docs.microsoft.com/en-us/azure/active-directory/governance/conditional-access-exclusion\r\nPage 1 of 9\n\nIn Microsoft Entra ID, you can scope a Conditional Access policy to a set of users. You can also configure\r\nexclusions by selecting Microsoft Entra roles, individual users, or guests. You should keep in mind that when\r\nexclusions are configured, the policy intent can't be enforced on excluded users. If exclusions are configured using\r\na list of users or using legacy on-premises security groups, you have limited visibility into the exclusions. As a\r\nresult:\r\nUsers might not know that they're excluded.\r\nUsers can join the security group to bypass the policy.\r\nExcluded users could have qualified for the exclusion before but no longer qualify for it.\r\nFrequently, when you first configure an exclusion, there's a shortlist of users who bypass the policy. Over time,\r\nmore users get added to the exclusion, and the list grows. At some point, you need to review the list and confirm\r\nthat each of these users is still eligible for exclusion. Managing the exclusion list, from a technical point of view,\r\ncan be relatively easy, but who makes the business decisions, and how do you make sure it's all auditable?\r\nHowever, if you configure the exclusion using a Microsoft Entra group, you can use access reviews as a\r\ncompensating control, to drive visibility, and reduce the number of excluded users.\r\nFollow these steps to create a new Microsoft Entra group and a Conditional Access policy that doesn't apply to\r\nthat group.\r\n1. Sign in to the Microsoft Entra admin center as at least a User Administrator.\r\n2. Browse to Entra ID \u003e Groups \u003e All groups.\r\n3. Select New group.\r\n4. In the Group type list, select Security. Specify a name and description.\r\n5. Make sure to set the Membership type to Assigned.\r\n6. Select the users that should be part of this exclusion group and then select Create.\r\nhttps://docs.microsoft.com/en-us/azure/active-directory/governance/conditional-access-exclusion\r\nPage 2 of 9\n\nNow you can create a Conditional Access policy that uses this exclusion group.\r\n1. Sign in to the Microsoft Entra admin center as at least a Conditional Access Administrator.\r\n2. Browse to Entra ID \u003e Conditional Access.\r\n3. Select Create new policy.\r\n4. Give your policy a name. We recommend that organizations create a meaningful standard for the names of\r\ntheir policies.\r\n5. Under Assignments select Users and groups.\r\n6. On the Include tab, select All Users.\r\n7. Under Exclude, select Users and groups and choose the exclusion group you created.\r\nNote\r\nAs a best practice, it is recommended to exclude at least one administrator account from the policy when\r\ntesting to make sure you are not locked out of your tenant.\r\n8. Continue with setting up the Conditional Access policy based on your organizational requirements.\r\nhttps://docs.microsoft.com/en-us/azure/active-directory/governance/conditional-access-exclusion\r\nPage 3 of 9\n\nLet's cover two examples where you can use access reviews to manage exclusions in Conditional Access policies.\r\nLet's say you have a Conditional Access policy that blocks access from certain countries/regions. It includes a\r\ngroup that is excluded from the policy. Here's a recommended access review where members of the group are\r\nreviewed.\r\nhttps://docs.microsoft.com/en-us/azure/active-directory/governance/conditional-access-exclusion\r\nPage 4 of 9\n\nhttps://docs.microsoft.com/en-us/azure/active-directory/governance/conditional-access-exclusion\r\nPage 5 of 9\n\n1. The review happens every week.\r\n2. The review never ends in order to make sure you're keeping this exclusion group most up to date.\r\n3. All members of this group are in scope for the review.\r\n4. Each user needs to self-attest that they still need access from these blocked countries/regions, therefore\r\nthey still need to be a member of the group.\r\n5. If the user doesn't respond to the review request, they're automatically removed from the group, and no\r\nlonger has access to the tenant while traveling to these countries/regions.\r\n6. Enable email notifications to let users know about the start and completion of the access review.\r\nLet's say you have a Conditional Access policy that blocks access for users using legacy authentication and older\r\nclient versions and it includes a group that is excluded from the policy. Here's a recommended access review\r\nwhere members of the group are reviewed.\r\nhttps://docs.microsoft.com/en-us/azure/active-directory/governance/conditional-access-exclusion\r\nPage 6 of 9\n\nhttps://docs.microsoft.com/en-us/azure/active-directory/governance/conditional-access-exclusion\r\nPage 7 of 9\n\n1. This review would need to be a recurring review.\r\n2. Everyone in the group would need to be reviewed.\r\n3. It could be configured to list the business unit owners as the selected reviewers.\r\n4. Auto-apply the results and remove users that aren't approved to continue using legacy authentication\r\nmethods.\r\n5. It might be beneficial to enable recommendations so reviewers of large groups can easily make their\r\ndecisions.\r\n6. Enable mail notifications so users are notified about the start and completion of the access review.\r\nNow that you have everything in place, group, Conditional Access policy, and access reviews, it's time to monitor\r\nand track the results of these reviews.\r\n1. Sign in to the Microsoft Entra admin center as at least an Identity Governance Administrator.\r\n2. Browse to ID Governance \u003e Access reviews.\r\n3. Select the Access review you're using with the group you created an exclusion policy for.\r\n4. Select Results to see who was approved to stay on the list and who was removed.\r\nhttps://docs.microsoft.com/en-us/azure/active-directory/governance/conditional-access-exclusion\r\nPage 8 of 9\n\n5. Select Audit logs to see the actions that were taken during this review.\r\nAs an IT administrator, you know that managing exclusion groups to your policies is sometimes inevitable.\r\nHowever, maintaining these groups, reviewing them regularly by the business owner or the users themselves, and\r\nauditing these changes can be made easier with access reviews.\r\nCreate an access review of groups or applications\r\nWhat is Conditional Access in Microsoft Entra ID?\r\nSource: https://docs.microsoft.com/en-us/azure/active-directory/governance/conditional-access-exclusion\r\nhttps://docs.microsoft.com/en-us/azure/active-directory/governance/conditional-access-exclusion\r\nPage 9 of 9", "extraction_quality": 1, "language": "EN", "sources": [ "MITRE" ], "references": [ "https://docs.microsoft.com/en-us/azure/active-directory/governance/conditional-access-exclusion" ], "report_names": [ "conditional-access-exclusion" ], "threat_actors": [], "ts_created_at": 1775434122, "ts_updated_at": 1775791271, "ts_creation_date": 0, "ts_modification_date": 0, "files": { "pdf": "https://archive.orkl.eu/6f0803944b2d156b9746d2a833dd809d783bf052.pdf", "text": "https://archive.orkl.eu/6f0803944b2d156b9746d2a833dd809d783bf052.txt", "img": "https://archive.orkl.eu/6f0803944b2d156b9746d2a833dd809d783bf052.jpg" } }