TL;DR: As identity providers accumulate more user groups, overprovisioning, unclear ownership, and nested dependencies increase blast radius and compliance burden, according to Opal Security. The security problem is not group creation itself but the absence of lifecycle discipline around who stays in groups, why the groups exist, and when they should disappear.
NHIMG editorial — based on content published by Opal Security: Back 4 Actions to Reduce Group-Based Access Control Risk
By the numbers:
- 90% of organizations experienced an identity-related incident in the past year.
- 100 groups within Okta., s up to 100 groups within Okta.
Questions worth separating out
Q: How should security teams reduce risk from group-based access control?
A: Security teams should treat groups as governed access structures, not convenience buckets.
Q: Why do oversized groups increase breach impact in IAM programmes?
A: Oversized groups increase breach impact because they expand the permissions inherited by a single account.
Q: What do teams get wrong about access reviews for groups?
A: Teams often review the existence of a group without understanding whether the group still has a valid purpose.
Practitioner guidance
- Define an owner and business purpose for every group Require each group to have a documented purpose, named owner, and explicit retirement condition before it can be used for new access grants.
- Make group membership time-bound by default Set expiration dates for user-to-group and group-to-resource relationships, then force renewal only when the need is still current.
- Prioritise cleanup of high-risk and sensitive groups Start with groups tied to critical systems, admin workflows, or nested inheritance paths, because those create the largest blast radius if compromised.
What's in the full article
Opal Security's full resource covers the operational detail this post intentionally leaves for the source:
- Step-by-step guidance for identifying groups that are overprovisioned and deciding which ones to target first.
- Operational examples of time-bound access for both user-to-group and group-to-resource relationships.
- Practical cleanup considerations for nested groups and automation-created groups that can break downstream workflows.
- The vendor's prioritisation approach for balancing cleanup risk against business disruption.
👉 Read Opal Security's analysis of group-based access control risk →
Group proliferation and overprovisioning: what should IAM teams do?
Explore further
Group-based access control has become a lifecycle problem, not a directory problem. The central failure is not that groups exist. The failure is that organisations let groups accumulate membership, scope, and purpose long after the original business need has changed. That turns access governance into a retention issue, where old permissions survive because nobody owns the cleanup. Practitioners should treat group membership as something that must expire, not something that merely exists.
A few things that frame the scale:
- 72% of organisations have experienced or suspect they have experienced a breach of non-human identities, according to The 2024 ESG Report: Managing Non-Human Identities.
- Two-thirds of enterprises have endured a successful cyberattack resulting from compromised non-human identities, with a quarter encountering multiple attacks, according to the same report.
A question worth separating out:
Q: Who is accountable when stale group access causes a security incident?
A: Accountability usually sits with identity owners, application owners, and compliance leaders together, because stale group access is a governance failure rather than a single technical mistake. The practical test is whether the organisation can explain why the group existed, who approved it, and why it was still active.
👉 Read our full editorial: Group-based access control risk is widening in IdP sprawl