Configuring Entra ID to Prevent User-Created Apps and Security Groups

Chris Singlemann
/
Go-to-market

Microsoft Entra ID (formerly Azure Active Directory) allows regular users to register enterprise applications and create security groups by default. While this supports flexibility and user autonomy, it introduces real security and governance risks—especially in larger organizations. 

When unmonitored, these permissions can lead to unapproved app integrations, poorly scoped access controls, and attacker persistence via rogue OAuth apps or groups. Here, we'll break down the potential threats posed by these default settings, how to disable them via Entra configuration, and how to strike a balance between tightened control and user collaboration needs.

Why default permissions in Entra ID are risky

Out of the box, Entra ID grants standard users surprisingly broad permissions that many administrators don't realize exist. Non-admin users can register enterprise applications and create security groups without any approval workflow or oversight. This permissive default creates multiple attack vectors that security teams often overlook during initial tenant configuration.

When users register applications, those apps can integrate directly with Entra ID and request extensive permissions (such as Mail.Read, User.ReadWrite.All, or even Directory.ReadWrite.All). 

While users must consent to these permissions, the consent process is often misunderstood or clicked through hastily. Additionally, applications requesting high-privilege permissions may receive admin consent that bypasses individual user consent entirely. Once granted, these applications operate with the full scope of their requested permissions, potentially accessing sensitive organizational data across the tenant. the tenant.

Security groups created by users present a different but equally concerning risk. These groups can be granted access to critical resources or integrated into role-based access control (RBAC) systems. Without proper governance, user-created groups may receive unintended privileges through automated group-based access policies or manual assignments by other users who assume the groups were created through official channels.

The shadow IT implications are significant. User-created applications and groups often exist outside standard documentation and monitoring processes. IT teams may be unaware of their existence, making it difficult to assess the organization's true attack surface or conduct comprehensive access reviews.

From an attacker's perspective, these default permissions create attractive persistence mechanisms. A compromised user account can register a malicious OAuth application that appears legitimate while silently exfiltrating data or maintaining access even after the original compromise is discovered and remediated. Similarly, attackers can create security groups to establish backdoor access paths or escalate privileges through group-based permissions.

How to restrict app and group creation

The good news is that Microsoft makes it fairly straightforward to lock down these risky defaults. The configuration changes take just a few minutes but provide significant security improvements. 

Here's how to implement the restrictions:

  • Navigate to the Microsoft Entra admin center > Identity > User settings
  • Toggle off "Users can register applications"
  • Toggle off "Users can create security groups"

These simple changes immediately close the primary attack vectors while maintaining user productivity. 

Note: It's important to understand that these restrictions specifically target security groups, not Microsoft 365 groups. This distinction matters because Microsoft 365 groups power collaborative features in Teams, SharePoint, and Exchange Online. Your users will still be able to create Teams channels and Outlook groups—those collaborative experiences remain completely unaffected.

Once these settings are disabled, only users with appropriate administrative roles can register applications or create security groups. The change takes effect immediately across your tenant, so it's worth communicating the policy shift to your user community beforehand. While accessible from Entra ID, these settings can also be reviewed alongside the rest of your security policy settings and configuration in Prelude's monitoring platform.

Prelude console showing which users are currently configured to create applications and security groups.

For organizations that need some flexibility, consider implementing controlled workflows rather than blanket restrictions. Access reviews, approval processes through Microsoft Entra PIM, or integration with ticketing systems can provide the necessary oversight while still accommodating legitimate business needs. These workflows ensure that all app registrations and group creations are documented, approved, and properly configured.

Security and governance benefits

Restricting user-led app and group creation delivers immediate security improvements aligned with zero trust and least privilege principles. Here are the key benefits organizations can expect:

Security improvements:

  • Prevents attacker persistence: Eliminates a common technique where compromised accounts register OAuth applications for long-term access that persists even after the original breach is discovered
  • Enforces least privilege: Makes object creation an explicit, approved action rather than an assumed user capability
  • Reduces misconfiguration risks: Prevents accidentally created groups from gaining unintended access to sensitive resources through automated policies

Governance benefits:

  • Enables meaningful access reviews: IT teams gain complete visibility into all identity objects when the universe is controlled and documented
  • Reduces alert fatigue: Security monitoring systems stop flagging legitimate user-created applications and groups as suspicious activity
  • Improves audit readiness: Fewer user-created objects means simpler tracking and assessment during compliance reviews

Operational advantages:

  • Forces deliberate decision-making: Organizations must think intentionally about identity permissions rather than discovering problems after incidents
  • Catches overly broad permissions: Applications with excessive access rights are more likely to be identified and corrected during the approval process
  • Strengthens overall security posture: Provides visibility and control over identity infrastructure that doesn't exist with default settings

Balancing security with collaboration needs

The key to successful implementation lies in understanding what functionality these restrictions actually impact. 

Microsoft 365 group creation (the foundation of Teams channels, SharePoint sites, and collaborative workspaces) operates independently of security group restrictions. Users can continue creating Teams and working collaboratively without any interruption to their normal workflows.

For legitimate application development needs, organizations should establish clear pathways for developers to request app registrations through designated admin intermediaries or formal ticketing systems. This process doesn't need to be cumbersome; it simply needs to exist to provide visibility and basic approval workflows.

Consider implementing tiered approaches where certain user groups or roles retain expanded permissions based on their job functions. Developers, power users, or specific business units might receive delegated permissions to create applications or groups. While Microsoft Entra ID's administrative unit functionality helps with delegating management of specific users and groups, app registration permissions themselves are tenant-wide and would need to be managed through role assignments rather than scoped delegation.

The approval workflows themselves can be automated and streamlined using tools like Power Automate or integrated with existing ITSM platforms. The goal isn't to create bureaucratic overhead but to ensure that identity object creation is intentional, documented, and appropriately scoped.

Regular review of these policies ensures they remain aligned with business needs while maintaining security posture. As organizations mature their identity governance practices, they may find opportunities to refine permissions or adjust workflows based on actual usage patterns and risk assessments.

A low-effort, high-impact security improvement

Disabling default user permissions for app registration and security group creation represents a low-effort, high-impact security improvement that every organization should implement. The configuration takes minutes but provides long-term protection against common attack vectors while supporting comprehensive identity governance.

The key to success lies in implementing these restrictions thoughtfully, with clear communication about what changes and what remains the same. When users understand that their collaborative tools continue working normally while the organization gains better security posture, adoption becomes seamless.