In March 2026, Microsoft introduced an opt-in public preview for Scoped permissions in Intune, a new RBAC behavior that stops the platform from silently merging admin permissions across role assignments with different scope tags. The change is a significant step toward least-privilege access, but it comes with an irreversible twist: once you flick the switch in the Intune admin center, you can’t turn it off. For now, tenants remain on the old merged-permission model, but Microsoft has confirmed that Scoped permissions will eventually become the default for all tenants—without publishing a hardening date. The clock is ticking for administrators to run the built-in Permissions Assessment Report, understand exactly who will lose what access, and clean up their role assignments before they’re locked in.
What Actually Changed
Intune’s role-based access control has always relied on scope tags to segment what admins can see and manage. Until now, if a single admin—or, more commonly, a security group—held multiple role assignments that covered the same permission category (like Mobile Apps or Device Configurations) but used different scope tags, Intune merged those permissions. The result was that an admin could end up with broader access than any single assignment intended, simply because the system combined privileges across all their assigned scope contexts.
Scoped permissions changes that calculation. When enabled, each role assignment’s permissions are evaluated strictly within its own scope tag context. No more merging. The same admin might have read-only rights on Mobile Apps tagged “Headquarters” and full create/update/delete rights on Mobile Apps tagged “Regional Office”—exactly as the role design intended, and nothing more.
The feature is tenant-wide and controlled by a single toggle under Tenant administration > Roles > Settings. Enabling it requires one of two roles: a custom Intune role with the Update permission for Organization (Microsoft’s recommended least-privilege option) or the built-in Intune Administrator Entra role. Once turned on, the setting cannot be reversed.
What It Means for You
This change lands differently depending on who you are in the organization.
For Intune administrators and IT operations teams: You’re on the front line. The Permissions Assessment Report—accessible from the same Settings page—is your primary tool. It displays every security group affected by the switch, the roles and scope tags involved, and a before-and-after comparison of permissions for each resource type. A group may show up multiple times if reductions occur across different resources. The report excludes groups with no members or no permission merges, so a clean report doesn’t automatically mean your RBAC design is perfect—it just means there’s nothing to merge.
For distributed IT organizations: This is where things get tricky. If you have regional support teams, help desk groups, application managers, or outsourced administrators who depend on access that only exists because of merged permissions, Scoped permissions will take that access away. A help desk tech who could reset device passcodes across all regions because of a merged assignment might suddenly be limited to a single office. The report won’t tell you whether that’s intentional; you need to talk to the teams that own those functions.
For security and identity architects: This is a welcome push toward least privilege, but it’s also a governance exercise. The assessment report asks a simple question for every affected group: are the lower, scoped permissions correct? Answering it demands up-to-date knowledge of who does what in Intune. Use the opportunity to weed out convenience groups that have accumulated unrelated administrators and to document why each reduction is either acceptable or must be corrected through explicit role assignments.
For end users: The change is invisible to them—unless an admin loses access they need to do their job, and support tickets pile up. That’s why communication and testing are so important before enabling the toggle.
How We Got Here
Intune introduced scope tags years ago to let organizations carve up administrative visibility. The idea was simple: an admin in Seattle should only see Seattle devices and policies. But the default permission calculation inherited a behavior from earlier Microsoft management tools: when two role assignments covered the same permission type, Intune treated the admin as having the combined permissions across all their assigned scope tags.
In small setups, this might not have mattered. In larger enterprises, it quietly undermined the segmentation that scope tags were supposed to provide. Over time, IT teams built complex role designs that accidentally relied on these merged rights. A regional admin who needed read-only access to compliance reports everywhere might have been granted that through a broad assignment, while a second assignment gave full policy-manipulation rights in their own region. The merger meant they could also alter compliance policies outside their region—a clear overprivilege.
Microsoft has been systematically hardening RBAC across its ecosystem, from Entra to Defender, and Intune was an obvious next step. The March 2026 public preview of Scoped permissions directly addresses this overgrant risk. The company has said that Scoped permissions will become the default behavior for all tenants at general availability, but it has not set a forced-change date. That ambiguity is both a gift and a warning: you have time to prepare, but you don’t know how much.
What to Do Now
Every hour between now and the day you enable Scoped permissions should be used to align your role assignments with your actual access needs. Here’s a step-by-step path:
-
Generate the Permissions Assessment Report. Go to Tenant administration > Roles > Settings and select Generate Report. The report runs almost instantly for most tenants. Export it to Excel immediately—you’ll need it for tracking.
-
Interpret the report columns. For each row, note the Group (the security group affected), Roles (the assignments whose permissions are being merged today), Scope Tag (the tag where a reduction will occur), Resource (the Intune resource type, like DeviceConfigurations or MobileApps), and the Old Permissions vs New Permissions comparison. Focus on the gaps: what moves from full control to read-only, or from read to nothing.
-
Assign ownership. Each affected group should have an operational owner—the person or team that knows what its members actually do in Intune. If you don’t know, find out. This is not an audit you can complete alone.
-
Decide on every reduction. For each row, ask: Is the reduced access correct for this group in this scope? If yes, document the approval and leave it as is. If no, update the role assignment to explicitly grant the needed permissions within the correct scope tag context. You may need to create new role assignments or adjust scope tags. Do not rely on the old merged result as a silent backdoor.
-
Rerun the report after changes. Fix everything you’ve identified, generate a fresh report, and confirm that the remaining reductions are all intentional. The report can be run as many times as you like—before or after enabling the toggle—so iterate until the picture matches your design.
-
Get formal sign-off. The toggle is one-way, so this decision should not rest on a single admin’s shoulders. Have the owners of the affected administrative functions approve the final report. Keep the exported file and the approval record. If a team later complains about missing access, you’ll be able to show whether it was intentional.
-
Enable the toggle. Only when you’re confident that the post-change access model is exactly what your organization intends, go to Tenant administration > Roles > Settings and turn on Scoped permissions. After this, your tenant will never merge permissions again.
A few things not to do:
- Don’t assume every reduction is bad. Some findings may surface overprivileged groups you’ve been meaning to trim.
- Don’t rely on verbal confirmation alone. Export, document, and archive.
- Don’t enable the toggle just because the report is available. The report is a decision tool, not a green light.
- Don’t treat this as a generic RBAC health check. It only addresses inter-scope-tag merging; it will not flag other misconfigurations.
Outlook
Microsoft’s language is clear: Scoped permissions will become the default. When exactly? No one outside Redmond knows. But given the one-way nature of the opt-in, tenants that wait too long risk being forced to adapt under a deadline—or worse, waking up one morning to a changed permission model they didn’t review.
For now, treat this as a preparation window. The assessment report gives you a safe, repeatable way to model the impact. Use it to clean up role assignments, tighten scope-tag design, and build the governance records you’ll need when the change becomes the new normal. Once Scoped permissions is on, your Intune administrators will finally have exactly the access you intended—no more, no less. Make sure that’s something your organization can live with permanently.