Microsoft Entra ID Governance: MFA, SSO, Conditional Access, and User Management Guide 2026
Why This Is Happening
If you're reading this, you've probably hit a wall. Maybe your organization has grown through acquisitions and now you're staring at four, seven, or twelve separate Microsoft Entra tenants , each with its own set of admins, policies, and inconsistent security configurations. Or maybe someone in marketing spun up a "shadow IT" tenant three years ago to run a campaign tool, and now it's sitting out there with no MFA enforcement, outdated Conditional Access policies, and zero oversight. I've seen this exact scenario at dozens of enterprise clients, and the frustration is very real.
Here's the thing that makes Microsoft Entra ID Governance setup so painful: the error messages and admin portal warnings almost never tell you why something failed. You get generic permission errors, silent policy mismatches that block SSO without explanation, or MFA prompts that fire even when Conditional Access says they shouldn't. Meanwhile, your helpdesk ticket queue fills up and your users are convinced IT broke something.
The root cause usually falls into one of three buckets. First, tenant fragmentation , your Microsoft Entra ID Governance policies exist in your primary tenant but don't extend to the five other tenants your users are signing into daily. Second, lifecycle gaps, user accounts get provisioned but never properly deprovisioned, so access review reports come back with hundreds of stale accounts that still have active SSO tokens. Third, configuration drift, someone manually changed a Conditional Access policy in a governed tenant six weeks ago, and now it's out of sync with your baseline, silently breaking MFA requirements for an entire department.
Microsoft's own research shows that most large organizations operate Microsoft services in multiple tenants because of mergers and acquisitions, requirements for partitioning security or privacy-sensitive workloads, and test environment separation. Add in user-created tenants that central IT doesn't know about, and you have a governance nightmare that no single admin can see end-to-end.
What makes Microsoft Entra Tenant Governance (currently in preview) different from earlier approaches is that it actually gives you automated discovery. Instead of manually hunting for shadow tenants, the system uses three discovery signals, B2B access patterns, multitenant application registrations, and shared billing accounts, to surface tenants you didn't even know existed. Once you can see them all, you can start enforcing consistent MFA, SSO, and Conditional Access policies across the board.
This guide walks you through exactly how to go from "I have no idea what tenants exist in my environment" to "I have a governed, monitored, policy-consistent tenant fleet." I'll cover the real-world steps, the common failure points, and the specific configurations that most guides skip over. Browse all Microsoft fix guides →
The Quick Fix, Try This First
If your immediate problem is that you need to get visibility into unknown tenants and enforce MFA or Conditional Access across them fast, here's the fastest path through Microsoft Entra Tenant Governance.
Sign in to the Microsoft Entra admin center at entra.microsoft.com as a Global Administrator or an administrator whose assigned roles include Tenant Governance permissions. You need either a Microsoft Entra ID Governance license or a Microsoft Entra Suite license, this feature is not available on standard Entra ID P1 or P2 alone. If you try to navigate to the Tenant Governance page without the right license, you'll hit a blank screen with no error, just a silent redirect. That trips up a lot of people.
Once you're in, navigate to Identity Governance > Tenant Governance in the left sidebar. If you don't see this menu item, your role doesn't have Tenant Governance read permissions, you'll need a Global Admin to assign you the appropriate scoped role first.
From the Tenant Governance overview page, click Enable tenant discovery. This kicks off the automated discovery process using the B2B signal (which tracks inbound and outbound B2B access, B2B guest registration, and administrative B2B relationships), the multitenant application signal (which finds apps registered in other tenants that have permissions in yours, or vice versa), and the billing signal (which finds tenants sharing your commerce billing accounts).
Discovery isn't instant, it typically takes 24 to 48 hours to fully populate the related tenants list on the first run. But within a few hours you'll start seeing entries appear under Related tenants. Each entry shows you which discovery signals fired, giving you immediate signal about the nature of the relationship, whether it's a legitimate partner tenant, a test environment, or something that shouldn't exist at all.
Once you can see your related tenants, you can prioritize which ones to bring under formal governance relationships and start pushing consistent Conditional Access and MFA policies. Everything else in this guide builds on this foundation.
Head to entra.microsoft.com, sign in with your governing tenant credentials, and navigate to Identity Governance > Tenant governance > Related tenants. Click Enable tenant discovery if you haven't already.
Once discovery runs, you'll see a list of related tenants with columns showing discovery signals, relationship type, and initial metrics. The metrics panel shows B2B inbound and outbound volume, registered multitenant applications with cross-tenant permissions, and billing account overlap, all of which give you an immediate risk picture without clicking into each tenant individually.
Use the filter panel on the right side to sort by discovery signal type. I recommend starting with the billing discovery signal filter, those tenants share your commerce billing accounts and are highest risk for ungoverned configurations. Then sort by B2B access volume to identify tenants where your users are actively signing in but that aren't formally governed.
For each tenant in the list, look at the Signals and metrics column. A tenant showing both B2B access and multitenant application signals means your users are not just visiting, there are also app registrations with cross-tenant permissions, which means data access, not just authentication. That combination should jump to the top of your governance backlog.
What you should see when this step works: a populated list of related tenants with at least one discovery signal shown per entry. If the list stays empty after 48 hours, check that your account has the TenantGovernance.Read.All permission and that your license includes Tenant Governance Basic or Premium.
Once you've identified which tenants need to come under governance, navigate to Identity Governance > Tenant governance > Governance relationships and click New relationship.
You have two workflow paths here. If the target tenant shares a commerce billing account with your governing tenant, the billing integration shortcut appears, this pre-populates tenant details and skips the manual invitation step. Use it when it's available, it saves about 15 minutes of back-and-forth.
For tenants that don't share a billing account, you'll use the invitation workflow. Enter the target tenant ID (not the display name, use the actual GUID from Azure portal or the Get-AzureADTenantDetail PowerShell cmdlet) and select the permissions your governing tenant's admins will need in the governed tenant. The principle here is least-privilege cross-tenant access, only request what you actually need. Common permission sets include:
- Security Reader (for read-only monitoring of Conditional Access policies)
- Intune Administrator (for device compliance policy management)
- Global Reader (for broad configuration visibility without write access)
- Privileged Role Administrator (for MFA and identity policy enforcement)After you send the invitation, an admin in the governed tenant receives a request notification and must approve it. Once approved, your users in the governing tenant can use cross-tenant delegated administration to perform administrative tasks in the governed tenant without needing separate accounts there. This is the feature that eliminates the old pattern of maintaining dozens of break-glass accounts across tenants.
Success state: the governance relationship shows status Active in the relationships list, and you can click into it to see the delegated permissions in effect.
This is where Microsoft Entra ID Governance starts paying real dividends. Instead of manually configuring MFA requirements and Conditional Access policies in each governed tenant one by one, governance policy templates let you define the permission set once and request it consistently across any number of tenants.
Navigate to Identity Governance > Tenant governance > Policy templates and click New template. Give it a descriptive name like "Baseline Security Governance, MFA + CA Read" and select the administrative roles and permissions that your governing team needs to audit and enforce MFA and Conditional Access settings in governed tenants.
Templates are particularly valuable when you need to establish the same governance relationship across multiple tenants at once, for example, after an acquisition where you've just inherited 12 new tenants and need to get consistent MFA enforcement across all of them within a compliance window. Instead of going through the full invitation workflow 12 times with potentially different permission sets each time, you reference the template and get the same result every time.
For MFA and Conditional Access enforcement specifically, your template should request at minimum Conditional Access Administrator and Security Administrator roles in governed tenants. These roles let your governing-tenant admins read existing CA policies, create new ones, and enable or modify MFA registration requirements, all without needing a separate admin account in each governed tenant.
Once your template is saved, you can use it in the New relationship workflow by selecting Use existing template instead of manually building the permission set from scratch.
Once governance relationships are active, the next layer is making sure governed tenants stay in sync with your security baseline. Configuration drift is the number one reason that MFA requirements silently break after initial setup, someone with direct admin access in the governed tenant modifies a Conditional Access policy, and your governing-tenant team has no visibility into the change until users start complaining.
Navigate to Identity Governance > Tenant governance > Configuration management. The configuration management system supports over 200 resource types across six Microsoft services: Entra, Intune, Exchange Online, Teams, Purview, and Defender.
Start by creating a configuration snapshot of your best-configured, most-compliant tenant. This gives you a JSON document representing the current state of tenant resources, think of it as a point-in-time photograph of your security posture. Navigate to Configuration snapshots > New snapshot, select the governed tenant, and choose the resource types you want to capture. For MFA and Conditional Access governance, prioritize:
- Microsoft.AAD/conditionalAccessPolicies
- Microsoft.AAD/authenticationMethodsPolicy
- Microsoft.AAD/securityDefaults
- Microsoft.Intune/deviceCompliancePoliciesOnce the snapshot is captured, use it as the foundation for a configuration baseline, a JSON document that expresses the desired state. Edit the snapshot JSON to remove environment-specific values (like tenant-specific GUIDs) and replace them with your intended policy definitions. Save this as your baseline.
Then create a monitor that targets the governed tenant and references your baseline. The monitor runs automatically at six-hour intervals and surfaces any configuration drifts, resources where actual state differs from the desired baseline state. You see these drifts as a list showing exactly which property changed, what value it changed from, and what value it changed to. No more discovering that someone turned off MFA enforcement three weeks ago when a compliance audit surfaces it.
Everything we've covered so far addresses existing tenants. But what about the next tenant your users create? Without secure tenant creation controls, you're playing catch-up forever, governing tenants reactively after they've already accumulated ungoverned configurations and users.
Navigate to Identity Governance > Tenant governance > Secure tenant creation. The secure tenant creation feature works by attaching governance policy templates to your commerce billing accounts. When a user creates a new add-on tenant using a controlled billing account, the governance relationship defined in the template is automatically established between your governing tenant and the new tenant before anyone even signs into it for the first time.
To set this up, first assign a governance policy template to your commerce billing account. Go to Billing > Billing accounts in the Azure portal, select the billing account you want to control, and navigate to Microsoft Entra assets > Governance policy. Select the template you created in Step 3.
You can also control who's allowed to create add-on tenants at all by managing access to the billing account itself. Limiting the Billing account contributor role to a small set of approved IT staff means that marketing, sales, or any other department can no longer spin up shadow tenants on the corporate credit card without IT being immediately notified and automatically governing the result.
The commerce API and the Entra admin center both support programmatic tenant creation with governance baked in, useful if your IT team creates test environments or project tenants at any volume. Using the API path (POST /tenants with the billing account and governance template parameters) ensures that every tenant created through your automation pipeline inherits your MFA, Conditional Access, and configuration management baseline from the moment it exists.
When this is fully configured, you should see new tenants appearing in your Related tenants list with status Governed rather than Discovered, that's the confirmation that governance is in effect before anyone has had a chance to misconfigure anything.
Advanced Troubleshooting
Once you get past the initial setup, a different class of problems emerges. Here are the ones I see most often in enterprise Microsoft Entra ID Governance deployments and exactly how to work through them.
Governance relationship shows "Pending" indefinitely
If a governance relationship invitation stays in Pending status for more than 24 hours, the governed tenant admin either didn't receive the invitation notification or doesn't have permissions to approve it. Check first in the governed tenant: navigate to Identity Governance > Tenant governance > Governance relationships > Received requests. If the request isn't there, the invitation email may have been caught by spam filtering or the wrong admin was targeted. You can resend the invitation from the governing tenant side without creating a duplicate, the system deduplicates by tenant ID.
If the request is present but the governed tenant admin can't approve it, they need the TenantGovernance.ReadWrite.All permission. Confirm their role assignments include this before asking them to retry.
Configuration monitor shows zero drifts even when you know policies are different
This is almost always a scoping issue. The monitor only covers resource types explicitly included in the baseline JSON. If you didn't include Microsoft.AAD/conditionalAccessPolicies in the baseline definition, the monitor won't surface Conditional Access drift. Open your baseline JSON in the configuration management editor and verify the resource type list against what you actually want to monitor. Also check that the governed tenant's delegated administration permissions include read access to each resource type, a monitor can't report drift on resources it can't read.
SSO breaks after governance relationship is established
Cross-tenant delegated administration works through a service principal that gets injected into the governed tenant. If SSO breaks after you establish the relationship, check for Conditional Access policies in the governed tenant that block service principal sign-ins or that apply MFA requirements to all apps without excluding the governance service principal. In the governed tenant, navigate to Protection > Conditional Access > Policies and look for policies with All cloud apps scope and All users scope, these can inadvertently catch governance service principals. Add a named exclusion for the Microsoft Entra Tenant Governance application (application ID edb47fbd-9e2b-4abe-836e-6c2afef0b7c7) to any Conditional Access policy that would otherwise block it.
PowerShell: Retrieve governance relationships and drift status
The tenant configuration management APIs are generally available and fully scriptable. To pull a list of current configuration drifts programmatically:
# Connect with appropriate scopes
Connect-MgGraph -Scopes "TenantGovernance.Read.All"
# Get all monitors across governed tenants
$monitors = Get-MgTenantGovernanceMonitor -All
# For each monitor, retrieve drift summary
foreach ($monitor in $monitors) {
$drifts = Get-MgTenantGovernanceMonitorDrift -MonitorId $monitor.Id
Write-Output "$($monitor.DisplayName): $($drifts.Count) drifts detected"
}This is useful in a weekly compliance reporting script, pipe the output to a CSV and you have an audit trail showing drift counts per tenant over time, which satisfies many compliance frameworks' change monitoring requirements.
Event log analysis for Entra ID Governance sign-in failures
When cross-tenant delegated administration fails silently, your first stop is the Entra sign-in logs in the governing tenant: Monitoring > Sign-in logs, filtered by Application = "Microsoft Entra Tenant Governance" and Status = Failure. The error codes you'll most commonly see are AADSTS50105 (user not assigned to a role for this application), AADSTS53003 (access blocked by Conditional Access policy), and AADSTS700016 (application not found in tenant, typically means the service principal wasn't properly injected). Each error code maps directly to a specific fix.
AADSTS700016 even after re-injecting the service principal, or if configuration snapshots fail to complete after 72 hours, escalate to Microsoft Support directly. These are backend provisioning issues that no amount of client-side configuration will resolve. Since Tenant Governance is currently in preview, Microsoft Customer Support is explicitly authorized to assist with production environments, you don't need to wait for GA.