From scoped operator to fleet control: Intune RBAC scope-tag escalation
A scope-tag or role-assignment misconfiguration lets a limited Intune operator widen their own reach to the entire fleet. The escalation lives in a grant, not a session.
Intune RBAC uses roles and scope tags to keep operators inside their lane. If an operator can edit their own role assignment or scope tag, the lane disappears and a limited operator becomes a tenant-wide endpoint administrator.
How the attack works
An operator provisioned to manage only one device group modifies a role assignment or scope tag so their access expands beyond that group. They then hold, or assign to a principal they control, a role whose scope now covers all devices and policies. From there they begin viewing and modifying devices and policies outside their original scope and gain a full endpoint-management foothold across the tenant. This is Account Manipulation, T1098, leading to elevation-control abuse, T1548.
Why it works
The right to assign roles is often not separated from operational roles, so an operator can widen their own scope. Logging in, viewing in-scope devices, and the existence of policies are all normal, so the only signal is the role-assignment or scope-tag change itself in the Intune audit log.
How to fix it
Watching and waiting only buys the attacker time, because they already hold fleet-wide control. The escalation is a persistent grant, not a session, so remove the over-broad role assignment, correct the scope tags back to the intended group, and revert any out-of-scope changes before they become persistence. For the root cause, separate the ability to assign roles from operational roles so no operator can self-escalate, audit all assignments to least privilege, and alert on every role-assignment and scope-tag change.
Practice it
We built this as a GraphLattice Range scenario so administrators can rehearse spotting a scope change, pulling the over-broad grant, and restoring least privilege.