Microsoft Entra Tenant Governance Is GA: What Changed and How to Use It

I wrote earlier about the multi-tenant security story in Entra, and that post started from one hard truth: most enterprises run far more tenants than central IT can safely track by hand. Now that Microsoft Entra Tenant Governance is generally available, that problem has a much cleaner control model than custom scripts and spreadsheet inventory.

If you want context first, read my earlier post Entra Tenant Governance: Securing Multi-Tenant Environments at Scale. This new post is the GA-focused update: what is now stable, what still sits in preview, and how to roll it out without causing governance noise.

My short version: Tenant Governance is not a replacement for identity lifecycle management, Conditional Access, Privileged Identity Management, or backup. It is a control plane that helps you find tenants, establish an accountable administrative relationship, and detect when important configuration moves away from an approved baseline. That distinction matters, because the value comes from operating it as part of your identity governance program, not from enabling one more blade in the portal.

What GA means here

From the August 2026 Microsoft Entra announcement, Tenant Governance is now positioned as a built-in capability to discover and govern multi-tenant estates at scale. The model stays centered on four capability areas:

Related tenants discovery
Governance relationships for delegated admin
Tenant configuration management and drift visibility
Secure tenant creation

What matters in real life is not the marketing summary, it is the split between stable control paths and still-moving admin experiences.

The control-plane mental model

I would describe Tenant Governance as three layers:

Visibility layer: related tenant discovery uses observable signals such as B2B collaboration, multitenant application activity, and shared billing relationships to build an inventory of tenants that interact with your organization.
Relationship layer: governance relationships define which tenant governs which other tenant, and what delegated administration or application provisioning is introduced through a policy template.
Configuration layer: snapshots, baselines, monitors, and drift reports help you compare current configuration against the state you decided was acceptable.

The most important design choice is to keep those layers separate in your operating model. Discovery tells you that a relationship probably exists. It does not prove business ownership. A governance relationship gives you an administrative path. It does not automatically mean every delegated role is appropriate. Drift monitoring shows change. It does not decide whether the change was malicious, emergency-driven, or an approved exception that never made it back into the baseline.

What is stable now, and what is still moving

Area	Current status	Operational note
Configuration management APIs (snapshot, baseline, monitor, drift)	Tenant Governance capability is GA; Graph Tenant Governance documentation is still under beta at the time of writing	Use for repeatable operations, but wrap beta API calls with version checks, error handling, and change monitoring
Related tenants + governance relationship model	Generally available capability	Treat discovery as visibility, not automatic ownership proof
New monitor-from-snapshot admin portal experience	Preview	Useful UX improvement, but keep runbooks API-first
Multi-tenant agent management in Microsoft Agent 365	Preview integration path	Strong for SOC centralization, but validate role boundaries carefully

Important: Enabling related tenant discovery is a one-way action in the admin model. Plan ownership and triage workflows before you switch it on in production.

What changed technically

The real change is that Tenant Governance now gives Microsoft-first primitives for a problem that many organizations previously solved with a mix of partner tooling, export scripts, privileged accounts, and manual tenant inventories. The primitives are useful because they map to real operational questions:

Which tenants are connected to us? Related tenants gives you an inventory based on observable relationships, not only what a CMDB says exists.
Who is allowed to administer a tenant? Governance relationships give you a directional governing tenant and governed tenant model instead of unmanaged standing admin accounts scattered across directories.
Which permissions and applications should appear when a relationship is accepted? Governance policy templates let you define delegated roles and optional multitenant app provisioning up front.
Which important settings changed? Configuration monitors compare actual resource state with a baseline and produce drift results for investigation or remediation.
How do we create a new tenant without losing control on day zero? Secure tenant creation can establish the governance relationship as part of tenant creation when the billing and role prerequisites are met.

That moves the architecture from "central IT periodically asks everyone what tenants exist" to "central IT has a governed inventory, delegated access path, and drift detection loop." It is a small sentence, but it is a large operating-model shift.

Microsoft Graph API reality

There is an easy trap here: GA product announcement does not automatically mean every programmable surface is a v1.0 Microsoft Graph API. Microsoft Learn currently documents the Tenant Governance Graph namespace as microsoft.graph.tenantGovernanceServices under the /beta endpoint. The docs are explicit that beta APIs can change and are not supported for production applications in the same way as v1.0.

That does not make the APIs useless. It just changes how I would use them:

Keep portal-backed runbooks for human approval and recovery paths.
Use automation first for inventory export, reporting, and preflight validation.
Gate relationship creation and acceptance behind change tickets or approval workflows.
Pin SDK usage to the beta Graph SDK profile intentionally; do not let engineers assume the default v1.0 SDK surface contains the same resource types.
Add smoke tests for the exact endpoints you use, because beta shape changes can break unattended jobs quietly.

The API areas to watch are related tenants, governance relationships, governance requests, governance invitations, policy templates, and tenant governance settings. In practice, I would start with read and report workflows, then add write operations only after the team has agreed on approval, rollback, and ownership processes.

Licensing reality check

This is where projects either move quickly or stall. The useful split from Microsoft Learn is:

Configuration monitoring and snapshot baseline capacity: available with Tenant Governance Basic capacity in Entra P1/P2 boundaries, with added scale through Entra ID Governance licenses.
Related tenants discovery: requires Entra ID Governance licensing for admins who use the feature.
Governance relationships using GDAP-style delegated administration: available with Entra P1/P2/ID Governance in the governing tenant.
Custom multitenant app injection through governance templates: requires Entra ID Governance.
Secure tenant creation: available for paid cloud customers with the required subscription and role prerequisites.

Also, license calculation is admin-centric for these controls. You are licensing administrators who operate Tenant Governance capability, not every end user in every governed tenant.

The configuration management capacity numbers are also worth reading literally. Entra P1 and P2 include basic configuration monitoring and snapshot capacity. Microsoft Learn describes this as up to 30 monitors and 800 configuration resources per tenant per day for drift reporting, and up to 20,000 configuration resources per tenant per month with 12 active snapshot jobs for snapshots. Entra ID Governance adds more capacity per licensed administrator. This means a small but careful monitoring scope can be covered by existing P1/P2 licensing, while large-scale full-tenant baseline programs need sizing.

My planning rule is simple: do not start by licensing for "everything." Start by counting the configuration resources that create the most tenant risk:

Conditional Access policies and named locations
Authentication methods policy and password protection settings
Privileged role settings and role assignment patterns
Cross-tenant access settings
Application consent and enterprise application posture
Break-glass account controls and exclusion patterns

When that set is stable, extend the baseline. If you begin with low-risk noise, drift monitoring looks noisy before it has earned trust.

A rollout sequence that works

If you have a large tenant estate, do this in five clean phases. This aligns with Microsoft deployment guidance and avoids chaotic first-week outcomes.

Prerequisites and role model: confirm Tenant Governance Administrator ownership, plus the service-specific permissions needed for configuration resources.
Discovery first: enable related tenants and classify outcomes as known, needs governance, or risky.
Template next: create governance policy templates before any relationship handshakes so every relationship starts with a repeatable model.
Relationship handshake: use two-step flows where shared billing exists, three-step invitation/request/accept flows where it does not.
Drift program: start with high-impact resources, then expand monitor scope once false positives are under control.

Phase detail I would add to the runbook

The five phases are easy to list, but the quality comes from the controls around them.

1. Prerequisites and roles

Create a small operating group before enabling anything. At minimum, include identity operations, security operations, compliance or risk, and the tenant owner group for known subsidiaries, acquisitions, development tenants, and regional tenants. Confirm who can hold the Tenant Governance Administrator role, who can grant configuration management permissions, and who can accept requests from the governed tenant side.

I would avoid assigning broad roles directly to people. Put delegated administration behind groups, require Privileged Identity Management activation where possible, and document which roles are allowed in each template. The governing tenant becomes a control plane, so its own privileged access model needs to be cleaner than the tenants it governs.

2. Discovery and classification

Related tenant discovery is powerful, but it is not a magic ownership engine. B2B activity may point to a partner or customer. Multitenant app activity may point to normal SaaS usage. Shared billing is a strong signal, but even that still needs business context. Treat the first output as an investigation queue.

A useful triage model is:

Known and acceptable: documented partner, customer, subsidiary, or test tenant. Record the owner and decide whether governance is needed.
Needs governance: tenant appears internal, has ongoing usage, or carries shared billing/application signals but no clear central control.
Risky or unknown: no owner, unexpected activity, suspicious app consent pattern, or signs of dormant shadow IT that still has access paths into your production tenant.

Do not measure success by how many relationships you create in week one. Measure success by how many tenants get classified with an owner, purpose, risk rating, and next action.

3. Governance policy templates

Policy templates are where you should be most conservative. A template can include delegated administration through cross-tenant GDAP and, when licensed, custom multitenant application injection. That is useful, but it also means a bad template can replicate unnecessary privilege across many tenants.

I prefer separate templates for different operating patterns:

Observe: read-heavy roles for inventory, posture review, and drift investigation.
Operate: narrowly scoped service administration for tenants under active central operations.
Recover: emergency-only role set with PIM activation, approval, and short assignment windows.
Build: controlled provisioning pattern for new governed tenants created by the organization.

Version templates like code. Keep a changelog, define an owner, and remember that template changes do not automatically modify existing governance relationships. If you change the intended permissions, plan a new request and acceptance flow.

4. Relationship handshake

Governance relationship setup is intentionally a handshake. Related tenants with a shared billing signal can use a shorter two-step flow: the governing tenant sends the governance request, and the governed tenant accepts it. Tenants without a shared billing signal use an invitation/request/accept pattern so that both sides explicitly participate.

Use the handshake as a governance checkpoint. The governed tenant should review the template, role assignments, and application provisioning before acceptance. The governing tenant should record why the relationship exists and what exit criteria would terminate it.

5. Configuration monitoring and drift response

Configuration monitoring is where Tenant Governance becomes operational instead of architectural. Start with a known-good snapshot, convert it into a baseline, create a monitor, and then treat drift as a queue for decision-making. The decision is usually one of three outcomes:

Unauthorized drift: restore the approved configuration and investigate who made the change.
Approved emergency change: keep the change, update the baseline, and attach the approval record.
Bad baseline: fix the baseline because the monitor is faithfully reporting a difference that the organization now accepts.

The unhealthy pattern is to suppress alerts until the dashboard looks clean. The healthy pattern is to reduce drift classes by improving change management, baseline design, and ownership.

A practical GA rollout pattern for Microsoft Entra Tenant Governance.

How I would design the first baseline

Do not baseline the whole tenant first just because the tooling can see a lot. A baseline is a security promise, not an export file. If the team cannot explain why a setting belongs in the baseline, who owns it, and what to do when it drifts, the monitor will create work without improving control.

For the first baseline, I would use four rings:

Ring	What to include	Why it matters
Ring 0	Break-glass accounts, emergency access exclusions, privileged role settings, tenant-wide security defaults or CA dependencies	Changes here can decide whether you can recover during an incident
Ring 1	Conditional Access, authentication methods, cross-tenant access, external collaboration settings	These settings directly shape who can sign in and from where
Ring 2	Application consent posture, enterprise app assignments, admin consent workflow, app management settings	App drift is a common path to over-privileged access
Ring 3	Service-specific governance controls across Intune, Exchange, Teams, SharePoint, Defender, and Purview where supported	This expands from identity control to tenant posture consistency

The first monitor should be boring on purpose. Choose a scope small enough that every drift item gets reviewed during the first month. Once the team proves it can classify and close drift, expand the monitor or create additional monitors by service area.

Implementation notes for architects

Use a governing tenant tiering model. The tenant doing the governing should have strict privileged access, strong break-glass hygiene, and alerting on role changes. Do not centralize weak administration.
Separate discovery from enforcement. Discovery output should feed an ownership workflow. Governance relationship requests should follow only after the tenant is classified.
Keep delegated roles narrow. The goal is centralized control, not a new set of permanent global administrators.
Document template intent. A template named "standard" is not enough. Record the role set, target tenant type, owner, approval requirement, and review cycle.
Monitor the monitor. Track drift volume, time to classification, time to remediation, accepted exceptions, and repeated drift by owner or service area.
Plan relationship exit. Mergers, divestitures, partner relationships, and test tenants all end eventually. Define who can terminate a governance relationship and what cleanup is required.

Common mistakes to avoid

Turning on discovery without a triage queue. You will get visibility before you get answers. Assign people to work the queue.
Using one template for every tenant. Subsidiary, lab, acquisition, partner, and regulated tenants rarely need the same delegated role pattern.
Confusing drift with compromise. Drift is a change signal. It needs context from audit logs, change records, and owner review.
Ignoring baseline debt. If the baseline does not reflect approved architecture, every monitor result becomes an argument.
Building brittle beta API automation. Until the Graph surface you use is v1.0, treat automation as controlled engineering work with tests and change monitoring.

What good looks like after 90 days

After the first quarter, I would expect these outcomes:

Every discovered tenant has an owner, classification, and documented next action.
Governance relationships exist only where there is a business reason and accepted delegated role model.
Templates are versioned, reviewed, and mapped to tenant categories.
High-impact configuration drift is reviewed on a predictable cadence.
Accepted exceptions are added back to the baseline instead of living in chat messages.
Security operations knows which drift types should become incidents and which belong to normal change management.

How this connects to my earlier posts

This GA update ties directly into three earlier threads I covered:

Entra Tenant Governance: Securing Multi-Tenant Environments at Scale - the early framing and risk model.
Entra ID Governance Walkthrough Part 1 - lifecycle governance mindset that now extends across tenants.
Microsoft Agent 365 GA licensing post - useful when you plan cross-tenant agent governance integration.

One more operational link: if your cross-tenant admin model already depends on controlled elevation and timed access, the patterns from SCIMming with PIM for Groups still apply very well to who can touch governed tenants and for how long.

Public resources worth bookmarking

Final take

This GA release is not just another admin blade update. It gives identity and security teams a practical way to move from tenant-by-tenant firefighting to an estate-level control model. The value is strongest when you combine discovery, least-privilege cross-tenant administration, and drift baselines into one operating rhythm.

If your organization is still managing extra tenants with local admin accounts and ad hoc scripts, this is a good time to reset the model.