Microsoft this month delivered a public preview that can permanently alter how your Intune administrators get their job permissions — but you can’t undo it once it’s on. As of March 2026, the Intune admin center includes a new Scoped permissions toggle that fixes years of overly broad role merging, and the associated Permissions Assessment Report is the only realistic way to test-drive the change before you commit your tenant. Ignoring the report and flipping the switch could silently cut off critical admin actions, so here is exactly what the new model does, whom it affects, and the step-by-step workflow to adopt it safely.
What Actually Changed — the End of
Scope tags exist to carve up Intune administration into logical boundaries: regions, business units, support tiers, and so on. Under the legacy behavior, when an administrator lands in multiple role assignments that contain permissions from the same category — say, Mobile Apps — Intune merges those permissions across all scope tags. The result is that an admin intended to have read-only access in one boundary can inherit create-update-delete capability simply because a different assignment within the same category hands out more privilege somewhere else.
Scoped permissions, now available as an opt-in public preview, changes that evaluation. Each role assignment’s permissions stay locked to the scope-tag context in which they were granted. To reuse Microsoft’s own example: an admin group that gets Read for Mobile Apps scoped to “Headquarters” and full CRUD for Mobile Apps scoped to “Regional Office” will, after enabling the feature, have exactly read-only at Headquarters and full control only at Regional Office. No silent elevation.
The setting is exposed at Tenant administration > Roles > Settings. Before you can even think about turning it on, you must generate the Permissions Assessment Report from that same page. The report shows, per security group, every permission reduction that will occur — which role combinations, which scope tags, and whether the old merged permission is shrinking to something narrower.
What It Means for You — by Role
The practical effects depend heavily on who you are inside the organization:
For IT operations and help-desk leads: The report may reveal that tasks your team currently performs are reliant on a permission that is technically “borrowed” from a wrong assignment. If Scoped permissions is enabled without adjusting those assignments, those tasks will start failing. The fix is not to avoid the feature but to make the assignment model honestly reflect intended access.
For security architects and identity managers: This is a long-overdue alignment with least privilege. The assessment report doubles as an audit of your current role design. Even if you delay enabling the preview, running the report now uncovers where your delegation boundaries are weaker than documented.
For anyone who manages role assignments: The cleanup can be messy. An admin might belong to five groups, each with subtle permission overlaps. Solving one reduction can surface another. The report is meant to be rerun repeatedly while you tune assignments, and the goal isn’t an empty report — it’s an explainable one where every post-enable permission set matches an approved job responsibility.
For the manager ultimately clicking the toggle: Enabling Scoped permissions is a one-time, tenant-wide action. There is no supported rollback. Treat it as a production control change: you’ll need formal sign-off, a communication plan, and ideally a change window in your ITSM tool.
How We Got Here — the Accidental Privilege Problem
Intune introduced scope tags years ago to enable distributed administration, but the permission-merging engine was always a compromise. When Microsoft shipped the public preview in March 2026, it acknowledged what many admins had grumbled about: a role model that inadvertently grants more power than intended isn’t truly role-based.
The announcement sat inside the official Use role-based access control (RBAC) and scope tags for distributed IT documentation, and Microsoft has been clear that this scoped behavior will eventually become the default for all tenants. No date for that switch has been published, so don’t panic about an imminent forced migration. But the writing is on the wall: every Intune tenant will eventually run with scoped permissions.
What to Do Now — a Battle-Tested Sequence
Here is the workflow that responsible Intune tenants are following right now:
Step 1: Generate and save the baseline
Navigate to Tenant administration > Roles > Settings, click Generate Report, and export the CSV or review the grid. Save this snapshot — it’s your before picture.
Step 2: Triage the reductions
The report lists, for each group, the Roles, Scope Tag, Resource, Old Permissions, and New Permissions. Don’t skim. For every row, classify the reduction:
- Intentional: The admin never needed the old permission; document it.
- Required but missing: The admin’s job still needs the action; you must amend the role assignment inside that scope tag.
- Unknown: Requires confirmation from the service owner or app team.
- Design debt: The whole assignment structure is overly complex and should be simplified.
Step 3: Remediate assignments — not by bypassing the feature
Do not attempt to “avoid” the reduction by assigning more permissive roles globally. That defeats the security goal. Instead, explicitly add the missing permission to the correct role assignment within the proper scope tag. The Roles > All roles > Assignment workflow lets you assign scope-tag-level actions precisely.
Step 4: Rerun, review, communicate
After any assignment change, regenerate the report. A clean or fully understood reduction set is your readiness signal. Then communicate the expected changes to the affected admins. Tell them: “After we enable Scoped permissions on [date], your console will no longer show these actions on objects tagged XYZ. You gain nothing new; you only lose access that was accidental.”
Step 5: Get the right role to flip the toggle
You need either a custom Intune role that includes the Update action for the Organization resource type, or the Intune Administrator Entra role. Microsoft recommends the custom role to avoid overprivilege, but be aware that no built-in Intune role currently has that Update permission — you must create one.
Step 6: Enable in a controlled window
Plan the toggle flip during a maintenance period. Immediately spot-check that critical admins can still perform their duties. If something breaks, remember: there is no “turn off” button. You’ll be opening cases with Microsoft support or hurriedly adjusting assignments on the fly.
Outlook — Why This Isn’t Going Away
Even if you ignore the preview today, Scoped permissions will one day become the default. The current opt-in period is a gift: you have time to inventory your delegation model, clean up role bloat, and train your admins. Microsoft hasn’t set a cutoff, but Intune’s trajectory is clear. As the platform expands into endpoint privilege management, cloud PKI, and advanced analytics, the damage from inadvertently broadened permissions only grows.
Start the report now. Run it quarterly. When the forced migration arrives, you’ll already be living with the model — and your admins will thank you for not flipping a switch they never saw coming.