How do you stop non-admin users creating groups in Microsoft Entra ID and Microsoft 365?

You stop non-admin users by restricting group creation to approved administrators or by disabling self-service group creation where your organisation does not need it. Review who can create Microsoft 365 groups and security groups, then test the change with a standard user account. Also check for applications or workflows that depend on end-user group creation before tightening the setting.

What actually controls group creation in Entra ID and Microsoft 365?

Group creation is governed by tenant settings and directory roles, not by the user interface alone. In practice, you are deciding whether regular users can create Microsoft 365 groups and security groups, or whether that capability is reserved to approved administrators. The key control is to make the default path for group creation explicit, limited, and testable.

For Microsoft 365 tenants, that usually means tightening the group creation setting in Entra ID and then validating which roles still retain create rights. For readers hardening the wider platform, the same principle is covered in the Microsoft 365 Security Guide, which ties group governance to broader tenant hardening, auditability, and access control.

If your environment depends on delegated administration, use a design that clearly separates who can create groups from who can manage them after creation. That distinction matters because group creation is often the first step in building access paths, collaboration spaces, and application entitlements that later become difficult to unwind.

How to stop standard users without breaking collaboration

The practical choice is between restriction and exception handling. If end-user group creation is unnecessary, disable it and route requests through a controlled admin workflow. If the business still needs self-service for some teams, keep the setting constrained and align it with naming, ownership, and review rules so groups do not proliferate without accountability.

It is worth checking the surrounding identity model as well. The Active Directory and Entra ID Hardening Guide is useful here because group-creation permissions sit next to broader privileged group design, delegation, and access control decisions, especially in hybrid environments where directory boundaries are easy to blur.

Be careful not to confuse “blocking users from creating groups” with “making groups safer.” You still need ownership, lifecycle, and approval discipline for the groups that administrators create, otherwise you only move the sprawl from end users to admins.

What should you check before and after you change the setting?

Before you tighten the control, identify every dependency on end-user group creation. That includes onboarding automation, collaboration workflows, app provisioning, ticketing integrations, and any business unit that uses ad hoc Microsoft 365 groups as a process shortcut. A change that looks safe on paper can still interrupt legitimate work if those dependencies are not mapped first.

After the change, test with a standard user account and confirm the result in both Microsoft 365 group creation and security group creation paths. Then verify that the expected administrators can still create groups, and that the tenant does not have a second route, such as an app or workflow, recreating the same capability indirectly.

For organisations managing privilege more formally, the Privileged Identity Management (PIM) Guide is the right companion reference because the real control question is not just who can create groups, but whether that privilege is standing, time-bound, and reviewable.

Risk and Threat Considerations

Unrestricted group creation creates governance drift and a real trust boundary problem. Users can create access containers that are later reused for permissions, sharing, or application access, which makes it harder to understand who really owns the exposure and whether the group was created for a legitimate purpose.

Failure mechanism: If standard users can create groups freely, they can create persistent collaboration or access objects outside normal approval and review paths. That expands the attack surface for oversharing, privilege accumulation, and shadow administration, especially where groups are later linked to resources or apps.

Impact: The likely outcome is access sprawl, harder incident response, and more difficult cleanup after compromise or misuse. In a mature tenant, group creation should be a controlled administrative function or a tightly governed self-service capability, not an uncontrolled convenience feature.

Practitioner Guidance

What to verify: Confirm the setting affects the group types you actually care about, because Microsoft 365 groups and security groups may be governed differently in your tenant design. Also confirm whether any privileged roles, automation accounts, or delegated admin paths still bypass the intended restriction.

Decision rule: If business users genuinely need to create groups, keep the capability but surround it with ownership, naming, and review controls. If they do not need it, remove the capability entirely and require an approved admin path for every new group.

Practitioner takeaway: The safest design is not “no one can ever create groups,” it is “only the right identities can create them, and every exception is intentional, visible, and reviewable.”

Related resources from NHI Mgmt Group

• How do you configure the admin consent workflow in Microsoft Entra ID?
• How do you review and approve admin consent requests in Microsoft Entra ID?
• How do you use groups for secure access control in Microsoft Entra ID?
• How do you restrict which users can join devices to Microsoft Entra ID?