Once a business has more than one office, plant or clinic, Intune administration gets political. The local IT person at the second site needs to reset passcodes and push apps, but nobody wants them able to change the security baseline for the whole company. The answer is Intune scope tags and RBAC (role-based access control), used together. Roles decide what an admin can do. Scope tags decide which objects they can see.

This guide explains how the pieces fit, gives a design pattern for multi-site organizations, and lists the traps that quietly give people more access than you intended. Intune RBAC and scope tags are included with Intune Plan 1, part of Microsoft 365 Business Premium, E3 and E5.

The three parts of an Intune role assignment

Every Intune role assignment combines three things. Getting each one right is the whole job.

Roles alone are not enough. A Policy and Profile Manager with no scope tags can see every policy in the tenant. Scope groups alone are not enough either, because they control targeting, not visibility.

Start with the right roles

Intune includes built-in roles that cover most needs:

• Help Desk Operator for remote actions on users and devices.
• Policy and Profile Manager for compliance and configuration policies.
• Application Manager for apps and app configuration.
• Endpoint Security Manager for endpoint security policies.
• Read Only Operator for auditors and managers who need visibility only.
• Intune Role Administrator for managing roles themselves.

If a built-in role grants too much, create a custom role at Tenant administration > Roles > All roles > Create. A common example is a site technician role that can sync, restart and retire devices but cannot wipe them.

Keep in mind that Microsoft Entra roles sit above all of this. Anyone with the Intune Administrator or Global Administrator Entra role has full Intune access regardless of scope tags. Keep those roles for a small central team, ideally activated just in time through Privileged Identity Management, which needs Entra ID P2.

A design pattern for multi-site organizations

This is the pattern I use for businesses with two to ten sites. It keeps central IT in control of security while letting site staff handle daily work.

1. Create one scope tag per site at Tenant administration > Roles > Scope (Tags) > Create, for example HQ, DEN and PHX. Creating tags requires the Intune Administrator Entra role.
2. Assign each tag to that site’s device group on the tag’s Assignments page. Devices in the group get the tag automatically, which avoids manual tagging every time a laptop is replaced.
3. Create security groups for admins per site, such as Intune-Admins-DEN.
4. Create role assignments per site. For each role a site needs, add the site admin group as members, the site’s user and device groups as scope groups, and the site tag as the scope tag.
5. Tag site-specific objects. Apps and policies that only apply to one site, such as a local printer or a plant-floor app, get that site’s tag.
6. Leave company-wide security policy with central IT. Your compliance policies, security baselines and Conditional Access stay untagged by site and are managed by the central team only.

The result: a Denver admin sees Denver devices and Denver apps, can act on Denver users, and cannot see or change the company baseline.

Rules that surprise people

Scope tags behave in ways that are logical once you know them, and confusing until you do. These are the ones that cause real problems:

• No scope tag means everything. An admin whose role assignment has no scope tag can see all objects their permissions allow. Every delegated role assignment needs at least one tag.
• New objects inherit the creator’s tags. When a site admin creates a policy, it gets all of their scope tags automatically. That is usually what you want.
• Admins can only assign tags they hold, and can only target groups listed in their own scope groups.
• The Default tag is added to untagged objects. If you give a site admin the Default tag, they see everything that has not been tagged elsewhere.
• Automatic tag assignment overwrites manual tags on devices. Pick one approach for devices, and I recommend automatic.
• Multiple role assignments can merge. By default, permissions from one assignment can extend into the scope tags of another for the same admin, which may be broader than intended. Microsoft offers an opt-in setting to contain each assignment’s permissions to its own tags. Review it if any admin holds more than one assignment.
• Some objects cannot be tagged, including Windows Autopilot device records and corporate device identifiers. Plan around them.

Protecting the RBAC model itself

A well-designed RBAC model is only useful if nobody can quietly change it. Three controls help:

• Multi Admin Approval. Intune access policies can require a second administrator to approve changes to roles, as well as app deployments, scripts, compliance and configuration policies, and wipe, retire and delete actions.
• Audit logs. Review Tenant administration > Audit logs monthly for role and scope tag changes.
• Access reviews. Review membership of admin groups quarterly. People change jobs and their Intune rights rarely follow.

If you want an outside view of who can do what in your tenant, a Microsoft 365 security assessment includes an admin rights review, and an Intune health check covers RBAC and scope tag design specifically.

A quick test plan

Before you hand access to site staff, test with a pilot admin account:

1. Sign in as the site admin and open Devices > All devices. Confirm only that site’s devices appear.
2. Open the configuration policy list. Confirm the company baseline is not visible.
3. Try to assign a site app to a group outside the site. It should be blocked.
4. Run an allowed action, such as sync, on a site device. It should work.
5. Try an action the role does not include, such as wipe. It should be unavailable.

If any step behaves differently, check for a missing scope tag on the role assignment or the Default tag being included.

Frequently asked questions

What is the difference between scope tags and scope groups?

Scope groups define which users and devices an admin can act on and target. Scope tags define which Intune objects, such as policies, apps and devices, the admin can see. A delegated role assignment usually needs both.

Do scope tags limit Global Administrators?

No. Intune RBAC does not apply to Microsoft Entra roles. Global Administrators and Intune Administrators have full Intune access regardless of scope tags.

How many scope tags can I use?

You can assign up to 100 scope tags to a role or to an object. Most multi-site businesses need one per site plus perhaps one per department, so the limit is rarely an issue.

Microsoft’s reference is Use RBAC and scope tags for distributed IT on Microsoft Learn. For ongoing administration across sites, see our Intune managed service.

Want to know who can really change what in your Intune tenant? Book a free Microsoft 365 security assessment and we will review your admin roles and scope tags.