Default groups are preconfigured group memberships that are assigned automatically when a user account is created or meets a preset condition. They are commonly used to apply baseline permissions, but they can also create excess access if the inherited entitlements are not reviewed and removed.
What Default Groups Do in Access Governance
Default groups are a convenience mechanism: they give new accounts an immediate baseline access profile without requiring manual group assignment. That makes onboarding faster, but it also means the access model starts with inherited entitlements that must be treated as real privileges, not harmless defaults.
Because default groups are applied automatically, they influence the first security posture a user or workload receives. In practice, they are part of the access design, not just a provisioning shortcut, so their contents should be reviewed with the same care as any other entitlement bundle.
Why Default Groups Become an Access Expansion Problem
The danger is not the group concept itself, but the tendency for baseline membership to accumulate permissions over time. If default groups are broad, stale, or copied between environments, they can silently grant access that exceeds the user’s role, business need, or trust level.
That creates privilege creep in its earliest form. The risk is especially high when a default group is reused across many accounts, because a single configuration choice can expose a large population to the same unnecessary permissions.
How Organisations Review Default Group Exposure
Exposure review starts with inventory: identify which accounts receive default group membership, what permissions those groups contain, and whether the assignment happens at creation time or through another preset condition. The next step is to compare those entitlements against the actual work the account must perform.
It also helps to trace where default group logic lives in the provisioning path, because the source of the assignment may sit in identity workflows, directory policies, SaaS admin settings, or cloud platform defaults. When default access is tied to platform or environment setup, a configuration review is often as important as the entitlement review itself.
For cloud and platform contexts, Azure Landing Zones Security Guide is useful when default group behaviour is driven by subscription or management-group baselines, and Cloud Network Security Guide helps when default access also intersects with permissive network paths or shared infrastructure patterns.
How to Reduce Risk from Default Group Memberships
Default groups should be intentionally minimal, with each entitlement justified by a clear baseline need. Where possible, they should be narrow enough that they support initial access without becoming the place where long-term authorization quietly accumulates.
Good practice is to pair default membership with periodic entitlement review, so inherited access is removed when it is no longer needed. Baseline permissions should also be separated from elevated or sensitive access, because mixing those two in one default group makes future governance much harder.
For design discipline, CISA Secure by Design supports the principle of shipping secure defaults rather than permissive ones, while NIST Cybersecurity Framework 2.0 reinforces the need to govern and monitor access rights over time.
What Happens When Default Groups Are Misused
Misuse usually shows up as overassignment, where default membership becomes a shortcut for convenience and eventually a back door to excess privilege. In identity-heavy environments, that can translate into broader lateral movement, harder recertification, and weaker accountability for who should really have access.
When a compromised or unnecessary group becomes the default, the issue is not just excess access, but excess trust. That makes the group a security boundary in practice, even if it was never intended to be one.
From a control perspective, NIST SP 800-53 Rev 5 Security and Privacy Controls is relevant because default memberships are an access control and configuration management problem, and OWASP Non-Human Identity Top 10 is useful where the same default-group pattern affects service accounts, workloads, or other non-human identities.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-2 — Account Management | Default groups are assigned through account provisioning and entitlement assignment. |
| AC-6 — Least Privilege | Default groups can grant excessive baseline permissions if not tightly scoped. | |
| CM-6 — Configuration Settings | Default group behaviour is often defined by platform or directory configuration. | |
| Recommendation — Review default group membership during account lifecycle changes and remove unnecessary inherited access. Limit default group permissions to the minimum needed for initial access and basic operation. Standardize and review default access settings so inherited permissions do not drift wider over time. | ||
| CIS Controls v8 | CIS-6 — Access Control Management | Default groups directly affect how accounts receive, retain, and lose access rights. |
| CIS-5 — Account Management | Default group assignment is part of account provisioning and lifecycle governance. | |
| Recommendation — Maintain and recertify default memberships to prevent unnecessary privilege accumulation. Map default groups to onboarding workflows and remove obsolete access as accounts change. | ||
Related resources from NHI Mgmt Group
- What breaks when organisations leave default readable access on sensitive Active Directory groups?
- What happens when Azure DevOps access is managed only through default groups and inherited permissions?
- Should security teams disable OneDrive auto-sync by default?
- What breaks when RC4-only Kerberos accounts are migrated into AES-default Active Directory domains?