Least privilege for non-IT staff doing M365 admin

If you've given HR Global Admin to do password resets, you've made a security decision that looked like a convenience one.

It's one of the most common bad patterns in M365-heavy MSP environments. The shape: routine M365 work (resets, license changes, new-hire setup, group adds) needs admin access. The people who should be doing that work (HR, office managers, frontline supervisors) don't have admin access. So IT either does the work itself (creating the L1 bottleneck this whole site is about) or hands out Global Admin "temporarily."

The temporarily becomes permanent. Six months later you've got six non-IT staff with Global Admin and no audit trail of who did what.

There's a better answer. It requires more thinking up front and significantly less worrying later.

What the wrong approaches actually cost

"Give them Global Admin just for now." The cost shows up the day someone in that group gets phished. Global Admin lets the attacker do anything in your tenant: pivot to other clients (if you're an MSP), exfiltrate everything, set up persistence, delete logs. The least-privilege failure mode is the worst-case failure mode.

"Funnel everything through IT." The cost shows up in your ticket queue: 30+ password reset tickets a month per client, half of which sit waiting for a tech for 45 minutes because the user is logged out and can't do anything else. Your L1 spends a third of their day on work the requester could have done in 30 seconds with the right scoped access.

"Build a custom admin portal." The cost shows up in maintenance: now you're shipping software. You own the auth, the audit logging, the M365 API integration, the access reviews, the security model. For an MSP that's not a software company, this is a forever tax.

What scoped delegation actually requires

The right answer has three parts.

1. Scoped admin roles

M365 has built-in admin roles narrower than Global Admin. The ones that matter for delegation:

• User Administrator. Can create/modify users, reset passwords for non-admins, manage groups. Cannot read security logs, cannot modify policies, cannot grant other admin roles.
• License Administrator. Can assign/revoke licenses. Nothing else.
• Exchange Recipient Administrator. Can manage mailboxes, DLs, mail-enabled groups. Cannot modify Exchange policies.
• Helpdesk Administrator. Can reset passwords for non-admin users and force password changes. Nothing else.

Most "let HR do password resets" use cases need Helpdesk Administrator and nothing more.

Most "let the office manager do new-hire onboarding" use cases need User Administrator + License Administrator scoped to a specific OU.

2. Administrative Units (or equivalent scoping)

The roles above can be scoped to Administrative Units. For example, this person is User Administrator for the Sales department only. They can reset passwords for sales staff but not engineering staff. Same admin role, different scope.

For most MSP clients, the right model is: scope each delegated admin to the OU/AU that matches their actual responsibility. HR for the whole company, line managers for their team, office coordinators for the office staff.

3. Just-in-time elevation (for the rarer asks)

For occasional work that needs more privilege than the scoped role provides (e.g., a manager needs to add an app for their team), Privileged Identity Management lets them request the role for 1 hour, with approval, with full audit. The privilege is temporary and logged. The default state is least-privilege.

PIM requires Entra ID P2 licensing. For larger clients it's worth it. For smaller ones, the right answer is usually "those rare asks come to IT."

Where purpose-built delegation tools fit

The native M365 roles cover most of the work. But the UI for non-IT staff doing this work is still the Microsoft admin center, which assumes the user knows M365 concepts. HR shouldn't need to understand "convert user to shared mailbox." They should click "this person left, do the offboarding thing."

That's the layer where purpose-built delegation tools (like UserDesk, which we ship) sit: a non-admin-center UI on top of scoped delegation. It doesn't replace the security model. It makes the security model usable by the people who should be doing the work.

The audit win

The biggest under-appreciated benefit of scoped delegation: you get an audit trail of who did what.

When five people share a Global Admin login, "Sarah from HR did the password reset" isn't recordable. When Sarah has Helpdesk Administrator scoped to the Sales OU, every action she takes is logged against her identity, with her scope, with the timestamp.

That audit trail is what lets you defend "yes, this access was used appropriately" against the auditor who shows up after an incident. The shared-admin pattern can't produce that record. The scoped-delegation pattern produces it by default.

The one-week project

If you're sitting on a tenant where non-IT staff have Global Admin "temporarily," the one-week project to fix it:

1. Audit who has what role. Microsoft Entra has built-in reports for this.
2. For each non-IT admin, figure out the smallest scope that lets them do their actual job.
3. Assign the scoped role, revoke Global Admin.
4. Document who has what, and put it in your annual review cycle.

The downstream effects: better audit posture, smaller blast radius on any future credential incident, fewer accidental config changes by people who didn't know what they were touching.

---

What's the oldest "temporary admin" grant you've found that was still active?