Notifications
Clear all
Topic starter
12/06/2026 12:53 am
TL;DR: Group sprawl in Microsoft 365 and similar collaboration stacks creates ownership ambiguity, access drift, and security blind spots when teams can create groups without coordination, according to Zluri. The governance issue is not the volume of groups alone, but the loss of control over who creates them, why they exist, and when they should be retired.
NHIMG editorial — based on content published by Zluri: Access Management Group Sprawl: What Is It and How To Fix It?
Questions worth separating out
Q: How should security teams control Microsoft 365 group sprawl?
A: Start by making group creation a governed event, not a free-form action.
Q: Why does group sprawl create access risk for IAM teams?
A: Group sprawl creates risk because every extra group becomes another entitlement boundary that can outlive its original purpose.
Q: What do organisations get wrong about collaboration group governance?
A: They often treat group management as a productivity issue and only later discover it is an access governance issue.
Practitioner guidance
- Inventory every collaboration group against an owner and purpose Build a register that records business owner, creation rationale, data sensitivity, and retirement criteria for each group so reviewers can judge whether it still serves a current need.
- Link group creation to policy checks and approval workflows Prevent ad-hoc creation by requiring a business justification, named owner, and scope review before a new group is provisioned in Microsoft 365 or adjacent collaboration platforms.
- Schedule recurring rationalisation of stale groups Run periodic reviews to identify duplicate, abandoned, or underused groups and delete or archive them when the business purpose no longer exists.
What's in the full article
Zluri's full article covers the operational detail this post intentionally leaves for the source:
- Step-by-step governance controls for creating, reviewing, and retiring Microsoft 365 groups.
- Practical examples of how centralised access requests can be used to reduce ad hoc collaboration sprawl.
- Operational guidance on using automation to streamline group lifecycle management and audits.
- A vendor-specific view of access management workflows for teams already standardising collaboration governance.
👉 Read Zluri's article on access management group sprawl and remediation →
Microsoft 365 group sprawl: what IAM teams need to fix?
Explore further
12/06/2026 10:25 am
Group sprawl is an identity governance failure, not a collaboration preference issue. The article describes a familiar pattern where decentralised creation outpaces policy, ownership, and review. That is a lifecycle breakdown because each group becomes an access object with its own privilege footprint. Practitioners should treat uncontrolled group creation as part of identity governance, not as a workspace cleanup task.
A few things that frame the scale:
- 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, according to Ultimate Guide to NHIs.
- 91.6% of secrets remain valid five days after the targeted organisation is notified, which shows how slowly invalid access can be removed in practice.
A question worth separating out:
Q: Who should be accountable for removing stale collaboration groups?
A: Accountability should sit with the business owner of the group, supported by IAM or IGA operations that enforce review and deletion workflows. If no owner is named, the organisation has already lost the governance signal it needs to safely certify or retire the access object.
👉 Read our full editorial: Group sprawl in Microsoft 365 creates hidden access risk
