Scope tags are the mechanism Intune gives you to divide one tenant between several teams without buying separate tenants. They look simple in the portal, and most guides stop at how to create one. The part that costs people an afternoon is what a scope tag actually governs. Intune scope tags control which objects an administrator can see and manage. They do not control which devices a policy is deployed to. Confuse those two and you either lock an admin out of their own work or, more often, hand them a view of the whole estate and wonder why the scoping did nothing.
This is a companion to the way which Intune policy actually wins is decided: RBAC scoping and policy assignment are two separate systems that people expect to be one, and the distinction matters as much in a co-management estate as in a cloud-only one. Below is how the scope tag resolves, the Default tag that quietly undoes your design, the failure modes nobody writes up, and what I would change if I were building it again. Verified against Microsoft Learn on 20 August 2026.
What Intune scope tags actually are
A scope tag is a freeform text label you attach to Intune objects: configuration profiles, compliance policies, apps, and enrolled devices. On its own the tag does nothing. It becomes meaningful only when the same tag is added to a role assignment. At that point an administrator holding that role assignment can see the objects carrying the tag, and nothing else.
You create them in the Intune admin center under Tenant administration, then Roles, then Scope (Tags), then Create. Microsoft documents a hard ceiling of 100 scope tags per role and 100 per object, which is far more than any sane design needs. If you are approaching either limit, the problem is the design, not the ceiling.
Intune scope tags scope visibility, not deployment
This is the single fact that resolves most scope tag confusion. A scope tag limits what an admin can see in the console. It has no effect on which users or devices receive a policy. Deployment is decided entirely by the assignment on the policy itself, the include and exclude groups. You can tag a compliance policy with a London tag, assign it to a group of Manchester devices, and it will apply to every Manchester device. The tag only decided who could open the policy in the portal.
Microsoft’s own guidance is explicit that a role assignment carries two different scopes. Scope (Groups) defines the users and devices an admin can manage. Scope (Tags) defines which tagged objects that admin can see. These are answering different questions, and the failure to keep them apart is where designs come undone.
How a role assignment resolves
An Intune role assignment has three moving parts, and it is worth naming all three because the portal presents them as one screen:
Admin Groups: the security group whose members receive the permissions. Scope (Groups): the users and devices those admins are allowed to manage. Scope (Tags): the tagged objects those admins are allowed to see.
Read that as a chain. An admin sees an object only if it carries one of their assigned scope tags, and can act on a device only if that device falls inside one of their scope groups. Both conditions have to hold. A tag with no matching device group produces an admin who can see a policy but cannot manage anything with it, which reads exactly like a permissions bug and is not one, in the same way that several problems only look like a sync failure.
The Default scope tag, and the objects you forget to tag
Every object that supports scope tags is given the Default scope tag automatically until you change it. This is the quiet undoing of a lot of scoping work. You build regional tags, assign them carefully, and then a policy created last year still carries only Default. If a delegated admin has the Default tag on their role assignment, they see it. If they do not, it vanishes from their console even though it is deployed and working.
There is a second edge here worth knowing before it bites: if your own role has a scope tag assigned, you cannot remove every scope tag from an object. At least one is always required. That is a guard rail, not a bug, but it surprises people mid-cleanup.
The failure modes
These are the ones that generate Tech Community threads about Intune scope tags, and almost none of them are written up in the walkthroughs.
A scoped admin still sees every device. This is the most common report. The scope tags are correct, and the admin still sees the whole estate. The cause is nearly always the role assignment, not the tags. Either Scope (Groups) was left as All Devices or All Users, or the account also holds a broad Entra directory role such as Global Administrator or Intune Administrator, which bypasses Intune RBAC entirely. Scope tags cannot claw back visibility that a directory role already granted, so tighten those accounts with a Conditional Access policy rather than expecting scoping to contain them.
The device count in a view looks wrong. A scoped admin opens the device list and the number does not match what they expected. Device visibility is governed by the scope groups on the assignment, and a device can sit in more than one group, which is worth ruling out before you chase it as a device that will not sync. If a device is a member of any group inside the admin’s scope, it shows up, even if you thought you had excluded it elsewhere. Scope tags on the device do not subtract from that.
A new policy disappears from a delegated admin’s view. Someone creates a policy and the regional team cannot see it. It was created without their tag and inherited Default. The object is fine and deployed; it is simply invisible to that role assignment. The fix is to add the correct tag to the object, not to touch the role.
Exclusions behave unexpectedly. Microsoft notes that an exclude group used in a policy assignment has to be nested inside one of the RBAC scope groups, or listed separately as a scope group, for a scoped admin to manage it correctly. Miss that and the exclusion appears to do nothing for the delegated admin.
What I would do differently
I have not run a multi-region scope tag design in production; my tenant is a lab with no enrolled devices, so what follows is judgement from the documentation and from how the mechanism resolves, not a migration I have measured.
I would stop trying to make scope tags do targeting. The instinct is to reach for a tag when what you want is for a policy to land on a subset of devices, and that is the wrong tool every time. Targeting is an assignment group. Visibility is a scope tag. Write that on the wall before you design anything.
I would tag at creation, never as a cleanup pass. The Default tag is patient and it will accumulate a backlog of objects that one team cannot see, discovered only when someone asks why a working policy is missing from their console. A creation-time convention, enforced in whatever automation builds your policies, costs nothing and removes an entire class of support ticket.
And I would keep the design flat. Two or three tags mapped to real teams beats a matrix of tags per region, per platform, per function. The 100 tag ceiling is not the constraint. The constraint is the human who has to reason about why an admin can or cannot see a thing at four in the afternoon.
Scope tags are a good mechanism used badly more often than not, because the portal makes them look like targeting and they are not. Keep them for visibility, target with groups, tag at creation, and most of the failure modes above never appear.
Last verified: 20 August 2026.
