Admin roles and RBAC¶

An Intune admin account can wipe every device in the company. Treat Intune administration as a privileged activity: give people only the permissions they need, only for the devices they look after, and only when they need them.

Principles¶

1. No daily use of Global Administrator or Intune Administrator. Both are Entra privileged roles with full read/write over Intune. Use Intune's own roles for routine work.
2. Separate admin accounts. Admins use a dedicated, cloud-only account without a mailbox for admin work, not their everyday account.
3. Just-in-time elevation. Make powerful roles eligible through Privileged Identity Management (PIM) instead of permanently assigned.
4. Two people for destructive actions. Use Multi Admin Approval for wipes, retires, deletes, scripts and role changes.
5. Review regularly. Check who has what every quarter.

Entra roles that reach into Intune¶

These Entra roles carry Intune permissions. Most are privileged and shouldn't be used for day-to-day Intune work.

Some tasks still require Intune Administrator or Global Administrator, for example creating device limit restrictions or turning on Windows settings restore. Elevate for the task, then drop the role.

Built-in Intune roles¶

Assign these in Tenant administration > Roles > All roles.

Windows 365 tenants also see Cloud PC Administrator and Cloud PC Reader.

Custom roles¶

Create a custom role in Tenant administration > Roles > All roles > Create when a built-in role grants too much. Common examples:

Use Tenant administration > Roles > Monitor to check the result:

• My permissions shows the effective permissions of your own account.
• Roles by permission shows which role assignments grant a given permission, and to which groups.
• Admin permissions shows everything a specific account can do.

How a role assignment works¶

A role on its own does nothing. You create an assignment, which has three parts:

flowchart LR
    G["Admin group<br/>INT-ADM-EMEA-Desk"] --> RA[Role assignment]
    R["Role<br/>Tier 1 service desk"] --> RA
    RA --> SG["Scope groups<br/>EMEA users and devices"]
    RA --> ST["Scope tags<br/>EMEA"]

Things that trip people up:

• If an assignment includes an exclude group, that group must sit inside one of the assignment's scope groups, or be listed as a scope group itself.
• Avoid All users and All devices as scope groups for delegated admins. That gives them the whole tenant.
• When one admin has several role assignments with different scope tags, the permissions can combine more broadly than you expect. Intune has an opt-in preview setting that keeps each assignment's permissions inside its own scope tags. Test it if you run a delegated model.

Scope tags¶

Scope tags decide which objects an admin can see. Create them in Tenant administration > Roles > Scope tags, then:

1. Add the tag to the role assignment.
2. Add the same tag to the policies, apps and profiles that admin should manage.
3. Tag devices by assigning the scope tag to a group of devices from the scope tag's Assignments page.

Objects without a custom tag carry the Default tag. An admin whose assignment doesn't include Default won't see them.

Just-in-time access with PIM¶

Intune supports two ways to elevate with Microsoft Entra Privileged Identity Management:

PIM for Groups is the better least-privilege design because it works with your custom Intune roles. Warn admins about the delay so they don't assume elevation failed.

Multi Admin Approval¶

Multi Admin Approval (MAA) means a change to a protected resource doesn't apply until a second admin approves it. Set it up in Tenant administration > Multi Admin Approval > Access policies.

You can protect:

• Apps (app deployments, not app protection policies)
• Compliance policies
• Configuration policies created with the settings catalog
• Device actions: wipe, retire and delete
• Role-based access control: role permissions, admin groups and member assignments
• Scripts deployed to Windows devices
• Access policies themselves
• Tenant configuration: device categories

How it behaves:

• The requester makes the change and adds a justification. An approver reviews it. The original requester then completes the change.
• Nobody can approve their own request, including Global Administrators and Intune Administrators.
• MAA also intercepts Microsoft Graph calls from automation, including app-only service principals. Graph returns HTTP 412 with an approval code, and your script must resubmit after approval. Plan this before you protect resources that automation changes. See Automation with Graph.

Approver group requirements:

• It must be a security group (not a Microsoft 365 group or distribution list), and approvers must be direct members.
• The group itself must be added as a member group to at least one Intune role assignment. Otherwise members are removed from the approver group over time.
• Approvers need the Read permission for the resource type they approve, for example Managed devices: Read to approve a device delete.

Quarterly access review¶

• Export role assignments (Tenant administration > Roles) and confirm every member still needs the role.
• Confirm no one holds a permanent Global Administrator or Intune Administrator assignment except break-glass accounts.
• Review custom roles for permissions added "temporarily".
• Check the MAA approver group membership.
• Review Tenant administration > Audit logs for role and assignment changes.

Learn more¶

• Role-based access control with Microsoft Intune
• Built-in role permissions
• Use access policies to require multi admin approval