In many of the environments I review, the risk of data moving uncontrolled into personal or foreign Microsoft 365 tenants is still underestimated. Copilot and the growth of unsanctioned cloud use make it easier than ever for users to move sensitive data out, sometimes by accident and sometimes on purpose. They do it through a personal OneDrive or SharePoint, or by signing up as a guest in an external tenant. Classic Conditional Access on its own doesn't cover this anymore. Since early 2025, tenant restrictions v2 has been the standard way in Microsoft Entra ID to block these leaks where they start.

Tenant restrictions v2 is more than a refresh of v1

I wouldn't call tenant restrictions v2 a simple update of the original. The v1 approach was rigid, relied entirely on proxy headers and was awkward to operate. v2 is finally built into the Entra admin center (External Identities → Cross-tenant access settings → Default settings → Tenant restrictions). You define one central policy there. By default, all external and personal Microsoft 365 tenants are blocked, and users can only reach partner tenants you have explicitly allowed. The policy controls who can authenticate from a device and which tenants apps and services can talk to. Combined with cross-tenant access settings (see Cross-tenant access settings: getting collaboration right), it becomes one of the most effective ways to close cloud data leaks and keep shadow IT under control.

The policy is enforced through GPO, Intune or universal tenant restrictions

Setting up the tenant restrictions v2 policy in the Entra admin center is easy. Enforcing it on the endpoint is the hard part. For the authentication plane there is the traditional registry key, which you can push with a Windows GPO or Intune. It makes sure only permitted tenants show up at sign-in. For more modern setups, including non-Windows devices, the new universal tenant restrictions option changes a lot. Microsoft now uses the Global Secure Access (GSA) client, part of Entra Suite, to enforce the policy on both the authentication and the data plane. That means browser sessions and applications outside Microsoft's ecosystem are covered too. The details are in the docs (Universal Tenant Restrictions).

A typical flow looks like this:

flowchart TD
    PolicyDef["Policy configuration in Entra admin center"] --> GPOIntune["Deploy registry key via GPO/Intune"]
    GPOIntune --> Client["Device applies tenant restrictions"]
    PolicyDef --> GSAClient["Roll out GSA client for universal restrictions"]
    GSAClient --> Client
    Client --> AuthPlane["Authentication plane blocks unauthorized tenants"]
    Client --> DataPlane["Data plane (apps, browser) limited to allowed tenants"]

Figure: Tenant restrictions v2 ties together the policy, endpoint configuration and enforcement on the authentication and data planes.

In practice you can mix the enforcement options. Windows endpoints under legacy management keep using the registry/GPO/Intune method. Environments with a wide range of devices or a Zero Trust approach get the most out of the GSA client, as long as they have the right Entra Suite licensing.

Proxy header injection works only as a fallback with real limits

Some companies still use a proxy-based approach. The corporate proxy injects a special HTTP header, and Microsoft services read it to decide which tenants are allowed. That can help with unmanaged devices or third-party endpoints. It doesn't solve everything, though. Devices outside the corporate network, for example at home or on the road, get around it easily. Newer app flows and mobile clients often ignore the header completely. I recommend treating proxy header injection as a stopgap or last resort, not as your main strategy.

Practical tip: If you still use proxy header injection, check regularly which requests it actually controls. New apps, browser updates or changes to Microsoft endpoints can open new blind spots quickly, so review your coverage often.

The MSA block works, but unmanaged devices remain a weak spot

Tenant restrictions v2 has its gaps as well. You can explicitly block personal Microsoft accounts (MSA), but unmanaged and BYOD endpoints are still hard to control. If a device doesn't run the GSA client and isn't managed through GPO/Intune, nothing prevents a user from signing in to another tenant on a personal PC or phone. You also have to manage exceptions in cross-tenant access settings carefully if you want to allow certain guest workflows. Otherwise legitimate collaboration gets blocked. The docs (tenant restrictions v2) are open about these gaps and the possible bypass routes.

For monitoring, you can run a query in the Microsoft Defender portal (Hunting → Advanced hunting) to look for suspicious sign-ins to unauthorized tenants. For example:

IdentityLogonEvents
| where AppDisplayName == "Microsoft Office" and AccountType == "ExternalGuest"
| where RemoteTenantId != "<your own tenant GUID>"

Prerequisites: Microsoft Defender XDR license, Security Reader role, and the relevant log sources enabled.

I see no serious cloud security without tenant restrictions v2

If you run a Microsoft 365 tenant in 2025 without tenant restrictions v2, you're asking for trouble. The feature closes a governance gap that has been open for years. Paired with universal tenant restrictions for the data plane and with cross-tenant access settings (see also Microsoft Entra Suite: Global Secure Access in practice), it gives you thorough, enforceable control over your tenant's data flow and external collaboration. You no longer need unreliable workarounds or patched-together proxies. For the first time, cloud identity governance does what it promised, and it's about time.