Microsoft says do not use Global Administrator to manage Intune. Almost every tenant we look at does.
The product ships nine built-in roles plus custom ones, groups that constrain which hardware an administrator may touch, and tags that constrain which objects they can even see. Combine all three and you have least privilege expressed properly, which is the thing a SOC 2 auditor or an insurance carrier is really probing for. Combine none of them and every administrator in your tenant can do anything to anybody.
- Nine built-in rolesPlus custom roles and Cloud PC roles
- Three partsMembers, scope groups and scope tags
- IncrementalMultiple assignments add permissions together
- 10s or 15 minPIM elevation timing, depending on method
Seven things that decide whether your Intune permissions mean anything.
Global Administrator is explicitly not the answer
The guidance could hardly be more direct: do not use that role here, and it is not recommended for administering or managing the product at all. A handful of features genuinely require it, mobile threat defense connectors being the documented example, and even there the instruction is to take it for the specific task and hand it back the moment you are finished.
Intune Administrator is also too much for daily work
This one carries global read and write across the whole product and is classified as privileged. Yes, it is narrower than the tenant-wide alternative, and it still hands over considerably more than any ordinary task requires, which is why the guidance says not to use it for routine administration either. Be aware it surfaces under a different name in Graph and PowerShell, which confuses people auditing their own tenants.
Nine built-in roles, each for a real job
The list covers application management, privilege management in both a managing and a reading flavor, endpoint security, help desk work, role administration itself, policy and profile work, pure read-only access, and school administration. Add a Windows 365 subscription and two Cloud PC roles join them. Here is the pattern we see: most organizations need three or four of these, and are using precisely none.
Scope groups limit which devices an administrator touches
These define exactly which users and machines somebody holding a role assignment is able to manage. There is a specific instruction attached: to stop an administrator being able to target everybody, do not use the options that add all users or all devices. That one checkbox, left alone or ticked in a hurry, is the entire difference between a scoped service desk and an unscoped one.
Scope tags limit which objects an administrator can see
They are simply freeform text values you define and attach to a role assignment, and they do two separate things worth keeping straight. Placed on the role, a tag governs who can see that role. Placed in an assignment, it restricts which objects, meaning policies, applications and devices, are visible to administrators whose assignments carry a matching tag.
Three monitoring views, and nobody uses them
One shows the effective permissions of whoever is signed in. Another works backwards from a specific permission to the assignments and groups granting it. The third takes any named account and produces the complete list of what it currently holds. That third view answers the exact question an auditor will put to you, and it does so in about thirty seconds, which is why it is remarkable how few people have ever opened it.
Just-in-time elevation, with two different timings
You have two options and they behave very differently. Managing the directory role directly gets somebody elevated typically inside 10 seconds. Going through the groups-based approach with an Intune role assignment can take up to 15 minutes to take effect. On an ordinary Tuesday that gap is academic. At two in the morning with an incident running, it is the difference between a control people use and one they route around.
Two role assignments with different scope tags can grant more than either was meant to.
This is documented behavior rather than a bug report, and it is comfortably the most counterintuitive thing about how permissions work here.
- Where two or more roles grant permissions over the same object, those permissions add together. Hold read through one assignment and read plus write through another, and what you effectively have is read and write.
- Now apply that to an administrator carrying several assignments with different scope tags on them, and the result can be meaningfully broader access than anybody intended. Nothing is malfunctioning. That is how the model composes, and crucially it is invisible from either assignment examined on its own.
- There is an opt-in preview setting that changes this, containing each assignment permissions within its own scope tag context, and published steps for assessing the impact on your tenant before you switch it on. Worth evaluating rather than enabling on a whim.
- What follows practically is that examining role assignments one at a time tells you almost nothing useful. The view showing the complete effective permission list for a named account is the only dependable way to answer what any individual can genuinely do.
Four things that make an Intune permissions model hold.
We start from effective permissions, not from role names
Point the admin permissions view at a named account and it returns everything that account currently holds. That matters because permissions accumulate across assignments, and because differing scope tags between assignments can widen access beyond anybody intention. Reading role names therefore tells you what a person was supposed to end up with, which is a different question from what they have.
We scope by group and by tag, not by one or the other
The two mechanisms answer genuinely different questions. Groups settle which people and machines somebody may manage; tags settle which policies, applications and devices they can even see. Organizations that attempt scoping at all almost invariably use only the first. And the accompanying instruction is quite specific about avoiding the options that select everybody.
We get the broad Entra roles out of daily use
One is documented as not for use here at all, the other as not for routine work. Where a specific feature genuinely demands elevated rights, certain threat defense connectors being the standard example, the approach is to take the role for that task and give it back immediately afterward. Just-in-time elevation is what turns that from a policy nobody follows into something practical.
We check the exclude group behavior, which trips people up
An exclude group referenced in a policy or application assignment has to be either nested inside one of the assignment scope groups or listed as a scope group in its own right. Miss that and your exclusions simply do not apply, with nothing logged and no error raised. Working backwards to this from the symptom is genuinely difficult, which is why we check it up front.
Six situations where Intune scoping stops being optional.
A group with several business units under one tenant
Combine the two scoping mechanisms and each division administrator manages and sees only what belongs to their division. Leave them out and somebody in one subsidiary can read and change configuration owned by another. That arrangement survives right up until the first person notices, at which point it stops being a technical detail and becomes a governance conversation.
An organization using an outsourced helpdesk
That role carries out remote actions against users and devices and can push applications or policies. Point it at the right groups and it is precisely the capability a service desk requires, no more. Leave it unscoped and you have handed an external supplier the ability to act remotely on every machine your company owns, which is a very different contract than the one you thought you signed.
A firm asked who can wipe a device
It arrives in slightly different words from SOC 2 auditors, from bank examiners working under GLBA, and from insurance underwriters, but it is the same question. Two views answer it from opposite directions: one takes a named account and lists everything it holds, the other takes a permission and shows which assignments and groups confer it. Exporting those beats reconstructing the answer from role names and nested group memberships while somebody waits.
An operator with site-based device populations
Machines at a plant, a distribution center or an isolated facility usually need somebody local who can actually fix things, and that person has no business being able to act on head office equipment. A scope group per site paired with a scoped help desk assignment delivers genuine local capability while keeping the reach where it belongs.
A school district using Intune for Education
That role handles applications, settings and devices for its groups within the education console, and can lock, restart or retire hardware remotely. Scope it per school or per campus and you have delegated capability that genuinely helps the people on site, while ensuring an honest mistake stays confined to one building rather than reaching the whole district.
An organization tightening privileged access generally
Approval by a second administrator can now be required before role permissions, admin groups or member assignments change. Put that alongside time-limited elevation and you have privileged access that is both bounded in duration and controlled at the point of change, which is exactly the shape both NIST and CIS guidance keep pointing organizations toward.
How organizations grant Intune administrative access.
| Feature | Scoped roles and tags | Everyone is an Intune Administrator | Global Administrator for everything |
|---|---|---|---|
Least privilege applied | Yes | No | No |
Helpdesk limited to their own devices | Yes | No | No |
Object visibility limited by scope tag | Yes | No | No |
Effective permissions answerable | Yes | Trivially, everyone has all | Trivially, everyone has all |
Role changes require approval | Yes | No | No |
Elevation is time bound | Yes | No | No |
Follows Microsoft published guidance | Yes | No | Explicitly not |
Survives an audit question | Yes | No | No |
Blast radius of a compromised admin account | Bounded | Whole estate | Whole tenant |
Effort to set up | Days | None | None |
Eleven roles, and the job each one is for.
Role
Application Manager
- What Microsoft says it does
- Manages mobile and managed applications, can read device information and view device configuration profiles
Role
Endpoint Privilege Manager
- What Microsoft says it does
- Manages Endpoint Privilege Management policies in the Intune console
Role
Endpoint Privilege Reader
- What Microsoft says it does
- Views Endpoint Privilege Management policies in the Intune console
Role
Endpoint Security Manager
- What Microsoft says it does
- Manages security and compliance features such as security baselines, device compliance, Conditional Access and Defender for Endpoint
Role
Help Desk Operator
- What Microsoft says it does
- Performs remote tasks on users and devices, and can assign applications or policies to users or devices
Role
Intune Role Administrator
- What Microsoft says it does
- Manages custom roles and adds assignments for built-in roles. The only Intune role that can assign permissions to administrators
Role
Policy and Profile Manager
- What Microsoft says it does
- Manages compliance policy, configuration profiles, Apple enrollment, corporate device identifiers and security baselines
Role
Read Only Operator
- What Microsoft says it does
- Views user, device, enrollment, configuration and application information, and cannot make changes
Role
School Administrator
- What Microsoft says it does
- Manages apps, settings and devices for their groups in Intune for Education, including remote lock, restart and retire
Role
Cloud PC Administrator
- What Microsoft says it does
- Read and write access to all Cloud PC features in the Cloud PC area
Role
Cloud PC Reader
- What Microsoft says it does
- Read access to all Cloud PC features in the Cloud PC area
Role
Custom roles
- What Microsoft says it does
- Any combination of Intune permissions, for refined access supporting least privilege
Five steps, and the first one usually surprises somebody.
- 1
Establish effective permissions as they are today
We work account by account through the effective permissions view rather than reading role names off a list, since permissions accumulate across assignments and differing scope tags can widen things further still. In parallel we enumerate which directory roles currently reach into the product, because several do and they do not all grant the same thing.
- 2
Map administrative jobs to the least privileged role
We sort your people by what they genuinely do: application management, endpoint security, policy and profile work, or simply reading. Wherever the closest built-in role hands over more than the job actually needs, a custom role gets built instead, which is explicitly supported for precisely this purpose.
- 3
Design scope groups and scope tags together
Groups get defined to bound what each assignment may manage, deliberately without reaching for the options that select everybody. Tags get defined to bound what each assignment may see. Then a specific check that every exclude group used anywhere in a policy or application assignment is either nested inside a scope group or listed as one, because that is where exclusions silently die.
- 4
Move the broad roles into just-in-time elevation
The two broad roles come out of permanent assignment entirely. Elevation gets configured, and the choice between the directory-role path that takes seconds and the groups-based path that can take a quarter of an hour is made on the basis of how the access is genuinely used, not on which one reads better in a design document.
- 5
Turn on the governance and hand over the views
Second-administrator approval gets switched on for permission, admin group and member assignment changes. After that the three monitoring views are handed over to whoever will be fielding permission questions in future, and role assignments join the same periodic review as the rest of your access governance, because otherwise they will drift exactly the way everything else does.
What organizations ask about Intune role-based access control.
Fifteen checks that reveal what your administrators can actually do.
Who holds what
- Who has Global Administrator?Microsoft says do not use it for Intune.
- Who has Intune Administrator?Also too broad for daily tasks.
- Which Entra roles reach Intune?Several do, with varying permissions.
- Have you run the Admin permissions view?It shows effective permissions per account.
- Does anybody hold multiple assignments?Permissions are incremental.
Scoping
- Do any assignments use add all users?Microsoft advises against it.
- Do any use add all devices?Same advice, same reason.
- Are scope tags in use at all?Most tenants have none.
- Do exclude groups sit inside scope groups?They must be nested or listed.
- Are role assignment scopes documented?Otherwise nobody can explain them later.
Governance
- Is Multi Admin Approval on for role changes?It now supports role-based access control.
- Is PIM used for elevation?Two methods, with different timings.
- Do administrators need licenses?Depends when the account was created.
- Are role assignments reviewed?They accumulate like every other permission.
- Who can create role assignments?Only the Intune Role Administrator role.
Run the Admin permissions view on one helpdesk account. That is the whole assessment.
It shows the complete list of permissions that account actually holds, which is frequently broader than the person who granted it intended. Two minutes, one account, and it usually starts the conversation on its own.
Related Services
Explore more solutions that work great with this service