Overview
In the Azure cloud, identity is the primary security perimeter. Microsoft Entra ID serves as the central control plane for managing this perimeter, but a default setting within it exposes organizations to significant governance gaps and financial risks. By default, any non-administrative user in an Azure environment can create an entirely new, independent tenant.
When a user creates a tenant, they are instantly granted the Global Administrator role within that new environment. This action creates a parallel infrastructure that exists outside the organization’s primary security boundary. This “shadow tenant” bypasses all established security policies, monitoring tools, and compliance controls, creating a critical blind spot for FinOps and security teams.
Restricting this capability is a fundamental step toward mature cloud governance. It ensures that the creation of new identity boundaries is a deliberate and managed process, not an accidental byproduct of user activity. This simple configuration change is a high-impact measure to prevent shadow IT, control costs, and maintain a consistent security posture across your entire cloud estate.
Why It Matters for FinOps
Allowing uncontrolled tenant creation introduces tangible risks that directly impact the business. From a FinOps perspective, the consequences extend beyond security vulnerabilities to affect financial stability, operational efficiency, and regulatory compliance.
Unmanaged tenants are the primary entry point for shadow IT, where resources are provisioned without visibility or oversight. This leads to unbudgeted cloud spend on virtual machines, storage, or premium licenses that are invisible to cost management tools until the invoice arrives. These orphaned resources often persist long after an employee leaves, accumulating costs without delivering any business value.
Operationally, this practice creates fragmented, siloed environments that are difficult to manage and secure. It introduces significant technical debt, as these shadow tenants may eventually need a complex and expensive migration back into the corporate fold. Furthermore, if sensitive data is moved into an unmanaged tenant, it falls outside the scope of corporate data protection policies, exposing the organization to severe legal and financial penalties under regulations like GDPR and HIPAA.
What Counts as “Idle” in This Article
In the context of tenant creation, the concept of “waste” or being “idle” moves beyond resource utilization to represent a governance failure. An unmanaged tenant is a form of governance waste—an asset that exists outside of established financial, security, and operational controls, posing a dormant but significant risk.
We define an “unmanaged tenant” as any Microsoft Entra ID instance created by a non-administrative user that is not formally onboarded into the organization’s central management and billing systems. Signals of this activity include audit log entries for tenant creation initiated by standard user accounts or the discovery of tenants associated with corporate email domains that are not linked to the primary enterprise agreement.
Common Scenarios
Understanding why users create tenants is key to implementing effective guardrails without hindering productivity.
Scenario 1
A developer needs an environment with Global Administrator privileges to test an application’s permission grants or infrastructure-as-code scripts. To avoid internal processes, they create their own tenant, inadvertently isolating their work and potentially exposing proprietary code in an unhardened environment.
Scenario 2
A marketing team member signs up for a free trial of a new SaaS tool using their corporate credentials. The signup process requires an identity directory they control, which can inadvertently trigger the creation of a new, unmanaged “viral” tenant to support the application, creating a new vector for data to leave the corporate environment.
Scenario 3
An employee follows an online tutorial to learn Azure, and the instructions direct them to create a new tenant for the exercises. While the intent is harmless, this action results in another abandoned tenant associated with the company’s domain, contributing to infrastructure sprawl and governance complexity.
Risks and Trade-offs
The primary trade-off in restricting tenant creation is balancing developer agility against centralized security and cost control. While enabling this feature by default may seem to reduce friction for technical teams, the risks of data exfiltration, cost overruns, and compliance breaches far outweigh the perceived benefits of convenience.
Failing to restrict this capability means accepting the risk of shadow IT, where unmonitored resources accrue costs and security policies are nonexistent. The proper approach is not to block innovation but to channel it through a managed process. By providing secure, sandboxed subscriptions within the main corporate tenant or implementing a formal approval workflow for new tenants, organizations can empower developers without sacrificing governance.
Recommended Guardrails
Implementing effective governance requires more than just a single configuration change. It involves establishing a clear set of policies and automated controls.
- Policy Enforcement: Formally document a policy that designates tenant creation as a privileged operation requiring explicit approval.
- Ownership and Approval: Establish a clear process for requesting a new tenant, with defined owners responsible for reviewing the business justification and ensuring security compliance.
- Least Privilege Access: For the few users who require this capability, use the designated “Tenant Creator” role instead of granting broader administrative rights.
- Budgeting and Cost Allocation: Ensure any approved new tenant is immediately integrated into the organization’s cost management and showback/chargeback systems.
- Automated Alerting: Configure alerts to trigger on any tenant creation activity—successful or failed—to ensure immediate visibility for the security and FinOps teams.
Provider Notes
Azure
The core of this governance control lies within Microsoft Entra ID, which acts as the identity service for Azure. The key is to modify the default user settings to prohibit non-administrative users from creating new tenants. For legitimate use cases where tenant creation is required, Azure provides the specific Tenant Creator role. Assigning this role allows organizations to follow the principle of least privilege, granting the capability only to authorized users without weakening the global security posture.
Binadox Operational Playbook
Binadox Insight: A permissive tenant creation policy is one of the most common gateways to shadow IT and uncontrolled cloud spend. This seemingly minor setting has major financial and security implications, making its restriction a foundational element of effective FinOps governance in Azure.
Binadox Checklist:
- Audit your Microsoft Entra ID user settings to verify the current tenant creation policy.
- Review historical audit logs for any past tenant creation events initiated by non-admins.
- Set the “Restrict non-admin users from creating tenants” setting to “Yes”.
- Establish and communicate a formal request and approval process for legitimate tenant creation needs.
- Identify users with a valid business need and assign them the specific “Tenant Creator” role.
- Configure alerts in Azure Monitor to notify security and FinOps teams of any tenant creation activity.
Binadox KPIs to Track:
- Number of unauthorized or shadow tenants discovered per quarter.
- Mean-time-to-remediate (disable or onboard) a newly discovered shadow tenant.
- Volume of legitimate tenant creation requests processed through the official channel.
- Percentage of cloud spend attributed to unmanaged or untracked tenants.
Binadox Common Pitfalls:
- Failing to communicate the policy change to development and engineering teams.
- Not providing a viable and efficient alternative, such as managed sandbox subscriptions.
- Overlooking the need to monitor for failed creation attempts, which can signal policy confusion or bypass attempts.
- Granting the “Tenant Creator” role too broadly, defeating the purpose of the restriction.
Conclusion
Controlling tenant creation is not about restricting innovation; it is about ensuring that all infrastructure exists within a managed, secure, and financially visible framework. By disabling this default capability in Azure, organizations take a critical step toward eliminating shadow IT and enforcing robust FinOps governance.
The path forward is clear: audit your current configuration, implement the restriction, and establish a formal process for exceptions. This simple yet powerful action closes a significant governance loophole, strengthens your security posture, and ensures that your cloud environment scales in a controlled and cost-effective manner.
7-day free trial