Microsoft Purview RBAC, tightened: view-only role visibility, expiring access, and a scoping trap to know about

Ask most compliance teams who can see the membership of their eDiscovery or Insider Risk Management role groups, and the honest answer is “whoever we gave Role Management to” — which in practice tends to be one or two people with full edit rights, because Purview never had a read-only way to look. Auditors ask for a role assignment review, and the response is a screenshot from someone who could just as easily have changed what they’re screenshotting.

That gap just narrowed. Microsoft rolled out View-Only Role Management for Microsoft Purview in late July–August 2026 (Message Center post MC1403403), and it’s worth pairing with two other pieces of the same permissions model that don’t get nearly enough attention: automatic expiring role group assignments, and a role precedence rule that will quietly undo your scoping if you’re not aware of it.

What View-Only Role Management actually adds

The Global Reader and Security Reader Entra roles now get read-only visibility into role assignments and scopes inside the Purview and Defender portals — without any manual role group assignment. If your organization already uses Global Reader for auditors or Security Reader for your SOC, those people can now open Settings > Roles and scopes in the Purview portal and see who belongs to which role group, without being able to add, remove, or edit anything.

Rollout is Worldwide first (late July through late August 2026), with GCC, GCC High, and DoD following from late August through late September 2026. There’s no admin action required to enable it — Microsoft’s guidance is to use the moment to review whether other stakeholders (audit, GRC, a second pair of eyes on eDiscovery) should now be holding Global Reader or Security Reader instead of something heavier.

That’s a genuinely useful, low-risk change. But it only solves visibility. It doesn’t touch the two things that actually reduce your standing-access footprint.

The bigger lever: automatic expiring role group assignments

Purview role group assignments support an expiration date, independent of PIM. You can assign a user or group to a role group — eDiscovery Manager excluded, along with eDiscovery Administrator, which are the two built-in role groups that don’t support this — with an expiration between one day and two years. When the date hits, the assignment is removed automatically; no one has to remember to clean it up.

This is worth building into any Purview onboarding runbook, especially for anything project-scoped: a contractor doing a records management migration, an investigator on a single case, a consultant validating a DLP rollout. Instead of a calendar reminder to revoke access in 90 days, you set the expiration once:

1. Settings > Roles and scopes > Role groups in the Purview portal.
2. Select the role group, Edit, add the user or group.
3. Select Edit expiration and set the date.

A few details that change how you’d actually use this:

• If the same person gets the same role group both individually and through a security group, each assignment keeps its own expiration — access survives as long as either one is still valid. Don’t assume removing the individual assignment revokes access if a group assignment is still active.
• Extending, shortening, or removing an expiration is all self-service for whoever holds the Role Management role — there’s no approval workflow built in the way there is with PIM approval flows.
• You don’t get a notification before expiry, and no audit log entry is generated when the assignment actually lapses — only when the expiration date is set or changed. If you need to know when access silently expired, you’re inferring it from the absence of a “role group assignment” audit event where you expected one, not from an explicit log line.

For anything that needs just-in-time activation rather than a fixed expiry window, Purview role groups can also be assigned to a security group that’s under PIM for Groups — activation grants the role group’s permissions for the activation window. The one thing you can’t do is manage just-in-time activation through a direct user assignment to a role group the way you can with Entra role PIM; the group has to be the PIM-managed unit.

The trap: Entra roles override your Purview scoping

Administrative Units let you scope a Purview role group assignment — say, a regional Compliance Administrator who should only see cases tagged to their region’s AU. That scoping is real, but it only holds if the user has no equivalent Entra role assigned directly.

Purview’s own documentation spells out the precedence rule plainly: if a user has both an Entra role and a scoped Purview role group assignment, the Entra role wins at runtime, and the scoping is ignored — the user gets unscoped access to everything the role covers. Two ways this bites in practice:

• Assign someone the Compliance Administrator role directly in Entra, and also give them an AU-scoped Compliance Administrator role group in Purview: the Entra assignment overrides the scoping. They see every case, every region, full stop.
• Assign Global Reader in Entra alongside a scoped DLP Compliance Management role group in Purview: anywhere the two roles’ capabilities overlap, the user gets unscoped access to that overlapping data — even though you thought you’d fenced them into one AU.

If you’re building a delegation model around Administrative Units — regional compliance teams, subsidiary-level eDiscovery, anything where “this admin should only see their slice” is a real security requirement — you need to audit for exactly this combination: anyone holding both a broad Entra directory role and a scoped Purview role group assignment that role would otherwise subsume. A quick starting point with the Exchange Online / Security & Compliance PowerShell module:

Connect-ExchangeOnline
Connect-IPPSSession

# List every Purview role group and its current members
Get-RoleGroup | ForEach-Object {
    [PSCustomObject]@{
        RoleGroup = $_.Name
        Members   = (Get-RoleGroupMember -Identity $_.Name |
                     Select-Object -ExpandProperty Name) -join ', '
    }
} | Format-Table -AutoSize

Cross-reference the output against your Entra role assignments (Get-MgRoleManagementDirectoryRoleAssignment or the Entra admin center) for the same set of users. Anyone appearing in both lists for overlapping capabilities is a candidate whose AU scoping isn’t doing what you think it’s doing.

The takeaway

None of these three pieces is dramatic on its own, but together they describe what a mature Purview access model looks like: read-only reviewers who don’t need edit rights to verify anything (View-Only Role Management), time-boxed access that cleans itself up instead of accumulating (expiring role group assignments), and an explicit understanding that Administrative Unit scoping is not a security boundary once a broader Entra role is layered on top of it. Start with the audit — expiring assignments and view-only reviewers are easy wins, but the precedence gap is the one that will actually surprise you if you assumed AU scoping was doing more than it is.

---

Sources & further reading: Permissions in the Microsoft Purview portal, Microsoft Purview: View-Only Role Management (MC1403403) — message center summary, Get-RoleGroup (ExchangePowerShell), Get-RoleGroupMember (ExchangePowerShell), Privileged Identity Management (PIM) for Groups.