Intune RBAC: the permissions nobody tells you to set

Intune RBAC looks like one setting and behaves like four. Permissions sit on the role. The admin groups, the scope groups and the scope tags all sit on the assignment, and an admin who is short of any one of them gets an error that names none of them. The usual symptom is a help desk account that signs in to the admin centre perfectly well and then cannot open Devices. This page separates the four axes, names the permission every built-in role quietly carries, and lists the failure modes in the order they turn up.

If the account cannot see anything at all rather than one blade, start with the symptom index in Intune troubleshooting and come back here. Everything below assumes sign-in works and the gap is in what the admin is permitted to see.

What an Intune RBAC role assignment actually controls

A role is a list of permissions and nothing else. It grants no access until it is assigned, and the assignment carries three further decisions that the role itself knows nothing about. The wizard separates them across four pages, which is the clearest statement of the model anywhere in the product.

1# The four independent axes of an Intune RBAC grant. Each is set in a different
2# place, and getting any one of them wrong produces the same unhelpful error.
3Permissions      on the role          what the admin may DO
4Admin Groups     on the assignment    WHO holds the role
5Scope (Groups)   on the assignment    WHICH users and devices they may manage
6Scope (Tags)     on the assignment    WHICH objects they can SEE

The documentation is precise about the middle two, and most tenants still conflate them. Admin Groups is where you choose a group that contains, in Microsoft’s words, the users you want to assign the roles permissions to. Scope (Groups) is where you add groups that contain only the users or devices that the members of the Admin Groups you selected in the previous step should be allowed to manage. One is the administrator. The other is the population. The wizard walkthrough is in assign a role to an Intune administrator, and it carries one detail worth reading twice: All Users and All Devices are Intune virtual groups, not Microsoft Entra security groups, so a scope of All Users does not give an admin access to a specific Entra user group. You add both.

The permission every built-in Intune role carries

Intune ships nine built-in roles: Application Manager, Endpoint Privilege Manager, Endpoint Privilege Reader, Endpoint Security Manager, Help Desk Operator, Intune Role Administrator, Policy and Profile manager, Read Only Operator and School Administrator. Two Cloud PC roles appear as well once the tenant holds a Windows 365 subscription. The built-in roles reference prints the permission table for each of them, and one row is identical in all nine: Organization, with Read enabled.

A custom role started from an empty permission list does not have it, and nothing in the interface points that out. The documented purpose gives you no reason to go looking either. On the custom role page, Read on Organization allows viewing the Scoped permissions setting and running the Permissions Assessment Report, and Update allows enabling the Scoped permissions setting. That reads like a narrow reporting permission, which is exactly why people leave it off.

Field reports do not match that description. The most detailed public account is a Microsoft Tech Community thread from an admin who built a departmental custom role with admin groups, scope groups and scope tags all configured, and whose department admins hit a not authorized error the moment they opened the device list. After hours of comparing the custom role against a working built-in one, the poster found the cause: Read on the Organization permission had never been enabled. A later reply asking where that setting lives was never answered, which is a fair summary of how well this is documented.

I have not run this in production. My tenant is a lab with no enrolled devices, so I cannot tell you how reliably the device list depends on that single permission, or whether the behaviour has shifted since the thread was written. What I can tell you is the shape of the evidence, and it is unusually clear: every role Microsoft ships includes the permission, the documented purpose is narrower than the reported effect, and the cost of granting it is read access to tenant-level reporting. So treat the reference table as the baseline rather than a curiosity. Before you assign a custom role, open it beside the nearest built-in role and compare the permission lists row by row, instead of assuming that an empty list plus the permissions you meant to grant adds up to a working role.

Scope tags decide what an admin sees, not what they can do

Roles and scope tags answer different questions, and the distributed IT guidance puts the split in one line: roles determine what access admins have to which objects, scope tags determine which objects admins can see. Four consequences of that split account for most of the designs that come apart in month two.

The first is the empty field. An assignment with no scope tag is not a narrow grant waiting to be widened. Microsoft states it plainly: if a role assignment has no scope tag, that admin can see all objects their permissions allow, and admins with no scope tags essentially have all scope tags. A pilot assignment left blank was never scoped at all, so the first team to tag their own assignment appears to lose access while everybody else keeps everything.

The second is inheritance. When an admin creates an object in Intune, every scope tag assigned to that admin is automatically assigned to the new object. Policies therefore carry the tags of whoever built them, which is how a profile ends up visible to one region because a contractor happened to create it. Automatic tag assignments also overwrite manually set ones, and once your own role holds a scope tag you cannot strip an object back to none, because at least one is always required.

The third is coverage. Four object types do not support scope tags at all: corporate device identifiers, Windows Autopilot devices, device compliance locations and Jamf devices. If the plan was to divide Autopilot enrolment between regional teams with tags, it cannot be done, and nothing tells you so. The ceiling is 100 scope tags on a role and 100 on an object, high enough that nobody trips over it and worth knowing before anyone designs per-site tagging.

The fourth is the bypass. Intune RBAC does not apply to Microsoft Entra roles, so a Global Administrator, or any Entra role carrying Intune access, sees every object whatever the tagging says. An audit that samples admins holding Entra roles will report that scope tags do not work. They do work. Those accounts sit outside the model, which is also the strongest argument for keeping Entra roles out of daily operations. The tagging mechanics, including the default tag and automatic assignment, are set out in RBAC and scope tags for distributed IT, and I have written up the behaviour I could test in Intune scope tags.

The failure modes

Every one of these presents as a permissions problem and only two of them are.

Two of these are worth linking out of. Running a device query needs both the permission and the licence, and the licence is the part that surprises people: see Intune Device Query. Collecting diagnostics is a remote task, and the reference describes Read Only Operator as viewing information without making changes, so it is the wrong role for anyone expected to pull logs. What lands in the zip is in Intune diagnostic logs.

What I would do differently

Three roles, not thirty. The temptation with a permission matrix this granular is to model the organisation chart in it, and the result is a set of roles nobody can audit and no two of which are quite the same. Most tenants need a read-only role, a help desk role and a policy role, with the differences expressed in scope groups rather than in permissions.

Model the scope groups before the scope tags. Scope groups answer who an admin may touch, which is the question the business actually asked. Tags answer which objects appear, which is an internal consequence of how your policies were built. Designing the tags first produces a tagging scheme that fits the policy estate rather than the delegation.

Treat a blank Scope (Tags) field as a defect in the design, not a default. It is the widest grant in the product and it is also the one that looks most like an unfinished form.

Test by signing in as the admin. A role definition reads correctly far more often than it works, because the thing that breaks is the interaction between four separate settings and none of them is wrong on its own. If you have Organization with Read, the Permissions Assessment Report is the cheapest way to see the effective picture without borrowing somebody’s account.

Last verified: 10 October 2026.