Block external-tenant sign-in paths only after mapping Tenant Restrictions v2 enforcement

Bottom line: Tenant Restrictions v2 can apply a cloud policy that limits which external tenants and applications users may access. The enforcement mechanism matters. A proxy header, Windows configuration, and Global Secure Access do not provide identical authentication-plane, data-plane, browser, platform, or application coverage.

Source fact: what Microsoft documents

Microsoft’s Tenant Restrictions v2 setup guide documents a policy in cross-tenant access settings and three enforcement approaches: universal tenant restrictions through Global Secure Access, authentication-plane enforcement through a corporate proxy, and Windows device enforcement. Policies can be scoped to users, groups, organizations, or external applications.

The source describes important boundaries. Windows enforcement can protect specified authentication and data paths on managed Windows devices, while browser and application behavior depends on the networking stack and configuration. The page includes separate sections for Chrome, Firefox, .NET applications, Microsoft 365 resources, service principals, and preview capabilities. Microsoft also distinguishes tenant restrictions from inbound and outbound cross-tenant access settings and from ordinary B2B collaboration.

What the source does not establish

The feature does not automatically cover every operating system, browser, personal device, protocol, application, or network route. An authentication block does not necessarily prove that cached or data-plane access is impossible in every documented scenario. The source does not identify an organization’s legitimate external tenants, determine partner risk, or guarantee that a default-deny rollout will preserve support, acquisition, training, or customer workflows.

Applicability questions

• Is the objective authentication-plane control, data-plane control, or both?
• Which Windows, macOS, mobile, browser, .NET, PowerShell, Office, Teams, SharePoint, Exchange, and Graph paths are actually used?
• Which partner, customer, training, support, and personal Microsoft tenants are legitimately required?
• Will enforcement occur on devices, proxies, Global Secure Access, or a combination, and where can traffic bypass it?
• Which capabilities in the current documentation are generally available versus preview?

DSE recommendation: controlled next steps

The following steps are DSE recommendations based on the cited source.

1. Write the intended allow and deny decisions before configuring technology. Assign an owner and review date to every partner-tenant and application exception.
2. Draw authentication and resource traffic paths for managed and unmanaged devices, remote users, alternate browsers, native clients, and automation.
3. Match each path to Microsoft’s documented enforcement coverage. Do not generalize a successful Windows or Edge test to another stack.
4. Pilot with users who exercise real collaboration and support cases. Test intended access, denied access, cached sessions, browser variations, and loss of the enforcement component.
5. Monitor denials and establish a time-bounded exception process before broad enforcement.

Verification and evidence

• Preserve partner policy objects, default policy, enforcement configuration, scope, and change approval.
• Record a client-and-resource test matrix showing expected and observed authentication and data access.
• Capture Entra sign-in evidence and relevant proxy, device, or Global Secure Access logs for allowed and blocked cases.
• Retest after client, browser, network, or policy changes.

Official references

• Set up tenant restrictions v2 — Microsoft