Tenant restrictions v2: stopping data from leaking to other tenants
You protect your tenant against unwanted sign-ins. But what stops an employee, on a company device, from signing in to another Microsoft 365 tenant and uploading your documents there? By default, nothing. That is the job of tenant restrictions.
The exfiltration scenario
Microsoft 365 services use the same domain names for every customer. A firewall that allows SharePoint Online or Outlook therefore also allows any other organisation's tenant, including one created by an attacker or by an employee on their way out. Signing in there with an external identity is enough to copy files across, without ever leaving traffic that looks legitimate.
Outbound cross-tenant access settings do not cover this case: they govern what your identities can do in other tenants. They say nothing about a foreign identity being used on your devices.
From v1 to v2
The first version of tenant restrictions relied on a proxy injecting the list of allowed tenants into authentication traffic. It still works but has limits: the list is managed on the proxy rather than in Entra ID, and control only applies to authentication.
Version 2 moves the policy into Entra ID, inside cross-tenant access settings. The proxy or device only sends a reference to your tenant and policy; Entra ID then decides whether the external identity can obtain a token, and for which applications.
Building the policy
The policy is defined in the default settings, then refined per organisation:
- Default: block every external identity from accessing any third-party tenant from your devices and network;
- Per organisation: explicitly allow the partners your users need to work with, restricting users, groups and applications where needed;
- Personal Microsoft accounts: decide whether they should be blocked too, which is usually desirable on managed devices.
Before enforcing a default block, map real usage: Teams meetings hosted by customers, supplier portals, test tenants. Sign-in logs help identify external identities used from your network.
Do not confuse the two. Tenant restrictions have nothing to do with B2B guests in your own tenant. They apply to identities from other organisations used on your devices or network.
Network or device: where to enforce
The policy only works if traffic carries it. Several enforcement modes exist, with different coverage:
| Mode | How it works | Watch out for |
|---|---|---|
| Corporate proxy | The proxy inspects TLS and adds a header pointing to your policy on authentication requests. | Only covers traffic through the proxy; control limited to the authentication plane. |
| Global Secure Access | The Microsoft Entra Internet Access client inserts the policy reference, including off the corporate network. | Requires deploying the client and the matching licences. |
| Windows device | A group policy or device management setting applies the policy locally. | Data plane protection limited to certain applications and Windows versions. |
Supported Windows versions, applications covered on the data plane and licensing requirements change over time: check Microsoft's current documentation before designing your rollout.
Rolling out without breaking things
- Inventory the external tenants actually used from your devices.
- Create per-organisation allowances for legitimate partners.
- Configure the default block, then enable policy injection for a pilot group.
- Track sign-in failures caused by tenant restrictions and adjust.
- Expand gradually, with a documented exception request process.
What an audit checks
- Whether a tenant restrictions v2 policy exists and what its default behaviour is.
- The list of allowed organisations and the justification for each.
- The actual enforcement mode: proxy, Global Secure Access or device, and how much of the estate is covered.
- How personal Microsoft accounts are handled.
- Consistency with outbound cross-tenant access settings.