Misconfiguration Spotlight: Not Disabling Tenant Creation for Non-Admin Users in Entra ID

Every user in your organization is one click away from becoming a Global Administrator, just not in your tenant.

That’s the uncomfortable reality of Microsoft Entra ID‘s default configuration. Out of the box, any authenticated user, including guests in some cases, can spin up a brand-new Entra ID tenant. The person who creates it is automatically granted Global Administrator rights in that new tenant, with zero inherited policies, zero monitoring, and zero connection to your governance framework. It’s not a bug. It’s a default. And it’s one of the most quietly dangerous misconfigurations in the Microsoft identity ecosystem.

Why This Persists

Microsoft designed this default to reduce friction for developers and small teams who need test environments quickly. In practice, most organizations never revisit this setting during initial tenant hardening because it lives in an obscure corner of the Entra admin center under “User settings.” Security teams focus on Conditional Access, MFA rollout, and app consent policies, the defaults around tenant and object creation simply don’t make the radar.

Real-World Risks

Shadow Identity Infrastructure

When a user creates a rogue tenant, they stand up an entirely separate identity platform outside your organization’s visibility. This shadow tenant can issue tokens, host applications, and authenticate users, all beyond the reach of your SIEM, your Conditional Access policies, and your security team. As Microsoft’s own security guidance warns, a rogue tenant can be exploited for token issuance, brand impersonation, consent phishing, or persistent staging infrastructure. Your traditional defenses are blind to it.

Consent Phishing and Brand Impersonation

An attacker who compromises a regular user account can create a new tenant, register a multi-tenant OAuth application with a convincing name, and use it to launch consent phishing campaigns against your employees or partners. Because the application originates from what appears to be a legitimate Microsoft tenant, it carries an air of credibility that a random external app wouldn’t.

Privilege Escalation via Guest-Created Subscriptions

This is where things get especially dangerous. BeyondTrust researchers demonstrated in 2025 that guest users, and by extension any user who creates a new tenant, can exploit billing permissions to create Azure subscriptions inside a target tenant and become the Owner. From there, attackers can enumerate privileged admin accounts, disable Azure security policies to silence alerts, create persistent managed identities that survive even after the guest account is removed, and register devices that bypass Conditional Access. This isn’t theoretical, BeyondTrust confirmed they’ve observed this technique being actively exploited in the wild.

AI-Powered Reconnaissance at Scale

Rogue tenants created by compromised accounts provide a clean staging ground for automated reconnaissance. With the explosion of AI-assisted attack tooling, an adversary can use a shadow tenant to systematically probe your organization’s app registrations, enumerate users via Graph API, and map out trust relationships, all from infrastructure you don’t even know exists.

Case Studies

Microsoft / Midnight Blizzard (January 2024)

Russian state-sponsored group APT29 compromised a legacy, non-production test tenant account at Microsoft that lacked MFA. From this forgotten tenant, the attackers pivoted to Microsoft’s corporate environment through a legacy OAuth application with elevated permissions, ultimately exfiltrating emails from senior leadership, cybersecurity, and legal teams. The breach went undetected for approximately two months. Microsoft later reported that attack volume increased tenfold in February 2024 as the group attempted to leverage exfiltrated secrets.

Impact: Corporate email compromise affecting executive leadership and U.S. federal agencies; source code repositories accessed.

Reference: Microsoft MSRC Blog, January 2024

Microsoft Secure Future Initiative, 6.3 Million Dormant Tenants Purged (2025)

As part of its post-breach remediation, Microsoft revealed it had purged 6.3 million dormant Azure tenants to reduce its attack surface. These orphaned tenants, many likely created by non-admin users and subsequently abandoned, represented exactly the kind of unmonitored identity infrastructure that adversaries exploit. The sheer number underscores how widespread the problem of tenant sprawl has become, even inside Microsoft itself.

Impact: Massive reduction in shadow identity attack surface; highlighted systemic governance failure.

Reference: SecurityWeek, April 2025

Consequences

• Regulatory exposure. Shadow tenants processing company data fall outside your data governance controls, creating potential GDPR, HIPAA, or SOX violations you don’t even know about until an auditor or regulator finds them first.
• Uncontrolled blast radius. A compromised user who creates a rogue tenant has established a persistent foothold your incident response team won’t find in your primary tenant’s logs, extending dwell time and complicating containment.
• Supply-chain risk amplification. Rogue tenants hosting OAuth applications can be used to target partners and customers through consent phishing, turning your organization into an unwitting launchpad for downstream attacks.
• Reputational damage. When a breach traces back to shadow infrastructure your security team didn’t know existed, the narrative becomes one of negligence, not sophistication.
• IP and data exfiltration. Users can move sensitive data into unmonitored tenants, whether through ignorance or intent, creating exfiltration channels that bypass DLP and CASB controls entirely.

Best Practices for Prevention

1. Restrict tenant creation immediately. In the Entra admin center, navigate to Users > User settings > Default user role permissions and set “Restrict non-admin users from creating tenants” to Yes. Alternatively, enforce this via PowerShell: Update-MgPolicyAuthorizationPolicy -DefaultUserRolePermissions @{AllowedToCreateTenants = $false}. This is a five-minute fix with zero operational impact for 99% of organizations.
2. Lock down app registration and security group creation in parallel. Tenant creation is one of three overly permissive defaults in Entra ID’s user role permissions. While you’re there, set “Users can register applications” and “Users can create security groups” to No as well. Assign the Application Developer and Groups Administrator roles to specific users who need them.
3. Restrict subscription transfers. Configure Azure Subscription Policies to block guests and unauthorized users from transferring subscriptions into your tenant. This closes the privilege escalation path BeyondTrust documented. This setting is off by default, you must opt in.
4. Monitor tenant creation events in audit logs. Set up alerts for the Create Company operation under DirectoryManagement in your Entra ID audit logs. Forward these to your SIEM and treat any unexpected tenant creation as a high-priority investigation trigger.
5. Enforce these settings with automation. Defaults can drift. Use an Azure Automation runbook or a policy-as-code framework to periodically verify that AllowedToCreateTenants, AllowedToCreateApps, and AllowedToCreateSecurityGroups remain set to false. Detect configuration regression before it becomes an exposure.

A default is not a recommendation, it’s a liability waiting to be discovered. In identity security, every unmonitored tenant is an unlocked door with no camera, no alarm, and no one checking who walks through. Reclaim the perimeter you didn’t know you’d lost.