In real Entra ID environments, one problem comes up again and again: who is allowed to manage the accounts that really matter? I mean C-level users, emergency access accounts and highly privileged admins. The risk grows when several IT providers or scattered admin teams share a tenant. A User Administrator with good intentions (or bad ones) can reset the CEO's password or offboard a break glass account by mistake. The built-in admin roles cover too much for this. Giving someone User Administrator at tenant level just isn't safe here. Restricted management administrative units close that gap. You can now lock down admin rights for selected accounts so that only a small, intended group can change them.

Restricted management AUs limit who can manage an account

Administrative units (AUs) have been part of Entra ID for some time. The restricted management option is what makes them useful for this problem. When you create an AU (Microsoft Entra admin center → Identity → Roles & admins → Admin units → Add), there is a toggle called "Restricted management administrative unit". You have to set it at creation, and you can't change it afterwards. Once sensitive accounts are in a restricted AU, only admins whose roles (for example User Administrator or Password Administrator) are scoped specifically to that AU can manage those users. Global Administrators and User Administrators at tenant level lose most of their rights to modify these accounts. An admin needs an Entra ID P1 licence to receive an AU-scoped role. Microsoft's documentation on restricted management AUs is a good reference.

The diagram below shows the idea. Sensitive accounts sit in a restricted AU, AU-scoped admins can manage them, and tenant-wide admins are explicitly blocked.

flowchart TD
    tenant_admin["Global Admin"]
    user_admin["User Admin (Tenant)"]
    au_admin["AU Admin (Restricted AU)"]
    sensitive_accounts["Sensitive Accounts"]
    standard_accounts["Other Accounts"]
    restricted_au["Restricted AU"]
    tenant_admin --> standard_accounts
    tenant_admin -.-> sensitive_accounts
    user_admin --> standard_accounts
    user_admin -.-> sensitive_accounts
    au_admin --> restricted_au
    restricted_au --> sensitive_accounts

Figure: Access to sensitive accounts in a restricted management AU

Global Administrators keep only a few rights over protected accounts

People often get confused about what Global Administrators can still do once a restricted management AU is in place. They can still assign AU-level admins, and they can delete the AU itself. What they can't do is reset passwords, change properties or modify group memberships for users in the restricted AU, unless they have been explicitly assigned a role scoped to that AU. That's a big step forward for separation of duties and for preventing abuse. Break glass and executive accounts badly needed this kind of protection. The permission boundaries are described in Microsoft's documentation.

Creating the AU and assigning roles has a few tricky parts

The process itself is simple. Create the AU in the admin center with restricted management enabled, add the sensitive users, then assign roles such as User Administrator or Password Administrator scoped to the AU, either in the portal or with PowerShell. (Keep in mind that the admin needs an Entra ID P1 licence to receive an AU-scoped role.) The role assignment steps are covered in this guide. In many of my projects I add Privileged Identity Management (PIM) on top, so AU roles are eligible or time-bound. Admins then activate access only when they need it, with approval where required.

Practical tip: Administrative units do not enforce restrictions for groups. You can't protect group memberships or properties with restricted management AUs. Groups need their own governance, for example Access Reviews for privileged groups.

Helpdesk workflows and break glass accounts need extra attention

Here's a snag I've run into. Helpdesk and first-level support teams are usually used to resetting any password and unlocking any account. Once you introduce a restricted management AU, those processes will suddenly fail for protected accounts, and that's by design. Update the helpdesk SOPs and spell out how to escalate incidents (a locked-out executive, for example) when the regular helpdesk can't step in. For emergency access (break glass) accounts, I consider restricted AUs mandatory. Regular admins and the helpdesk should never be able to modify these accounts, and I always recommend additional monitoring for failed modification attempts.

The setup pays off in real environments

I've rolled out restricted management administrative units in several environments, and in my experience they're the most effective built-in Microsoft mechanism for protecting critical Entra ID accounts. You can set them up quickly, assigning a small group of trusted admins is easy, and the security boundary you get is substantial. You do have to sort out P1 licensing and update your incident response playbooks. In return, the tenant becomes much more resilient. If you want to automate onboarding and offboarding for sensitive users as well, my post on lifecycle workflows is a practical next step.