Notifications
Clear all
Topic starter
11/06/2026 11:45 pm
TL;DR: Group-based access control can hide nested permissions, stale memberships, orphaned groups, and overprovisioned users across modern SaaS estates, according to Zluri. The governance problem is not the group model itself but the static access assumptions behind it, which break least privilege as environments change.
NHIMG editorial — based on content published by Zluri: Access Management 4 Ways to Reduce Risk in Group-Based Access Control
By the numbers:
- 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools.
- 90% of IT leaders say properly managing NHIs is essential for a successful zero-trust implementation.
- 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface.
Questions worth separating out
Q: How should security teams review group-based access in complex environments?
A: Security teams should review the effective access path, not just the visible group roster.
Q: Why do nested groups create more access risk than simple role assignments?
A: Nested groups increase risk because they hide indirect privilege inheritance.
Q: What should organisations do when groups no longer have a clear owner or purpose?
A: They should treat those groups as active access risks, not dormant clutter.
Practitioner guidance
- Flatten effective access before each review cycle Generate a user-level entitlement view that includes direct and nested group inheritance, then certify against effective access rather than visible top-level membership.
- Assign explicit ownership to every active group Require a named business owner, documented purpose, and review cadence for each group that still grants access to production apps or sensitive data.
- Expire temporary access structures automatically Set time-bound rules for project, contractor, and testing groups so access is removed when the use case ends instead of waiting for quarterly cleanup.
What's in the full article
Zluri's full article covers the operational detail this post intentionally leaves for the source:
- Step-by-step methods for mapping nested group chains across Entra ID and Okta.
- Specific review patterns for orphaned groups, including cadence and ownership checks.
- Operational guidance on using HRMS and ITSM attributes to drive dynamic group assignment.
- Practical walkthroughs for automating certifications with risk context and remediation closure.
👉 Read Zluri's analysis of 4 ways to reduce risk in group-based access control →
Group-based access control: the governance gap teams are missing?
Explore further
12/06/2026 8:34 am
Static group membership is a governance assumption, not a control. The article exposes a basic identity premise that groups stay aligned with business need after they are created. That premise fails as soon as roles, projects, and app ownership move faster than manual review cycles. The implication is that identity programmes must stop treating group structures as self-correcting governance artefacts.
A few things that frame the scale:
- 71% of NHIs are not rotated within recommended time frames, increasing the risk of compromise over time, according to Ultimate Guide to NHIs.
- Only 5.7% of organisations have full visibility into their service accounts, according to Ultimate Guide to NHIs.
A question worth separating out:
Q: When should teams replace static groups with attribute-based access control?
A: Teams should move to attribute-based access control when access decisions depend on changing context such as role, department, employment status, or location. Static groups work best where access is stable. They fail when permissions need to follow frequent business change, because membership lags behind reality and leaves excess access in place longer than intended.
👉 Read our full editorial: Group-based access control is creating hidden governance risk
