The difference is more than calendar trivia. Microsoft did not publish the kind of prominent GA announcement that normally accompanies a new Entra security service, and its rolling “What’s new” page still carries older entries that label major Tenant Governance components as public preview. Administrators looking only at release notes could reasonably conclude that Tenant Governance relationships, related-tenant discovery, the admin portal, and secure add-on tenant creation remain previews. Microsoft’s current Learn documentation and its public documentation repository say otherwise: the preview labels and prerelease notices were removed across 26 Tenant Governance documents for GA.
For IT teams, the practical news is real. Tenant Governance now moves the discovery, cross-tenant administration, baseline monitoring, and governed-tenant creation workflow out of the preview bucket. The more important conclusion is that it should be deployed as an inventory and assurance project—not treated as a switch that magically secures every Microsoft 365 tenant connected to the business.
Microsoft’s GA record is in the documentation, not a launch post
Microsoft’s public GitHub repository for Entra documentation contains the clearest GA record. A July 27 commit is titled “Remove ‘preview’ tags from Entra Tenant Governance Learn article for GA,” and its change description says Tenant Governance would go generally available on August 3. The commit removed preview qualifiers from the Tenant Governance overview, related-tenants material, governance relationships, delegated administration, configuration management, secure tenant creation, deployment guidance, FAQ, and licensing section.
Microsoft Learn now presents the product simply as “Microsoft Entra Tenant Governance,” rather than “Microsoft Entra Tenant Governance (preview).” Its landing page describes the service as a way to identify related tenants, establish governance relationships, monitor configurations, and create add-on tenants under governance from the outset.
Petri’s reporting accurately identifies the central problem the service is intended to solve: enterprises often accumulate tenants through acquisitions, test environments, regional divisions, partner arrangements, and self-service creation. These tenants can retain B2B connections, app permissions, shared billing relationships, or administrative exposure to an organization’s main tenant long after their original project has ended.
What Petri’s framing leaves unclear is that GA did not introduce an entirely new service on August 11. The capability set had been publicly previewed since March 2026, and Microsoft made the underlying Tenant Configuration Management APIs generally available in April. The August 3 milestone is the point at which the Tenant Governance experience itself—including its portal-driven workflow and related-tenant controls—became generally available.
That distinction matters for customers who delayed deployment because preview status conflicted with their change-control rules. The product is now eligible for a production rollout, but its operating model still carries limits that security teams need to understand before promising complete tenant coverage.
Related tenant discovery finds signals, not ownership
Tenant Governance’s discovery function can identify tenants associated with a governing tenant through three primary signals: B2B activity, multitenant application relationships, and shared billing accounts. Microsoft’s documentation says the B2B signal includes inbound and outbound collaboration, B2B registrations, and B2B administrative access. The application signal surfaces tenants that have registered multitenant applications with permissions in the organization’s tenant, or where the organization’s own multitenant apps have access elsewhere.
This is useful because it turns several scattered identity records into a searchable tenant inventory. A dormant test tenant might not appear on a central IT asset register, but a B2B administrator, enterprise application consent, or billing tie can make it visible. That gives identity teams a starting point for deciding whether the tenant is legitimate, should be governed, or should be isolated using existing cross-tenant controls.
However, discovery is not takeover. Finding a related tenant does not grant the governing tenant administrative authority over it. In the normal setup flow, the tenants must establish a governance relationship through an invitation, request, and approval process. Microsoft allows a shared-billing relationship to skip the invitation stage, but the prospective governed tenant still participates in the request-and-acceptance process.
That is a deliberate security boundary. An organization cannot use Tenant Governance simply to seize administration of every tenant that happens to collaborate with its users. In a real shadow-tenant investigation, the technology can identify the exposure and supply evidence for an escalation; recovery still depends on proving ownership, locating an authorized administrator, or using Microsoft’s tenant-recovery processes where applicable.
Microsoft also documents an architectural limitation that matters in large federated companies: governance relationships can be one-to-many or many-to-one, but not multi-tier. A tenant cannot simultaneously be governed by one tenant and serve as the governing tenant for another. Enterprises with regional identity hubs or layered subsidiaries will need to design around that constraint rather than assume Tenant Governance maps cleanly to every corporate reporting structure.
Delegated administration replaces local admin sprawl
Once a governance relationship is established, Tenant Governance can provide cross-tenant delegated administration using granular delegated admin privileges, or GDAP. Administrators can sign in with accounts from the governing tenant rather than maintaining separate local administrator or B2B guest accounts in every governed tenant.
For sysadmins, that is the operational payoff. A central identity team can use a defined, least-privilege relationship to administer selected functions across a set of managed tenants, reducing the number of standing privileged accounts spread across development, regional, or acquired environments. Microsoft also supports reusable governance policy templates so organizations can request the same permissions repeatedly rather than negotiate an entirely new relationship design for each tenant.
The licensing model makes this less uniform than the marketing suggests. Microsoft’s current licensing table lists cross-tenant GDAP governance relationships under Entra ID P1, Entra ID P2, and Entra ID Governance. The more advanced custom multitenant-app injection capability requires Entra ID Governance. Related-tenant discovery itself is also reserved for Entra ID Governance, even though the basic delegated-administration relationship can be available with P1 or P2.
That split can create a deployment trap. An organization may have Microsoft 365 E3 or Entra ID P1 coverage sufficient to administer a known secondary tenant, but lack the Entra ID Governance licensing needed to discover shadow tenants through the service. Teams should confirm which capability they are buying before treating Tenant Governance as a complete multi-tenant security package.
Baselines detect configuration drift; they do not remediate it
The Tenant Configuration Management feature is the most immediately useful component for Windows and Microsoft 365 administrators. It supports more than 200 resource types across Entra, Intune, Exchange Online, Teams, Microsoft Purview, and Microsoft Defender. Administrators can create JSON configuration snapshots, turn a known-good state into a baseline, and run monitors that compare live settings with the approved state.
Microsoft’s current documentation says monitors run every six hours. A result can show which resource properties differ from the baseline and consolidate drift across one monitor or the tenant’s monitors more broadly. That can expose a Conditional Access setting altered in a lab tenant, an Exchange transport rule changed outside a formal process, or an Intune policy whose settings no longer match the designated reference configuration.
The language around “enforcing baselines” needs care. Tenant Governance provides configuration monitoring and drift reporting. It does not, based on Microsoft’s current documentation, automatically roll a drifted setting back to the approved state. The service identifies the difference; the organization still needs an administrative workflow, delegated permissions, an automation process, or a human change decision to correct it.
That does not make the feature less valuable. It makes it a control that belongs between configuration-as-code and incident response, rather than a replacement for either. A good operating model is to capture an approved production baseline, apply narrower baselines to test or regional tenants where exceptions are legitimate, then route drift results to the team responsible for the workload. Treating every difference as an incident will produce alert fatigue; treating every baseline as universal will break environments designed for distinct legal, operational, or testing purposes.
The service limits also deserve planning. Microsoft lists P1 and P2 capacity at up to 30 monitors and 800 configuration resources per tenant per day, while Entra ID Governance adds capacity based on the number of licenses held. The product’s “over 200” supported resource types should not be read as coverage for every Entra and Microsoft 365 setting, nor as unlimited estate-wide monitoring.
AI and Sentinel claims need a narrower reading
Petri connects Tenant Governance to AI-agent oversight and Microsoft Sentinel integration. Microsoft’s published Tenant Governance materials support the broader idea that identity governance matters for rapidly growing AI and multi-tenant estates, but they do not describe Tenant Governance as an AI-agent management platform.
Microsoft has positioned Entra Agent ID and the broader Agent 365 work as separate capabilities for agent identity, authorization, and governance. Tenant Governance can help an enterprise find and secure the Entra tenants in which AI projects are being developed, particularly where those tenants have B2B, application, or billing ties to the main organization. It does not replace an agent inventory, agent authorization controls, or the governance layer Microsoft is building for agents.
The Sentinel point is similarly overstated. Microsoft’s Tenant Governance configuration documentation names Entra, Intune, Exchange Online, Teams, Purview, and Defender as supported services. It does not list Microsoft Sentinel among the monitored workloads, and Microsoft has not documented a native Tenant Governance-to-Sentinel integration as part of this GA release. Organizations can still feed relevant identity or configuration findings into their SIEM workflows using their own automation and APIs, but that is not the same as a built-in Sentinel governance feature.
The concrete opportunity is to use Tenant Governance now to establish an authoritative tenant register, put legitimate tenants into approved governance relationships, and baseline the configuration surfaces Microsoft actually supports. The August 3 GA release removes preview status from that work; it does not remove the need to decide which tenants belong to the organization, who is accountable for them, and what configuration differences are acceptable.