What this check looks at
Checks whether ordinary users can create security groups in the Azure portals, the API or PowerShell.
The Entra ID setting Users can create security groups in Azure portals, API or PowerShell decides whether any member of the tenant can create security groups and become their owner. Microsoft’s default is Yes. It is separate from the setting for Microsoft 365 groups, which Teams uses and this check does not cover.
The check reads the default user permissions in the tenant’s authorisation policy. It fails when ordinary users can create security groups and passes when they cannot.
Security groups grant access: to apps, to SharePoint sites, to Azure resources, and as inclusions or exclusions in Conditional Access policies. When anyone can create and fill them, groups appear with no owner in IT, official-looking names and members nobody reviews. An attacker with one compromised account can create a convincingly named group and ask for it to be added somewhere useful, and a group made for a project often keeps its access long after the project ends.
Why it matters
Security groups grant access to apps, files and Conditional Access exclusions. When anyone can create and fill them, groups appear that nobody owns or reviews, and access granted through them goes unseen.
Over a few years, a tenant where anyone can create security groups gathers dozens of unowned groups with confusing names. An administrator asked to give "Finance-Team" access to a site cannot tell the real finance group from one created by a temp, and access goes to the wrong people. During an incident, every unknown group is another thing to investigate.
Limiting creation to administrators, or to a group-management role, ties every security group to a request and an owner, which is what makes later access reviews meaningful. The cost is the occasional request to IT for a new group.
The CIS Microsoft 365 Foundations Benchmark (5.1.3.2) asks that users cannot create security groups. The rule maps to NIST CSF 2.0 PR.AA-05: access permissions defined, managed, enforced and reviewed.
How to fix it
Where: Entra admin centre → Groups → General
Before you start
- Check who creates security groups today (audit log, activity "Add group") and give them a group-management role if they still need to.
Step by step
- Check who creates security groups today. In the Microsoft Entra admin centre, go to Entra ID > Monitoring & health > Audit logs and filter Activity on Add group over the last 30 days. Note who, other than administrators, creates security groups for their work.
- Give a group role to anyone who still needs it. If someone genuinely needs to manage groups, assign them the Groups Administrator role in Entra ID > Roles & admins (scoped to an administrative unit where possible), or agree that IT creates groups for them on request.
- Change the setting. Go to Entra ID > Groups > General. Under Security Groups, set Users can create security groups in Azure portals, API or PowerShell to No and select Save. Leave the Microsoft 365 groups setting as the client wants; it is not part of this check.
- Or make the change in PowerShell. In Microsoft Graph PowerShell: Connect-MgGraph -Scopes Policy.ReadWrite.Authorization, then Update-MgPolicyAuthorizationPolicy -DefaultUserRolePermissions @{ AllowedToCreateSecurityGroups = $false }.
- Tidy up existing groups. In Entra ID > Groups > All groups, filter on Group type Security and look for groups with no owner in IT or no clear purpose. Give each an owner, or delete it after checking what access it grants.
- Confirm. Reload Groups > General and check the setting shows No. Re-run the assessment to confirm the finding passes.
What users will notice
Ordinary users can no longer create security groups in the portals, PowerShell or the API. Microsoft 365 groups and Teams are not affected by this setting.
How to confirm it worked
Entra admin centre, Groups, General: "Users can create security groups in Azure portals, API or PowerShell" is No.
Frameworks and controls
This check maps to controls in 13 frameworks. Passing it is evidence that the setting is in place, not a certification against any of them.
| Framework | Control |
|---|---|
| NCSC CAF | B2.d Identity and access management (IdAM) |
| DSPT | Standard 4: Managing data access |
| NIS2 | Art. 21(2)(i) Access control and asset management |
| Microsoft Cloud Security Benchmark | PA-7 Follow just enough administration (least privilege) |
| Zero Trust | Identities |
| SOC 2 | CC6.3 Role-based access and least privilege |
| NIST SP 800-171 | 3.1.5 Employ the principle of least privilege |
| CMMC Level 2 | AC.L2-3.1.5 Least Privilege |
| ISO 27001:2022 | A.5.15 Access controlA.5.18 Access rights |
| CIS M365 | 5.1.3.2 Ensure users cannot create security groups |
| CIS Controls v8.1 | 6.8 Define and maintain role-based access control (IG3) |
| NIST CSF 2.0 | PR.AA-05: Access permissions, entitlements, and authorizations are defined in a policy, managed, enforced, and reviewed, and incorporate the principles of least privilege and separation of duties |
| NCSC 10 Steps | Identity and access management |
The framework mappings were last checked against the published standards in October 2026.
Microsoft’s documentation
- Restrict security group creation (Microsoft Learn)