Entra ID Administrative Units: Scoped Roles and RMAUs

Most Microsoft Entra ID tenants hand their help desk and regional IT teams tenant-wide roles, so a person who only needs to reset passwords in one country can reset them for the whole organisation. Administrative units (AUs) fix this by limiting a role assignment to a defined set of users, groups and devices, and restricted management administrative units (RMAUs) go further by locking sensitive objects away from tenant-level administrators. This guide explains how both work, which roles can be scoped, where the boundaries leak, and how to design, roll out and monitor a delegation model built on them. It is written for identity architects, Entra administrators and security teams. For the roles themselves and the admin centres they control, see the Microsoft 365 admin centres and admin roles guide; this page covers how to scope them.

This is an independent guide from NHI Mgmt Group, based on Microsoft's public documentation as of November 2026. It is not sponsored or reviewed by Microsoft. Product features change, so confirm settings against Microsoft's current documentation.

Key takeaways

An AU limits management, not visibility. A scoped administrator can change only the AU's members, but every user can still browse the directory with default user permissions.
Adding a group does not add its members. A scoped User Administrator can rename a group in the AU and change its membership, but cannot reset the passwords of its members unless those users are added to the AU directly.
Scoped roles cannot touch privileged users. A scoped Helpdesk Administrator cannot reset the password or authentication methods of a user who holds any role with organisation-wide scope, which blocks the obvious escalation path.
RMAUs reverse the default. Objects in a restricted management AU can be changed only by administrators assigned at that AU's scope; Global Administrators are blocked until they assign themselves, which is an audited event.
Plan licences and limits early. Each AU-scoped administrator needs Entra ID P1, each member of a dynamic AU needs P1, AUs cannot be nested, and a tenant can hold at most 100 RMAUs.

How administrative units work

An administrative unit is a Microsoft Entra resource that contains other Entra resources. When a role is assigned with AU scope, its permissions apply only when managing members of that AU and do not extend to tenant-wide settings. A role assigned without AU scope applies to the entire tenant. Microsoft compares AUs to organisational units in Windows Server Active Directory, with one important difference: the AU only defines a management boundary. It does not hide objects or change where they live.

Members: an AU can contain only users, groups and devices. A user, group or device can belong to several AUs at once, and can still be managed by tenant-wide administrators as well as by every AU-scoped administrator whose scope includes it.
No nesting: AUs cannot contain other AUs, so a region-and-department hierarchy has to be flattened into separate units or expressed through multiple membership.
Group semantics: placing a group in an AU brings the group object into scope (name, description, membership) but not the users inside it. This catches many teams out; the FAQ confirms that users must be assigned to the AU directly.
Hidden membership: the Microsoft Graph administrativeUnit resource has a visibility property that can be set to HiddenMembership, after which only members of the unit can list its other members.
Where it works: the Microsoft Entra admin center, Microsoft Graph and PowerShell support the full feature set; the Microsoft 365 admin center supports a subset and filters users outside the admin's AUs from view. AUs are not available in Azure AD B2C tenants, and Microsoft states that managing devices in Intune through AU scope is not supported.

Creating an AU requires at least the Privileged Role Administrator role. Microsoft describes three lifecycle stages: initial adoption, when criteria are defined and the number of units grows; pruning, when unneeded units are deleted; and stabilisation, when the structure settles.

Roles you can scope to an administrative unit

Only some built-in roles accept AU scope. Custom roles can also be scoped if their permissions include at least one permission relevant to users, groups or devices. The table lists the built-in roles Microsoft documents as AU-assignable and what each can do inside the unit.

Role	What it can do inside the AU	Typical delegation use
Helpdesk Administrator	Reset passwords for non-administrators	Regional or site service desk
Password Administrator	Reset passwords for non-administrators	Narrower alternative to Helpdesk Administrator
Authentication Administrator	View, set and reset authentication method information for non-admin users	Re-registering MFA after a lost phone
Privileged Authentication Administrator	View, set and reset authentication methods for any user in the AU, including admins	Executive or VIP support team, usually inside an RMAU
User Administrator	Manage all aspects of users and groups, including resetting passwords for limited admins	Local IT for a business unit or school
Groups Administrator	Manage all aspects of groups	Department owner of its own security groups
License Administrator	Assign, remove and update licence assignments	Subsidiary licence management
Cloud Device Administrator	Limited device management, such as enabling, disabling and deleting devices and reading BitLocker recovery keys	Site desktop support
Attribute Assignment Administrator and Reader	Update or read custom security attribute assignments for users or service principals	Data owners tagging their own population
SharePoint Administrator and Teams Administrator	Manage Microsoft 365 groups in the AU, with limited site or team actions through the Microsoft 365 admin center only	Collaboration leads for one division
Printer Administrator and Teams Devices Administrator	Manage printers and connectors, or Teams-certified devices	Facilities and meeting-room support

Built-in protections for privileged targets

When the target user holds another role or is an administrator, scoped roles are blocked from reading or changing authentication methods, resetting the password, modifying sensitive properties such as telephone numbers, alternate email addresses and OAuth secret keys, and deleting or restoring the account. A scoped Password Administrator therefore cannot reset the password of a user in the same AU who holds a tenant-wide role. This is the control that stops a regional help desk from taking over a Global Administrator who happens to sit in its region.

Who can hold a scoped role

AU-scoped roles can be assigned to users, role-assignable groups and service principals. Service principals and guest users also need tenant-level read access, such as the Directory Readers role, because directory read permissions cannot be scoped to an AU. Scoped administrators cannot change tenant-wide settings: a Groups Administrator scoped to an AU cannot manage group expiration or naming policies.

Assigned and dynamic membership

An AU's membership is either assigned (managed by administrators) or dynamic (driven by a rule). The Graph properties are membershipType (assigned or dynamic), membershipRule and membershipRuleProcessingState (On or Paused).

Aspect	Assigned AU	Dynamic AU
Object types	Users, groups and devices in one AU	Users or devices, one type per AU; groups cannot be added by rule
Who changes membership	Administrators, through the portal, Graph or PowerShell	Only the rule engine; add and remove commands are disabled
Rule syntax	Not applicable	Same syntax and attributes as dynamic membership groups, up to 3,072 characters
Licensing	Members need Entra ID Free	Members need Entra ID Free; scoped administrators need P1
Tenant limit	Standard directory limits	Dynamic groups and dynamic AUs together cannot exceed 15,000 per tenant
Where to manage	Entra admin center, Microsoft 365 admin center, Graph, PowerShell	Entra admin center, Graph, PowerShell; not the Microsoft 365 admin center
Cloud availability	All Entra clouds where AUs are offered	Global Azure only, not Azure Government or Azure operated by 21Vianet

Choose dynamic when a reliable, HR-sourced attribute such as user.country, user.department or user.companyName defines the population. Movers then leave the old admin's scope automatically, which assigned AUs cannot do without a process.
Choose assigned when you need groups in the unit, when the population is small and hand-picked (executives, a project team), or when the attribute is unreliable. A bad attribute in a dynamic rule silently moves people in and out of an administrator's reach.
Exceptions: to add one extra member to a dynamic AU, Microsoft's FAQ says to extend the rule with an OR expression rather than adding the object by hand.
Attribute integrity: whoever can edit the attribute behind a dynamic rule effectively controls AU membership. Make sure scoped administrators cannot write the attributes that define their own scope, or a local admin can pull a user into reach by editing their department.

Restricted management administrative units

A restricted management administrative unit is created with the Graph property isMemberManagementRestricted set to true. The setting can be chosen only at creation and cannot be changed later. For any administrator not explicitly assigned at the RMAU's scope, operations that directly modify the Entra properties of its members are blocked. Microsoft's example problems are a Helpdesk Administrator resetting a chief executive's password and a tenant-level Groups Administrator adding people to a security group that grants access to financial data.

Who is acting	Can modify RMAU members?
Global Administrator or Privileged Role Administrator at tenant scope	No, but can create and delete RMAUs, change membership and assign roles at RMAU scope, including to themselves
User Administrator, Groups Administrator or any other built-in or custom role at tenant scope	No
Owners of groups or devices placed in the RMAU	No
A role assigned at the scope of this RMAU, or another RMAU the object belongs to	Yes
A role assigned at the scope of a regular AU the object also belongs to	No
An application holding Microsoft Graph application permissions	No; the application needs an Entra role assigned at the RMAU scope

The restriction applies only to Entra properties. Reading standard properties, adding RMAU members to other groups, changing Exchange mailbox settings, applying Intune policies to RMAU devices, assigning licences and setting usage location all remain possible for tenant administrators. RMAUs support users, devices and security groups only; Microsoft 365 groups, mail-enabled security groups and distribution groups cannot be members.

RMAU limitations to plan around

Governance features stop working: users and groups in an RMAU cannot be managed with Privileged Identity Management, entitlement management, lifecycle workflows or access reviews. Weigh this before placing a whole population in one.
Public groups bypass the lock: a group with Public visibility allows self-service joining. Microsoft calls this a temporary limitation and does not recommend public groups in RMAUs.
Role-assignable groups: group owners cannot change their membership inside an RMAU, and only Global Administrators and Privileged Role Administrators can, which cannot be AU-scoped.
Locked-out administrators: a Global Administrator who is a member of an RMAU cannot have their password reset by other admins until they are removed from the unit.
Deletion lag and cap: deleting an RMAU can take up to 30 minutes to lift protection, and a tenant can have at most 100 RMAUs.

Designing a delegation model

Start from who needs to manage whom, not from the org chart. The Microsoft 365 admin centres guide covers which roles to use; the AU design decides the boundary for each.

Pattern	AU type	Scoped roles	Watch out for
Regional service desk	Dynamic user AU per country, plus a dynamic device AU	Helpdesk or Password Administrator, Authentication Administrator	Country attribute quality; travelling or seconded staff
Subsidiary or school IT	Assigned or dynamic AU by company or school	User Administrator, Groups Administrator, License Administrator	User Administrator can manage all groups in scope; keep sensitive groups out
Executive protection	Assigned RMAU with executives and their devices	Privileged Authentication Administrator and Cloud Device Administrator for a named VIP team	Loss of PIM and access reviews for those users; recovery if the VIP team leaves
Sensitive access groups	Assigned RMAU of security groups that grant finance, HR or production access	Groups Administrator for the data owner's team	Public visibility; role-assignable group rules
Contractor or partner population	Dynamic AU on an employee type or company attribute	User Administrator for the vendor manager team	Guests and service principals need tenant-level read

Small versus large organisations

Under about 1,000 users: a single IT team rarely benefits from many AUs. The best return is usually one RMAU for executives and the security groups that gate sensitive data, because it protects the accounts attackers target through the help desk.
Multi-region or federated organisations: scope every help desk and local IT role, and treat tenant-scoped User Administrator and Helpdesk Administrator as exceptions that need justification. Combine with role-assignable groups so scope is granted to a team, not to individuals.
Managed service providers: partner admin access is handled by granular delegated admin privileges, not AUs. See the GDAP and MSP Delegated Admin Access Guide.

Where identity fits

Automation is the overlooked consumer of AUs. A provisioning or joiner-mover-leaver workflow that runs as a service principal with tenant-wide User Administrator can modify every user in the tenant, including administrators it has no reason to touch. Assigning the role to that service principal at AU scope narrows its reach to the population it serves, at the cost of also granting Directory Readers at tenant scope. Note the RMAU rule: Microsoft Graph application permissions such as User.ReadWrite.All do not apply to RMAU members, so an integration that suddenly fails against executive accounts may be meeting a restricted unit rather than a bug. See the Entra ID Applications and Consent Guide and the Least Privilege Techniques Guide.

Implementing administrative units

Inventory current assignments: export every tenant-scoped assignment of the AU-assignable roles listed above, and note who uses each and for which population. These are your candidates for scoping.
Fix the source attributes: check completeness and accuracy of the attributes your dynamic rules will use, and restrict who can write them.
Build units in a pilot: create one dynamic user AU and one device AU for a single region, confirm membership after the initial population run (it can take several minutes), and set membershipRuleProcessingState to Paused if results look wrong.
Assign scoped roles to groups: in the Entra admin center go to Entra ID, Roles and admins, Admin units, select the unit, then Roles and administrators. Custom roles must be assigned from inside the AU, not from the Roles and admins page. Use role-assignable groups so membership changes do not need role changes.
Run both assignments in parallel: keep the tenant-scoped role for one or two weeks while the team works with the scoped one, then remove the tenant-wide assignment. Rollback is simply re-adding it.
Add RMAUs last and carefully: because the restricted flag is immutable and RMAU members lose PIM, access reviews and lifecycle workflows, create a test RMAU with test accounts first. Write down who can recover access if the scoped team leaves.
Govern the units: limit AU and RMAU management to Privileged Role Administrators, review scoped assignments quarterly, and prune units that no longer match the organisation.

Detection and measurement

AU changes are delegation changes, so treat them like role changes. Microsoft Entra audit logs record these activities, which should feed your SIEM. See the Entra ID Audit Log Detection Guide.

Audit category	Activity	Why it matters
AdministrativeUnit	Add administrative unit (including `IsMemberManagementRestricted` = true for RMAUs)	New delegation boundary; RMAU creation should be rare and ticketed
AdministrativeUnit	Add or remove member from an AU or RMAU	Removing an executive from an RMAU lifts protection; adding a user to an AU puts them in reach of local admins
RoleManagement	Add or remove member from a role scoped over an AU or RMAU	A Global Administrator assigning themselves to an RMAU is the documented break-the-seal event and should page someone

Useful metrics:

Scoped share: percentage of Helpdesk, Password, Authentication and User Administrator assignments that are AU-scoped rather than tenant-wide.
Tenant-wide holders: count of people with tenant-scoped User Administrator or Helpdesk Administrator, trending down.
Executive coverage: percentage of named executive and high-impact accounts that sit in an RMAU.
RMAU break-ins: number of self-assignments to RMAU scope by tenant administrators, each with a matching ticket.
Orphaned units: AUs with no scoped role assignment, or scoped assignments to disabled users.

Common failure patterns

Scoping a group and assuming its members are covered: the scoped admin can edit group membership but not the users, so the team asks for the tenant-wide role back and the project stalls.
Treating AUs as a privacy boundary: AUs restrict management only. Every user can still browse users and groups outside the unit, and the Entra admin center and PowerShell still show them to scoped admins.
Leaving tenant-wide roles in place: adding a scoped assignment without removing the tenant one changes nothing. The help desk social engineering attacks covered in the Vishing and Help Desk Social Engineering Awareness Guide succeed against any operator who can reset anyone.
Dynamic rules on writable attributes: a local admin who can edit department can move a user into their own AU and then reset them.
RMAUs with no recovery plan: when the only scoped administrators leave, a Global Administrator must assign someone; without a procedure, people improvise under pressure. Pair RMAUs with the Break-Glass Account Guide.
Putting governed populations in RMAUs: moving users who rely on access reviews, entitlement management or PIM into an RMAU quietly switches those controls off for them.

Framework mapping

Framework	Reference	How AUs support it
NIST SP 800-53 Rev 5	AC-6 Least Privilege; AC-6(5) Privileged Accounts	Scoped roles limit administrative rights to the population each team serves
NIST SP 800-53 Rev 5	AC-5 Separation of Duties	RMAUs separate who can change sensitive accounts and groups from general administrators
NIST SP 800-53 Rev 5	AC-2 Account Management; AC-6(7) Review of User Privileges	Scoped assignments are reviewed and pruned like any role
NIST CSF 2.0	PR.AA-05	Access permissions managed with least privilege and separation of duties
NIST CSF 2.0	DE.CM-03	Monitoring AU and scoped role changes in audit logs
ISO/IEC 27001:2022 Annex A	5.15 Access control; 5.18 Access rights; 8.2 Privileged access rights	Documented, restricted and reviewed administrative access
MITRE ATT&CK v20	T1098.003 Additional Cloud Roles; T1078.004 Cloud Accounts	Fewer tenant-wide admins reduce the value of each compromised account and the paths to add roles

Practitioner checklist

Export all tenant-scoped Helpdesk, Password, Authentication, User and Groups Administrator assignments and justify each one.
Define AUs by region, subsidiary or business unit using reliable HR-sourced attributes, and lock down who can write them.
Add users and devices to AUs directly; do not rely on group membership to bring users into scope.
Assign scoped roles to role-assignable groups, and grant Directory Readers at tenant scope to any service principal or guest that holds a scoped role.
Remove tenant-wide assignments once scoped ones are proven, keeping a documented rollback.
Place executives, their devices and the security groups that gate sensitive data in a restricted management AU, after testing with non-production accounts.
Avoid Public visibility for groups in RMAUs, and record who can recover access if the RMAU administrators leave.
Alert on RMAU creation, RMAU membership removal and any self-assignment at RMAU scope.
Budget Entra ID P1 for every scoped administrator and every member of a dynamic user AU.
Review AUs and scoped assignments quarterly and delete units with no purpose.

Entra ID Administrative Units Guide: Scoping Admin Roles and Restricted Management Units