Entra ID Conditional Access and Administrative Units: The Scoping Gap That Leaves Admins Unprotected
Retool's new app builder is where AI-generated code ships safely
Building apps with AI is easy. Getting them to production safely is another story.
Administrative Units are widely used for delegated administration in large organizations -- regional IT teams get admin rights over their regional users without Global Admin. The security team then creates CA policies targeting the User Administrator and Password Administrator directory roles to enforce MFA and privileged access controls on these delegated admins. What they do not know (because the Microsoft documentation does not surface this prominently) is that the CA role condition only matches tenant-wide role assignments. The regional admins with AU-scoped assignments are not covered. They authenticate without the enforced controls.
Reproduce the Gap: How to Verify It in Your Tenant
To verify whether this gap affects your tenant: identify a CA policy that targets a specific directory role (for example, a policy requiring phishing-resistant MFA for the User Administrator role). Check whether any users in your tenant hold that role scoped to an Administrative Unit (Entra admin center > Roles and Administrators > User Administrator > filter by scope). Sign in as one of the AU-scoped admin users and check the Conditional Access sign-in log. The CA policy targeting User Administrator should not appear in the CA results for this user's sign-in -- confirming they were not evaluated against it. Alternatively, check the policy definition in Conditional Access: a policy with Assignments > Users > Directory roles > User Administrator only matches users with the tenant-wide User Administrator assignment. AU-scoped assignments have a different role activation path and are not enumerated by the directory role condition.
Enumerate All AU-Scoped Role Assignments
Identify which users and which roles are affected by AU scoping in your tenant. PowerShell with Microsoft Graph: $scopedRoles = Get-MgDirectoryRoleScopedMember -All; $scopedRoles | Select-Object RoleId, RoleDisplayName, PrincipalId, PrincipalDisplayName, DirectoryScopeId | Export-Csv au-scoped-admins.csv. The DirectoryScopeId for tenant-wide assignments is '/' -- any other value (a GUID for an AU) indicates an AU-scoped assignment. Use this export to build a list of all users who hold roles via AU scoping. Cross-reference this list against your Conditional Access policies: for each CA policy that targets a directory role condition, verify whether any AU-scoped holders of that role are covered by the policy through another targeting mechanism (group membership, individual user inclusion). Any AU-scoped admin not covered by a CA policy through another path is operating without the expected privileged access controls.
Briefings like this, every morning before 9am.
Threat intel, active CVEs, and campaign alerts, distilled for practitioners. 50,000+ subscribers. No noise.
Workaround 1: Security Group Targeting
The most practical workaround is to place all privileged administrators -- regardless of whether their roles are tenant-wide or AU-scoped -- into a dedicated security group called something like 'AllPrivilegedAdmins' or 'TieredAccessGroup'. Update the CA policy to target this group instead of (or in addition to) the directory role condition. When a new AU-scoped admin is created, they must also be added to the group. This requires a process: update your AU-scoped admin provisioning procedure to include group addition as a mandatory step. Use Entitlement Management or an identity governance workflow to enforce group addition when an AU-scoped role is assigned. The limitation: this group must be maintained manually -- it does not self-update when AU-scoped role assignments are added. Automate the group maintenance with a Graph API script or Azure Logic App that runs nightly and syncs AU-scoped role members to the privileged admin group.
Workaround 2: All Users Policy with Privileged Role Exceptions
Instead of targeting specific roles in the CA policy, apply the protective CA policy to All Users and carve out specific exclusions. Example: a CA policy requiring phishing-resistant MFA for All Users that accesses Azure Management or the Entra admin center -- this catches all users including AU-scoped admins, regardless of how their role is assigned. The tradeoff: applying privileged access CA requirements to all users means standard users accessing admin portals (which they should not be doing) also get the strong CA requirements. This is actually a desirable security outcome -- any user accessing admin portals should satisfy strong authentication. For organizations where All Users policies are not feasible, use a named location condition to catch admin portal access from non-corporate IP addresses as a fallback.
Design AU Deployments With CA Gaps in Mind
For organizations planning or already using Administrative Units at scale: document which roles are available for AU scoping in your environment and which CA policies are intended to cover them. For each CA policy that targets a directory role, explicitly note whether AU-scoped holders of that role are covered (via group membership or All Users) or are excluded by design. Establish a policy that every user with an AU-scoped privileged role assignment must also be a member of the privileged admin security group used by CA policies. Review this during quarterly privileged access reviews: Get-MgDirectoryRoleScopedMember and compare against the privileged admin group membership. Any AU-scoped admin not in the group should be added or the AU assignment should be reviewed. This is a process gap as much as a technical one -- the technical fix (group targeting) is simple; the ongoing discipline of maintaining the group membership is the harder part.
The bottom line
Conditional Access policies targeting directory roles do not protect AU-scoped administrators of those same roles. The gap is silent -- the CA policy appears correct, the role appears in your directory, but the AU-scoped admins are not evaluated. Fix by maintaining an explicit privileged admin security group that includes all privileged users regardless of assignment scope, and target CA policies at that group rather than the directory role condition. Run a quarterly audit comparing AU-scoped role members against the privileged admin group.
Frequently asked questions
Does this gap also affect Azure RBAC role assignments in Administrative Units?
This specific gap applies to Entra ID directory role assignments (User Administrator, Password Administrator, etc.) scoped to Administrative Units. Azure RBAC role assignments (Owner, Contributor on subscriptions/resource groups) are managed separately via Azure Resource Manager and do not use Entra ID AUs. Azure RBAC-based Conditional Access targeting is configured differently and has its own coverage considerations. The AU scoping gap is specific to Entra directory roles.
Is this a bug that Microsoft will fix?
Microsoft has acknowledged that the directory role condition in Conditional Access applies to tenant-wide role assignments. As of mid-2026, there is no public Microsoft roadmap item to extend the role condition to cover AU-scoped assignments automatically. Microsoft's recommended mitigation is the group-based targeting approach described above. Monitor the Entra ID roadmap (Microsoft 365 roadmap, Entra ID what's new) for any updates to the role condition behavior.
Can I see which CA policies a specific AU-scoped admin was evaluated against?
Yes. In the Entra ID sign-in logs, navigate to a specific sign-in event for the AU-scoped admin user. The Conditional Access tab shows which policies were evaluated, which matched, and which were excluded. A CA policy that uses the directory role condition will show as 'Not applied' for an AU-scoped admin of that role -- the policy was not evaluated because the role condition did not match.
Does Entra ID PIM cover AU-scoped role assignments?
Yes. PIM for Entra ID directory roles does support AU-scoped eligible assignments -- a user can have an eligible assignment for the User Administrator role scoped to a specific AU and activate it via PIM. The PIM activation process itself (MFA requirement, justification, approval) provides protection during the activation step. However, the CA policy gap still applies to the ongoing active session after PIM activation -- the CA role condition still does not recognize the AU-scoped active assignment. The group-based CA targeting workaround must also cover AU-scoped PIM-active assignments.
Should I use Administrative Units as a security boundary or just an operational grouping?
Administrative Units are an operational delegation tool, not a security boundary. The CA scoping gap described in this guide is one example of AUs not providing security isolation. Additionally, AUs do not restrict data access -- a User Administrator scoped to an AU can still read properties of users outside that AU via the Graph API. Treat AUs as a way to delegate administrative tasks to sub-admins without granting tenant-wide roles, but do not rely on AU scoping to isolate security-sensitive operations. For security isolation, use separate tenants (for hard boundaries) or separate Conditional Access groups with explicit privileged access policies (for within-tenant delegation with security controls).
How do Conditional Access policies interact with Entra ID Administrative Unit-scoped role assignments and what gaps exist?
Administrative Units (AUs) allow scoping directory roles so that a User Administrator can only manage users within their assigned AU. However, Conditional Access policies cannot be scoped to AUs -- CA policies always apply tenant-wide or to specific users and groups, not to AU membership. This creates a delegation gap: if you create a CA policy that exempts User Administrators from certain restrictions (to allow them to manage accounts), that exemption applies to all User Administrators in the tenant, not just those scoped to an AU. An attacker who compromises an AU-scoped User Administrator can potentially use that role to bypass CA policies that were intended for a different administrative tier. Additional AU-CA interaction gaps: CA policies targeted at 'All users' do include AU-scoped admin accounts because AU scoping only limits the resources they can manage, not the CA policies that apply to their own authentication. Document all CA policy exemptions and verify they are the minimum necessary scope -- use groups rather than roles as CA targets where possible to limit scope to specifically enumerated accounts.
Sources & references
Free resources
Critical CVE Reference Card 2025–2026
25 actively exploited vulnerabilities with CVSS scores, exploit status, and patch availability. Print it, pin it, share it with your SOC team.
Ransomware Incident Response Playbook
Step-by-step 24-hour IR checklist covering detection, containment, eradication, and recovery. Built for SOC teams, IR leads, and CISOs.
Get threat intel before your inbox does.
50,000+ security professionals read Decryption Digest for early warnings on zero-days, ransomware, and nation-state campaigns. Free, daily, no spam.
Unsubscribe anytime. We never sell your data.
Founder & Cybersecurity Evangelist, Decryption Digest
Cybersecurity professional with expertise in threat intelligence, vulnerability research, and enterprise security. Covers zero-days, ransomware, and nation-state operations for 50,000+ security professionals every morning.
Win a $2,495 Black Hat pass.
Full-access to Black Hat USA 2026 in Las Vegas. Subscribe free to enter.