Intune RBAC and Scope Tag Delegation Design Guide · CloudEngineerHub
Intune10 min read6 views
Intune RBAC, Scope Tags, and Delegation Design for Enterprise Teams
Build least-privilege Intune delegation with built-in and custom roles, scope tags and scope groups, and automation identities that stay auditable and small.
C
CloudEngineerHub Team
Published: September 19, 2026· Last Updated: October 26, 2026·10 min read
Someone in the service desk needs to unlock a screen. A regional team wants to publish its own applications. Security wants read-only visibility into compliance. In many tenants all three get answered the same way: grant the Intune Administrator directory role and move on. A year later an audit asks who can wipe devices, and the answer is uncomfortable.
Visual Walkthrough
Delegation without holes: the intersection that grants effective rights.
Layered StackIntune RBAC — Role Meets Scope Tag5/5
PerimeterCore asset
1
Entra directory role
Intune Admin / Global Admin — the tenant-level floor.
floor
2
Intune RBAC role
Endpoint Security Manager, Help Desk, custom roles refine verbs.
role
3
Scope tag attached
Objects tagged by region/team become visible subsets.
scope tag
4
Assignment scope
Scope groups limit which users/devices the role touches.
scope group
5
Effective permission
Intersection of all three — document the matrix, verify with a test admin.
Each layer assumes the previous one failed — depth is the strategy.
Intune RBAC — Role Meets Scope Tag. 1. Entra directory role: Intune Admin / Global Admin — the tenant-level floor. — 2. Intune RBAC role: Endpoint Security Manager, Help Desk, custom roles refine verbs. — 3. Scope tag attached: Objects tagged by region/team become visible subsets. — 4. Assignment scope: Scope groups limit which users/devices the role touches. — 5. Effective permission: Intersection of all three — document the matrix, verify with a test admin.
C
CloudEngineerHub Team
Author
The CloudEngineerHub editorial team — Microsoft endpoint management and cloud engineers writing hands-on guides on Intune, Azure, Entra ID, Autopilot, Defender and PowerShell. Every article is reviewed against current Microsoft documentation.
Intune role-based access control, scope tags, and scope groups exist precisely to avoid that outcome. This guide designs a delegation model that survives growth: when built-in roles are enough, how to carve up objects with scope tags, how scope groups bound what an admin can affect, how to build a helpdesk role people actually use, and how to keep automation identities and role assignments auditable.
Why This Matters
Delegation failures in Intune are quiet. An over-scoped role does not break anything on Monday; it surfaces months later when a contractor retires the wrong device or edits a compliance policy belonging to another region. Regulators and customers increasingly ask who can change endpoint management, and a tenant where everyone holds global admin rights has an awkward answer.
Good scoping also improves daily operations. Scoped admins see only their objects, which removes noise and mis-clicks, and your audit trail maps cleanly to the org chart instead of to whoever had the console open.
Intune RBAC Building Blocks
Two concepts combine into everything else:
Role definitions group permissions (read, update, assign, delete) across object areas such as apps, device configuration, compliance policies, and managed devices, often with platform restrictions you can tick or untick.
Role assignments bind a definition to Entra security groups of users or service principals and to two scoping layers: scope tags and scope groups.
Scope tags are labels you attach to managed objects such as devices, applications, and profiles. An admin only sees and manages objects carrying their assigned tags. Scope groups bound which users or devices the admin's assignments can affect. A role assignment therefore grants permissions only inside the intersection of its tags and scope groups, which is exactly the lever you need for regional or platform delegation.
Built-In Roles Versus Custom Roles
The built-in set covers common shapes: Policy and Profile Manager for configuration, Application Manager for app lifecycle, Endpoint Security Manager for security baselines and compliance, Help Desk Operator for frontline device actions, plus Read Only Operator and School Administrator. Built-in roles are immutable, so treat them as templates rather than finalists.
When none fits, create a custom role by cloning the closest built-in and removing what you cannot justify. Two habits keep custom roles healthy. Name them for a function, not a person (Endpoint Ops EU, not Dave's Role). And keep a change note in the description that records the ticket justifying each permission. A role whose description explains why it exists is auditable; one that does not is an incident waiting for context.
Built-in role
Typical holder
Scope pattern
Help Desk Operator
Service desk
Device actions only, scoped to supported pools
Policy and Profile Manager
EUC engineering
Config objects, broad read
Application Manager
App packaging team
App objects plus assignments
Endpoint Security Manager
Security operations
Baselines, compliance, antivirus
The Scoping Model: Tags and Scope Groups
Design the tag taxonomy before you create any tags. Most tenants land on a two-axis scheme: one tag per platform or function, one per region or business unit. Devices can carry multiple scope tags (up to 15), while objects such as apps and profiles carry the tags chosen at creation. Anything left untagged falls under the Default scope tag, which is how delegation quietly breaks: a colleague creates an untagged app, and the Europe-scoped admin simply cannot see it.
Scope groups are the other half. They bound what a role assignment can affect: user groups for user-targeted actions, device groups for device-targeted ones. Prefer dedicated security groups designed for delegation rather than reusing the groups that drive policy assignments, because the two audiences grow for different reasons.
Layer
Applies to
Example
Scope tag
Devices, apps, policies, profiles
Europe, macOS, Server team
Scope group
Users and devices affected by assignments
EU-Windows-Devices
Role permissions
Object areas and actions
Read devices, wipe, sync
Assign roles through dedicated role-holder groups, never through direct user membership. The group is the audit unit; swapping a person becomes a group edit, not a permission change.
Reference Design: Helpdesk Operator
A workable build for a frontline team:
Clone Help Desk Operator into a custom role named for the function, for example Service Desk Device Actions.
Trim it to actions the desk performs daily: read device properties, sync, remote lock, and retire for user-enrolled devices. Grant wipe only for corporate pools where policy demands it, because retire removes management and organizational data while wipe resets the entire device, and the difference matters at scale.
Assign the role to a role-holder group whose membership follows your rota, not named individuals.
Scope it with the helpdesk's device and user scope groups plus a visibility tag set for the regions they support.
Pilot with two agents for a week: confirm they can complete a sync and a retire, and that they cannot see another region's devices.
Document the role with screenshots in your runbook so onboarding does not depend on tribal memory.
If the desk also handles password resets and sign-in issues, train that those live in Entra ID, not Intune, and keep the two toolsets separate in the runbook.
Automation Identities and Service Principals
Pipelines should authenticate with dedicated app registrations or workload identities, one per function (app-deployment automation, compliance reporting), so a leaked secret has a contained blast radius instead of being a master key. Grant Microsoft Graph application permissions at the narrowest scope that works, for example DeviceManagementConfiguration.ReadWrite.All for a configuration pipeline, and never bundle the managed-devices privileged set into a reporting identity.
Understand the scoping caveat honestly: Intune's scope tags fence delegated (user) access in the console and Graph, while app-only application permissions are effectively tenant-wide for whatever they grant. Keep application permission sets minimal, rotate credentials on a schedule, and audit service principals alongside humans. Where you need scoped automation, run it with a delegated identity holding a scoped Intune role rather than broad application permissions.
Interactive FlowMulti-Admin Approval — Guardrail for High-Risk Change5/5
1
Protected resource edited
High-risk objects (e.g. scripts, baselines) trigger a request.
request
2
Approval request raised
Change captured with diff and requester identity.
approve
3
Second admin approves
A different admin reviews context and approves/denies.
apply
4
Change applies
Only then does the edit take effect on the resource.
5
Audit trail complete
Request, approval, and result stored for compliance review.
Multi-Admin Approval — Guardrail for High-Risk Change. 1. Protected resource edited: High-risk objects (e.g. scripts, baselines) trigger a request. — 2. Approval request raised: Change captured with diff and requester identity. — 3. Second admin approves: A different admin reviews context and approves/denies. — 4. Change applies: Only then does the edit take effect on the resource. — 5. Audit trail complete: Request, approval, and result stored for compliance review.
Auditing Role Assignments
Make role review a quarterly routine rather than an audit-season panic:
Export current role assignments and compare them against an expected-state file in source control; drift means an undocumented change or a stale file.
Review Entra ID audit logs for role and directory-role changes, and Intune's own audit logs (Tenant administration, then Audit logs) for permission-relevant object changes.
Include service principals and their Graph permissions in the same review; automation identities outlive their owners.
Run access reviews on role-holder groups so managers attest to their people twice a year.
Watch for permission creep after incidents: emergency grants tend to survive the incident.
Best Practices
Default-deny by design: start with no access and grant into it; you will under-scope far less than when you start wide and trim.
One function per custom role; composable roles beat god-roles.
Treat tags as taxonomy, not decoration; review the tag list quarterly and delete orphans.
Test every role with a real pilot account before assigning the rota.
Use PIM-style elevation for rarely used permissions instead of permanent membership.
Common Pitfalls
Granting the Intune Administrator directory role to the helpdesk temporarily; it has no scoping at all.
Leaving objects on the Default scope tag so scoped admins cannot see them, then widening scopes to fix visibility.
Reusing policy-assignment groups as scope groups, so delegation grows whenever a policy audience grows.
Assigning roles to individual users; the audit trail becomes an HR question.
Granting wipe to a BYOD-facing role where retire was the intended action.
Over-permissioning app-only service principals and forgetting they are not fenced by scope tags.
Do scope tags hide objects from admins or only block edits?
Both. Objects outside an admin's scope tags are not visible in their console at all, and objects they can see are manageable only if the role assignment's permissions allow it. Tags gate visibility, role permissions gate actions, and scope groups gate assignment targets.
Can I delegate just macOS devices to one team?
Yes. Restrict the role assignment by device platform, scope its tags to the macOS tag set, and scope its groups to macOS device collections. Platform restriction combined with tags gives clean separation even when Windows and Mac fleets share a tenant.
How do I stop the helpdesk wiping devices by mistake?
Give the BYOD-facing role retire only and reserve wipe for a corporate-device role. Because Intune roles cannot require per-action approval, pair the split with privileged elevation for the wipe-capable group so the capability exists but is used deliberately.
Comments
0No comments yet — be the first to share your thoughts.