Microsoft Entra Tenant Governance: Finding the Tenants You Don’t Know You Have

Run tenant discovery against a mature Microsoft 365 environment and the first surprise is the count. In one tenant we reviewed, discovery returned roughly 50 related tenants, and most of them were not acquisitions or forgotten test environments. They were software vendors: the ticketing system, the scheduling tool, the migration utility, every provider whose multitenant application someone had consented to over the years. None of them appeared on any inventory, because no inventory existed.

Microsoft Entra Tenant Governance is Microsoft’s first-party answer to that blind spot, and it is generally available as of September 2026. It is four capabilities behind one page in the Microsoft Entra admin center: related tenant discovery, governance relationships that grant cross-tenant administrative access without local accounts, configuration management that watches tenants for drift against a JSON baseline, and secure tenant creation that governs a new tenant from the moment it exists. The capabilities carry different licensing, and the one most organizations want is the one that costs the most.

Why Your Organization Has More Entra Tenants Than You Think

Tenant sprawl is the normal end state of a decade of Microsoft cloud adoption, not a sign that something went wrong. Microsoft states the case plainly in its documentation: “Modern organizations rarely operate within a single Microsoft Entra tenant. Mergers, acquisitions, divestitures, geographic expansion, developer experimentation, and decentralized IT models have led to tenant sprawl.”

Each of those produces tenants through a different door. An acquisition arrives with a tenant already populated and already configured to someone else’s standards, and a regulated workload gets partitioned into its own tenant deliberately.

Developer sprawl is the quiet one. A team of 500 people can produce hundreds of tenants without one of them passing through a provisioning process, because creating a tenant is a self-service action that needs no budget approval and no ticket. And somewhere in most organizations there is a proof of concept that went up on a corporate card and never came down.

The organizational problem is not the count. It is that central IT usually cannot name the tenants, which means it cannot say whether any of them enforce multifactor authentication, restrict user consent, or retain audit logs. Every one of those tenants holds identities, and identities that your organization does not govern are still identities that your name is attached to. The Entra ID settings we review first in every tenant are worth nothing in the tenants you have never opened.

What Microsoft Entra Tenant Governance Actually Does

Tenant Governance is four products sharing a blade, and separating them is the first step to evaluating it. Related tenants is the discovery layer: it detects tenants that interact with yours and tells you what evidence establishes each connection. Governance relationships are the administrative layer: invitation and approval workflows that give administrators in a governing tenant least-privilege access to a governed tenant without a local account or a guest account in it.

Configuration management is the monitoring layer, and it is the broadest of the four. Microsoft documents support for over 200 types of resources across six services: Entra, Intune, Exchange Online, Teams, Purview, and Defender. You express a desired state as JSON, and a monitor compares the live tenant against it on a schedule.

Secure tenant creation is the prevention layer. It creates a new tenant with a governance relationship already established, so the next tenant your organization produces is governed from birth rather than discovered two years later.

Those four solve different problems, and an organization with one merger behind it and no development teams has a different case for this product than a software company with a dozen environments. Decide which layer you actually need before reading the price list, because the licensing does not treat them equally.

How Related Tenant Discovery Finds Tenants You Didn’t Know About

Related tenant discovery works from three signals, all of them derived from activity that already exists in your environment. B2B collaboration signals identify tenants through guest registrations and cross-tenant sign-in activity. Multitenant application signals surface tenants whose registered applications have permissions in your tenant, and tenants where your own applications have access. Shared billing account signals identify tenants that sit under a billing account with yours.

The most important thing to understand about the output is what it is not. Microsoft is direct about this: “The related tenants feature isn’t an authoritative inventory of tenants an organization owns.” It is an inventory of tenants your organization touches.

That distinction is why a discovery run returns dozens of software vendors alongside the two tenants you were looking for, and why the result needs triage rather than acceptance. Microsoft’s guidance sorts each discovered tenant into three categories: known and acceptable, requires governance, and potentially risky, with a quarantine path for the last of those.

Discovery also surfaces tenants that belong to Microsoft rather than to anyone in your supply chain, and flags them as Microsoft managed so you can filter them out. That flag earns its place. In one tenant, an unfamiliar Microsoft-managed tenant turned out to be identifiable only by opening its inbound application signals, which showed the Windows Virtual Desktop client applications that indicate where Cloud PCs are hosted. Without the flag, that entry reads as an unexplained foreign tenant with sign-in activity.

Two operational details matter before anyone clicks the button. Discovery is not instant: signals aggregate after you enable the feature, and the data takes days rather than minutes to populate. More importantly, enabling tenant discovery is permanent. Microsoft’s documentation states that after you enable it, the setting cannot be reversed. This is a decision to make deliberately, not a button to press while exploring the portal.

How Configuration Snapshots and Drift Monitoring Work

Configuration management answers a different question. Discovery tells you which tenants exist; monitoring tells you whether the ones you administer still match what you approved. You author a baseline as JSON that expresses the desired state of tenant resources, create a monitor that compares the live configuration against it, and review the properties that differ. Each monitor runs every six hours, and results from the first run can take that full interval to appear.

Two limits shape how much you can cover. Each baseline holds up to 200 resource instances, and the daily ceiling is 800 resource instances across all monitors in the tenant. Snapshots, which capture current state rather than compare against a desired one, run on a separate allowance of 20,000 resources per tenant per month with 12 active snapshot jobs. A snapshot taken from a known good tenant is the practical way to start a baseline, because authoring 200 resource definitions by hand is work nobody needs to do twice.

Setting up permissions is where this takes real time, and it is worth budgeting for. The configuration management service reads tenant configuration under its own explicit grants, in this order:

1. Sign in to the Microsoft Entra admin center as a Global Administrator or Privileged Role Administrator and open Tenant governance then Configuration management permissions.
2. Add the Microsoft Graph application permissions for each resource type you want to monitor, such as Policy.Read.All for Conditional Access policies.
3. Assign the Entra roles that specific resources require, such as Teams Reader for Teams resources.
4. Grant Exchange, Security, and Compliance permissions separately in those services’ own admin centers.
5. Author the baseline, validate it, and create the monitor.

Expect friction at step 2. The portal presents these as individual checkboxes with no select-all, which turns a complete grant into a thirty to forty-five minute exercise of clicking one permission at a time. Expect friction after it as well: even with a permissions health check reporting green, first runs commonly return some resource types partially successful and others failed, and the gaps have to be chased individually. Plan this as a configuration project with a second pass built in, not as a switch you flip on a Friday afternoon.

One more caution on maturity. Tenant Governance as a whole reached general availability, but individual capabilities inside it still appear with preview labels in the portal depending on the tenant, snapshots among them. Check what carries a preview label in your own tenant before you build a compliance process on top of it.

What Secure Tenant Creation Requires

Secure tenant creation produces a new tenant with a governance relationship already in place, a policy template applied, a Microsoft Entra ID Free billing asset provisioned in an Azure subscription you choose, and the tenant added to your related tenants inventory. Microsoft documents the full flow as the last phase of its end to end deployment guide. The value is preventive: the tenant never spends a period ungoverned.

The prerequisites are more about Azure than about identity. You need a paid Enterprise Agreement or Pay-As-You-Go subscription, with both Microsoft Online Subscription Agreement and Microsoft Customer Agreement billing accounts supported, plus Azure Resource Manager permissions through the Tenant Contributor or Subscription Owner and Creator role. Organizations running only a free tenant or a trial subscription cannot create tenants this way at all.

One detail causes a failure that looks like a success. The feature applies a governance policy template whose ID is literally default, and if no default template exists, the tenant is still created but no governance relationship is established. Nothing errors. You get a new tenant that is exactly as ungoverned as the ones you deployed this product to find. Create the default template before anyone uses the governed workforce option, not after.

What Tenant Governance Costs

Licensing applies to the administrators who use these capabilities, not to every user in the tenant, which keeps the cost far lower than a per-seat reading suggests. The capabilities land across tiers as follows:

Read the last row carefully, because it is the one that decides most budgets. Related tenant discovery, the capability that answers “which tenants do we even have,” requires Microsoft Entra ID Governance. Everything else of substance is reachable from licensing you almost certainly own: Entra P1 is included in Microsoft 365 E3 and Business Premium, and Entra P2 is included in Microsoft 365 E5.

That produces a clear starting point. Configuration monitoring gives the best return for no additional spend, so baseline and monitor the tenant you already administer first, prioritizing authentication methods, Conditional Access policies, and role settings.

If you then need discovery, license only the administrators who will use it. One administrator enables discovery for the tenant, and after that every administrator who views results, triggers a refresh, or acts on a signal needs a license of their own. Microsoft Entra ID Governance also arrives inside Microsoft Entra Suite and Microsoft 365 E7, so organizations already weighing whether the E7 frontier suite is worth it should count this among what the SKU includes.

Key Takeaways

• Related tenant discovery reports the tenants your organization interacts with, not the tenants it owns, so a first run returning dozens of software vendors is the feature working correctly.
• Enabling tenant discovery is permanent and cannot be reversed, and the data takes days to populate.
• Configuration monitoring is included with Entra P1 and P2, covering 30 monitors and 800 resources per tenant per day. Related tenant discovery requires Microsoft Entra ID Governance.
• Secure tenant creation silently skips the governance relationship when no policy template with the ID default exists.

Frequently Asked Questions

Do governed tenants need their own Tenant Governance licenses?

No. Licenses are required only in the governing tenant. When a service provider establishes a governance relationship with a customer, only the administrators in the provider’s tenant who configure the relationship need licenses, and the number of relationships does not change the license count.

How long do governance requests and invitations stay valid?

A governance request sent from a governing tenant is valid for 14 days. When no shared billing account exists between the two tenants, the governed tenant starts the process with an invitation instead, and that invitation is valid for 30 days.

Which administrative roles are required?

Tenant Governance tasks require the Tenant Governance Administrator or Global Administrator role. Configuration management requires Global Administrator or Privileged Role Administrator, because granting the underlying Microsoft Graph application permissions is a privileged operation.

Conclusion

The honest assessment of Microsoft Entra Tenant Governance is that the discovery half answers a question most organizations cannot answer today, and the configuration half is available right now at no additional licensing cost.

Start with a configuration baseline on the tenant you already administer, because that is where the return arrives fastest. Treat discovery as a deliberate decision, given that enabling it cannot be undone. If you want help building that first baseline, or an inventory of the tenants carrying your organization’s identities, our project work covers exactly this kind of assessment, so reach out and let’s talk.