Almost nobody configures the authority model inside Intune. Roles get assigned once during the build, scope tags get created and never used, multi-admin approval stays off because it looks like friction, and the result is a tenant where every administrator can see and change everything and no change requires a second opinion. This is the privileged-access story of this product, and it is separate from the identity one.
Two mechanisms, and the sentence that separates them
Microsoft’s own framing is the clearest I have seen and worth quoting because it stops an entire category of confusion: scope tags control which objects admins can see, and roles control what actions they can take on those objects. Two mechanisms, two questions, and they compose rather than overlap.
Scope tags themselves are freeform text values you define and then attach in two different places, which is where people go wrong. A scope tag added to a role controls the visibility of the role itself. A scope tag added in a role assignment limits the visibility of Intune objects. Those are different jobs done by the same object type and the distinction is not signposted in the interface.
The composition rules matter more than the definitions, because this is the part that produces surprises. Permissions are incremental where two or more roles grant permissions to the same object. Assign permissions and scope tags apply only to the objects in that role assignment’s scope groups, while other permissions, meaning create, read, update and delete, apply to all objects of the same type across any of the user’s assignments. Permissions for objects of different types do not apply to each other. And where an administrator has no scope tags, or has scope tags from different assignments, they see the devices that are part of some scope tags rather than all devices.
Read those together and a property falls out that Microsoft has now admitted in writing. When an administrator holds multiple role assignments using different scope tags, the behaviour can result in broader access than intended. That is a first-party statement that the shipped model over-grants, and there is an opt-in preview setting that contains each role assignment’s permissions to its own scope tag context.
The product’s own documentation says the scoping model can grant more than you intended. That is not a bug report from the field. It is the vendor telling you.
Here is why that matters more than a preview flag normally would. Microsoft has said that when scoped permissions reach general availability, the scoped behaviour becomes the default for all tenants, and there is a permissions assessment report under the roles settings to preview the impact before it lands. So this is not a feature you may adopt. It is a change to how your existing role assignments resolve, arriving on someone else’s schedule, with a report that tells you the blast radius in advance. Run the report now. An administrator who quietly relied on the broader behaviour is going to lose access to something on a date you did not choose, and the difference between finding that out from the report and finding out from a service desk ticket is a week of goodwill.
Two practical notes on scope tags. Creating them requires the Intune Administrator role, which Microsoft itself flags as privileged. And automatic scope tag assignments overwrite manually assigned ones, while a device that picks up multiple scope tags through group assignment carries all of them.
The nine roles, and the two permissions that live in none of them
Intune ships nine built-in roles, plus Cloud PC roles when Windows 365 is subscribed. Naming them precisely is worth doing once, because half the delegation conversations I have are people describing a role that does not exist.
| Role | Scope |
|---|---|
| Application Manager | Manages mobile and managed applications; reads device information and views configuration profiles |
| Endpoint Privilege Manager | Manages Endpoint Privilege Management policies |
| Endpoint Privilege Reader | Views Endpoint Privilege Management policies |
| Endpoint Security Manager | Manages security and compliance features: security baselines, device compliance, Conditional Access, Defender |
| Help Desk Operator | Performs remote tasks on users and devices; assigns applications and policies |
| Intune Role Administrator | Manages custom roles and assignments; the only Intune role that can assign permissions to administrators |
| Policy and Profile Manager | Manages compliance policy, configuration profiles, Apple and Android Enterprise enrollment profiles, and corporate device identifiers |
| Read Only Operator | Views user, device, enrollment, configuration and application information; cannot make changes |
| School Administrator | Manages apps and settings for their groups, with remote actions |
Now the cross-cutting facts that a role list does not reveal, and which are the actual privileged-access findings.
Read Only Operator can retrieve FileVault recovery keys. The Get FileVault key permission sits in Endpoint Security Manager, Help Desk Operator, and Read Only Operator, which means the role whose entire premise is that it cannot make changes can nonetheless read the credential that decrypts a Mac. That is not a defect, since reading a key is not a change, but it is a delegation decision most people make without knowing they are making it.
Rotating a local administrator password is in no built-in role at all. Not on Windows, where the Rotate Local Admin Password remote task is absent from every built-in Intune role and from the Entra Intune Administrator role. Not on macOS, where the two enrollment-programs permissions for viewing and rotating the Mac admin password are likewise absent from every built-in role. Both require a custom Intune role. Microsoft made the same design decision twice on two platforms, so it is deliberate, and the effect is that the most sensitive credential operation in the product is invisible to anyone auditing built-in role membership.
Reading a Windows LAPS password is not an Intune permission at all. It is an Entra directory permission, and viewing metadata and viewing the password itself are separate permissions. So the answer to who can read local administrator passwords in your tenant is not in the Intune console, and a delegation review that only looks at Intune roles will conclude nobody can.
Rotating a BitLocker key is a preview-labelled permission held by Endpoint Security Manager and Help Desk Operator. And the Endpoint Security Manager role, which is the natural home for most of this, does not cover everything under the endpoint security node: viewing Endpoint Privilege Management reports needs a separate view-reports permission on top.
The least-privileged role for administering the model itself is Intune Role Administrator, which Microsoft labels as such. If one person in the organisation should be able to hand out permissions, that is the role, and it should not be the same person who holds Global Administrator.
Multi-admin approval, and what it does not cover
Multi-admin approval requires a second administrator to approve a change before it applies. There are seven selectable protected resource types, and stating their limits is more useful than stating their names, because the limits are where the false confidence lives.
| Resource type | What it actually covers |
|---|---|
| Apps | App deployments. Not app protection policies. |
| Compliance policies | Compliance policies. |
| Configuration policies | Settings catalog policies only. |
| Device actions | Wipe, retire and delete. |
| Role-based access control | Role changes: permissions, admin groups, member group assignments. |
| Scripts | Scripts deployed to Windows devices only. |
| Tenant Configuration | Device categories: create, edit, delete. |
Access policies themselves are automatically protected and are not selectable, which is a sensible piece of design. But read the limits column again: configuration coverage is settings catalog only, apps coverage excludes app protection policies, scripts coverage is Windows only. Multi-admin approval is not blanket protection, and an article that implies it is has done its reader a disservice.
The prerequisites contain two silent failure modes, both worth asserting rather than assuming. The approver group must be a security group; distribution lists, Microsoft 365 groups and mail-enabled security groups are not supported and silently fail to resolve approver membership. And the group must be directly assigned to an Intune role as a member group, because permissions held by individual members through other groups or direct user assignments do not satisfy the requirement. If the approver group is not added to a role assignment, its members are periodically removed from the group. So the failure mode is a configuration that looks correct and quietly does nothing, which is the worst kind.
Operationally: nobody can approve their own request, including a Global Administrator or Intune Administrator, whose changes still need a different person. Intune sends no notifications when requests are created or when their status changes, so the workflow depends on somebody looking. A request not processed within three days expires and must be resubmitted, and statuses remain visible for thirty days. And approval alone does not apply the change; the requestor has to return and select complete.
The deadlock is the best operational warning in this whole article and Microsoft documents it against itself. Enable an access policy for the role policy type, and any attempt to modify roles, including the role assignments that multi-admin approval itself requires, needs approval first. That creates a state where you cannot configure the assignments needed for the feature to function. The escape is to delete the role access policy, wait a few minutes for propagation, complete the assignments, and re-create it. Microsoft’s own ordering advice is the right one: configure every other access policy and verify the role assignments before you enable the one covering roles.
One setting here is irreversible and deserves its own sentence. Allowing unlicensed administrators to participate in the workflow cannot be turned off once it is turned on. Decide that deliberately.
An AI surface has also appeared inside the approval control, which is worth noting rather than adopting: where the Change Review Agent is set up and has run, the requests views show an agent response column for Windows PowerShell script requests, with a suggestion you can open to complete the approval workflow. An agent recommending approvals inside the mechanism whose purpose is requiring a second human is a design worth thinking about before enabling.
The bypasses, which is where this connects back to the front door
Two of them, and both are documented rather than clever.
The device enrollment manager account can enrol devices that a platform restriction would otherwise block, is not subject to device limit restrictions, and can carry up to a thousand devices. Everything the enrollment build sheet configures is bypassed by holding one of these. So the DEM account list is a privileged-access artifact and belongs in the same review as the role assignments, not in a corner of the enrollment documentation. There is a genuine constraint on them worth knowing: a DEM account cannot complete enrollment when a Conditional Access policy is enforced for that user’s sign-in.
And the asymmetry from the build sheet repeats here. Managing enrollment restrictions requires the Intune Administrator role and every other built-in role is read-only on them, including custom roles that once held those permissions. But corporate identifiers sit at a lower bar, available to Policy and Profile Manager and to custom roles. A delegated administrator can therefore upload the identifier list that changes the tenant’s default device ownership without being able to view, let alone change, the restriction that consumes it. That is a real separation-of-duties question and I have never seen it appear on anyone’s delegation review.
The privileged-access tier, collected
| Tier | Setting or decision | Position |
|---|---|---|
| R | Scope tags in use | Defined and applied, or explicitly decided against; not created and abandoned |
| C | Permissions assessment report | Run before scoped permissions reach GA and change how existing assignments resolve |
| R | Scoped permissions preview | Adopted deliberately rather than inherited at GA |
| C | Intune Administrator membership | Enumerated; it is the only role that can manage enrollment restrictions and create scope tags |
| R | Intune Role Administrator | Assigned to a named person, separate from Global Administrator |
| C | LAPS rotation permission | A custom Intune role exists; no built-in role carries it on Windows or macOS |
| R | LAPS password read permission | Reviewed in Entra, not in Intune; the Intune console will not show it |
| R | FileVault key read permission | Reviewed knowing Read Only Operator carries it |
| R | Multi-admin approval | Enabled on device actions and RBAC at minimum, with its coverage limits documented for the reader |
| C | MAA approver group shape | A security group, directly assigned to an Intune role as a member group; anything else fails silently |
| R | MAA enablement order | Every other policy first, the role policy type last, to avoid the documented deadlock |
| O | Unlicensed admin access for MAA | Decided deliberately; it cannot be turned off once enabled |
| C | Device enrollment manager accounts | Enumerated and owned; each one bypasses both enrollment restriction types |
| R | Corporate identifier delegation | Reviewed against who can manage the restriction that consumes it |
| O | Change Review Agent in MAA | Understood before enabling; it places an agent suggestion inside a human-approval control |
How to know it held. For roles, read the resolved assignment list for a named administrator rather than the role membership, because incremental permissions across multiple assignments are the thing that surprises you. For multi-admin approval, submit a real change as a requestor who is also in the approver group and confirm you cannot approve it yourself; a test that a lesser configuration would pass is not a test. For DEM accounts, enumerate them and confirm each one is a person somebody can name.
This article and the identity pillar’s privileged access work are siblings rather than duplicates. That one governs who is an administrator and under what conditions their privilege activates. This one governs what an Intune administrator can see and change once they are one. A tenant can do the first perfectly and still hand every one of those carefully elevated administrators a console where everything is visible and nothing needs a second signature.
Best Practices
‹ Previous: [BP 4.2] The Intune Baseline: Recommended and Optional Tiers
Next: [BP 4.4] Intune Licensing: The Suite That Dissolved Into Microsoft 365 ›
