Understanding Intune Roles and Permissions

The most common Intune permission model I still see in smaller environments is “everyone who touches Intune gets Global Administrator.” It works, until it doesn’t - a helpdesk technician deletes the wrong Autopilot device, or an intern with too much access pushes a compliance policy tenant-wide. Intune’s role-based access control (RBAC) exists to prevent exactly that, and it’s worth setting up properly from day one rather than retrofitting it once something has already gone wrong.

Built-in roles

In the Intune admin center under Tenant administration > Roles, you’ll find a set of built-in roles that cover most day-to-day scenarios:

• Intune Administrator - full control over the Intune service, but not over other Microsoft 365 workloads. This is what most of your Intune admins should get, not Global Administrator.
• Helpdesk Operator - can view device and user details, retire or wipe a device, and restart it, but can’t touch policies, profiles or app assignments. This is the role I hand out most often to first-line support.
• Policy and Profile Manager - can create and assign configuration profiles and compliance policies, without the ability to manage apps or enrollment.
• Application Manager - manages app assignments and app protection policies, nothing else.
• School Administrator - a narrower role built for education tenants (Intune for Education scenarios).
• Read Only Operator - exactly what it says: view everything, change nothing. Useful for auditors or for a manager who wants visibility without write access.

Each built-in role comes with a fixed, predefined set of permissions - you can assign it, but you can’t edit what it’s allowed to do.

Custom roles

If none of the built-in roles fit, you can create a custom role from scratch or by duplicating a built-in role and adjusting it. Permissions in a custom role are grouped by object type - Managed Devices, Mobile Apps, Compliance Policies, Configuration Profiles, Enrollment, and so on - each with granular actions like Read, Create, Update, Delete, or Assign.

A pattern I use a lot: duplicate Helpdesk Operator, then add just the one extra permission a specific team actually needs (for example, “Managed Apps > Assign” for a regional IT team that handles their own app rollouts) instead of jumping them straight to Intune Administrator. Smaller, additive custom roles are much easier to reason about later than a handful of broad ones.

Scope tags: the other half of RBAC

A role assignment on its own only answers “what can this person do.” Scope tags answer the second question: “on which devices, users, or objects.” Without a scope tag, a role assignment applies tenant-wide - a Helpdesk Operator role with no scope tag can retire any device in the tenant, not just the ones for their site or department.

I use scope tags constantly to delegate access to specific offices, departments or device groups without duplicating roles per site. I’ve written in more detail about tagging devices via Autopilot and carrying that scope tag through into Intune and Defender for Endpoint device groups here: Defender for Endpoint Scope Tag with Autopilot and Intune - the same scope tag mechanism applies to configuration profiles, compliance policies and apps, not just Defender onboarding.

A practical example

Say you have three regional offices, each with its own on-site IT contact who should only manage devices for their own location:

1. Create a scope tag per region (Region-CH, Region-DE, Region-US).
2. Assign the scope tag to the relevant Autopilot devices, groups, and policies for each region.
3. Duplicate the Helpdesk Operator role once per region, and assign each duplicate to the matching regional contact, scoped to their region’s tag.

Each regional contact now sees and manages only their own devices in the Intune console - not because you built three separate custom roles with different permissions, but because the same permission set is scoped differently per assignment.

Least-privilege recommendations

A few things I check whenever I take over or audit a tenant:

• Global Administrator should not be anyone’s day-to-day Intune role. Use Intune Administrator (or a narrower custom role) instead, and reserve Global Administrator for genuine emergency-access scenarios.
• Review role assignments periodically, the same way you’d clean up stale devices - people change teams or leave, and their old role assignments rarely get revoked automatically.
• Prefer several narrow scope tags over one broad one. It’s much easier to loosen access later than to figure out, after an incident, exactly who could touch what.
• Use Read Only Operator for anyone who only needs visibility - managers, auditors, or a security team that monitors compliance without needing to change policies.

Conclusion

Intune RBAC is really two independent decisions - which permissions (role) and which objects (scope tag) - and most of the value comes from combining a narrow role with a narrow scope rather than reaching for a broader built-in role out of convenience. Setting this up properly early costs very little extra effort and saves you from having to untangle overly broad access later, usually right when you can least afford the distraction.