Why the User Administrator Role Is the Wrong Answer for HR Delegation

If you've ever asked "how do I let HR create and manage M365 users without giving them Global Admin?" the canonical Microsoft answer is the User Administrator role. It's the closest built-in option to what you want. It almost works.

It also almost-fails for three specific reasons that show up the moment you actually try to deploy it. Here's the gap, why it matters, and what the working pattern looks like instead.

What User Administrator actually grants

From Microsoft's documentation:

Users with this role can create and manage all aspects of users and groups. This role also includes the ability to manage support tickets and monitor service health. This role does not include the ability to manage shared mailboxes or other Exchange Online recipient types.

In practice this means a User Administrator can:

• Create and delete user accounts
• Reset passwords for non-admins and for other admins below their tier (excluding Global Admins)
• Assign and remove any license the tenant has available
• Create, modify, and delete groups (Microsoft 365 Groups, security groups, distribution lists)
• Modify any user's department, job title, manager, mobile phone, office location
• Read all directory data
• Manage Entra ID-joined devices (in some configurations)

This is a lot of power. We covered the role taxonomy in detail in Microsoft 365 Admin Roles Explained: Global vs User vs Helpdesk — User Administrator sits one tier below Global Admin, which means anything that isn't explicitly Global-Admin-only is fair game.

Gap 1: Blast radius is too wide

The most concrete failure: User Administrator can reset passwords for all users in the tenant, including IT staff who aren't Global Admins.

If your HR coordinator gets phished, the attacker can:

• Reset the password of every non-Global-Admin in your IT department
• Lock out the senior engineer who would otherwise notice the intrusion
• Create new admin accounts as persistence
• Modify or delete the membership of any security group, including ones your conditional access policies rely on

For a role we want to grant to a non-IT person doing one specific job — onboarding new hires in the Sales department, say — that's a six-figure blast radius for a tactical convenience.

You can theoretically constrain User Administrator with Administrative Units (AUs), scoping the role to a specific department or location. In practice, AU configuration is brittle, the admin center UX is confusing, and the role-holder still sees the full M365 admin center UI when they sign in — which leads to the next gap.

Gap 2: The interface is the M365 admin center

Granting User Administrator gives the role-holder access to the same Microsoft 365 admin center that Global Admins use. The dashboard, the user list, the groups page, the licenses page, the service health view, the support tickets view. All of it.

For an HR coordinator whose entire job in the system is "create a user from a Sales template," dropping them into the admin center has predictable outcomes:

1. They get overwhelmed and file an IT ticket anyway. The bottleneck you were trying to fix returns, and now you've also given the HR coordinator a role you'll have to remember to revoke later.
2. They click something they shouldn't. Maybe they "fix" a user record that wasn't broken. Maybe they accidentally remove someone from a group. Maybe they spend ten minutes trying to figure out what "Conditional access" means and panic when it asks them to confirm a policy change.

Neither outcome is what you wanted. The admin center is a power tool designed for IT pros — putting a non-IT person in front of it is the UX equivalent of handing them a chainsaw to open a package.

Gap 3: Audit logs live in Azure Monitor

When the role-holder takes an action, it gets logged. Good. But the log lives in the Entra ID audit log, which surfaces via Azure Monitor and queries via KQL. The compliance review workflow looks like this:

• Auditor asks: "Who created the account for our former contractor in March?"
• You open the Entra ID admin center, navigate to Audit logs, set the date range, filter by activity type "Add user," filter further by the user's display name or UPN — assuming you know how to spell it correctly.
• You export the results to CSV.
• You email the CSV to the auditor.

This isn't difficult for an IT pro. It's also not a workflow your HR director or compliance team will run themselves — which means you end up running it every time someone asks. The point of delegation was to reduce the routine work landing on your plate, not to relocate it.

What "actually working" looks like

The pattern that addresses all three gaps is a delegation layer that wraps the Microsoft Graph API, not the admin center. Specifically:

• OAuth-based, so the role-holder authenticates with their own Microsoft account and the system acts on their behalf with their token. No standing access for the delegation tool itself.
• Operation-scoped, so the delegate can call user-creation operations (with parameter constraints from your templates) but cannot call anything else, regardless of what their Entra ID role would technically allow.
• Department- or scope-aware, with role assignment in the portal that's distinct from Entra ID role assignment. Your HR coordinator gets the "Member" role in the delegation portal; they don't need to be a User Administrator in Entra ID at all.
• Audit log in a non-technical interface, so compliance reviews don't require KQL fluency.

UserDesk for M365 implements this pattern. The delegate signs in with their normal Microsoft account. The portal exposes only the user-management operations you've configured — typically: create from template, reset password, assign/remove license, manage group membership. The audit log is a clean table view that anyone in HR or compliance can scan and filter. No PowerShell, no KQL, no admin center.

Importantly, the delegate doesn't need to be a User Administrator in Entra ID. They need standard user permissions plus the appropriate role in the portal. The portal calls Graph with their token (using delegated permissions like User.ReadWrite.All granted at the app level via admin consent), constrained by the operations the role allows.

The decision tree

If you're evaluating whether to use User Administrator vs a delegation layer:

Situation	Use User Administrator	Use a delegation layer
Dedicated IT staff who handle all user ops	✓	—
HR coordinator handling onboarding	—	✓
Office manager handling password resets	—	✓
Team lead managing their own team's group memberships	—	✓
Need to scope by department	—	✓
Need audit logs your compliance team can review without KQL	—	✓
Need to constrain which licenses can be assigned	—	✓
MSP managing client tenants where client staff need self-service	—	✓

User Administrator works for "this person is part of my IT team but I don't want them to be Global Admin." It doesn't work for "this person is in HR and just needs to onboard new hires."

For the workflow side of this — what HR's actual day-to-day looks like once delegation is in place — we covered it in How to Onboard a Microsoft 365 User in Under 2 Minutes.

See the delegation pattern in action: the interactive demo lets you switch between portal roles (Admin / Member / Viewer) and watch the available operations change. No signup, sample data, 2 minutes.