Tenant Restrictions v2: How Do You Block Tenants for CUI and ITAR?

The question can reach the IT Director from an assessor or the security office, and it is specific: what stops an engineer on a company laptop from signing in to a personal Microsoft 365 tenant, or a former employer’s, and uploading a drawing there? Sharing and guest access are already locked down, and someone points at the outbound cross-tenant access settings as the answer. They are not the answer, because those settings govern the organization’s own accounts, and the account in this scenario was issued by someone else. This guide covers the control that does govern it, what each way of enforcing that control blocks, and what Microsoft says changes in GCC High and DoD. It does not decide whether a data set is CUI or ITAR-controlled, or whether a contract or regime requires this control; that belongs to the export-compliance office and the contract.

If the security office has already tightened outbound cross-tenant access settings and believes the leak path is closed, look at whose account those settings govern. Microsoft’s Set up tenant restrictions v2 page (last updated March 20, 2026) frames the problem in its opening: “To enhance security, you can limit what your users can access when they use an external account to sign in from your networks or devices.” Its own example is the insider case: “For example, you can prevent a malicious insider from leaking data over external email by preventing the attacker from signing in to their malicious tenant.”

The same page separates the three settings in three lines:

• “Inbound settings control external account access to your internal apps.”
• “Outbound settings control internal account access to external apps.”
• “Tenant restrictions control external account access to external apps.”

It adds that “Your inbound and outbound settings for B2B collaboration and B2B direct connections don’t affect (and are unaffected by) your tenant restrictions settings.” Microsoft’s Overview: Cross-tenant access with Microsoft Entra External ID page (last updated March 28, 2025) says “Outbound access settings control whether your users can access resources in an external organization.” and “By default, B2B collaboration with other Microsoft Entra organizations is enabled, and B2B direct connect is blocked.”

The planning rule follows from those lines. Outbound settings govern your own accounts when they reach into other organizations. An account that someone else issued, whether a personal tenant, a former employer’s or a partner’s, is governed only by tenant restrictions, and only on your networks and devices. Where users do need to work in a partner’s tenant, Microsoft’s advice on the setup page is direct: “When your users need access to external organizations and apps, consider enabling tenant restrictions to block external accounts and use B2B collaboration instead.”

Before you choose how to enforce the policy, decide which plane the data at risk needs, because the routes differ exactly there. Microsoft’s setup page lists authentication plane protection in tenant restrictions v2 at general availability. Authentication plane protection blocks sign-ins that use external identities: the insider who tries to sign in to their own tenant is stopped at sign-in.

The second plane covers attacks that bypass sign-in. Microsoft says “Data plane protection in tenant restrictions v2 forces the user to authenticate for attempts to access a resource.” In the step-by-step table on the same page, Microsoft marks data plane protection as preview and describes it as blocking anonymous access to Microsoft Forms, SharePoint files and Microsoft Teams meetings, and user access with an infiltrated token. An anonymous link to a file in someone else’s tenant, or an access token copied from another device, is a data plane case.

Both planes depend on the policy signal reaching Microsoft. The same table says Microsoft Entra ID enforces the tenant restrictions v2 policy when the tenant restrictions v2 header is present on the request, which is why the next decision is how the header gets onto every request your users make.

When a pilot shows that remote users or a second browser still reach another tenant, look first for a route that does not cover that path. Microsoft’s setup page gives three routes, and each covers different ground.

A corporate proxy. Microsoft says “If you’re using a corporate proxy for header injection, options include only authentication plane protection.” In its proxy section it adds “This header doesn’t block anonymous access to Teams meetings, SharePoint files, or other resources that don’t require authentication.” and “Tenant restrictions v1 and v2 on the proxy require decryption of requests to sign-in URLs such as login.microsoftonline.com.” A proxy covers what passes through it, so a laptop off the corporate network needs another route.

Universal tenant restrictions through Global Secure Access. Microsoft says “Universal tenant restrictions use Global Secure Access to tag all traffic no matter the operating system, browser, or device form factor.” Its coverage is stated precisely: “Global Secure Access signaling supports authentication plane protection on all platforms and data plane protection for Microsoft Graph only.” Microsoft’s Turn on Universal Tenant Restrictions page (last updated July 29, 2026) says “Users on your devices with GSA or GSA Remote Networks can only sign in to tenants and applications authorized in your TRv2 policy.” and “Global Secure Access requires a license.”

Windows device policy. Microsoft says “For your corporate-owned Windows devices, you can enforce both authentication plane and data plane protection by enforcing tenant restrictions directly on devices.” and “Devices can be Microsoft Entra ID managed, or they can be domain joined and managed via Group Policy.” The setup page’s heading for this option marks it preview. Microsoft is candid about its reach: it calls tenant restrictions v2 on Windows a partial solution that protects the authentication and data planes for some scenarios. The next sentence on the page says it works on managed Windows devices and does not protect the .NET stack or the other browsers that Microsoft names there. It then says “This is the method for enforcing data plane protection for Microsoft 365 resources, such as SharePoint Online and Exchange Online.”

Two limits apply whichever route you choose. Microsoft’s list of unsupported scenarios on the setup page begins with anonymous blocking to consumer OneDrive accounts. And for platforms where the proxy cannot break and inspect traffic, Microsoft lists other Microsoft controls, including Conditional Access, B2B collaboration outbound rules, consent settings and an Intune app policy, then says “Although these alternatives provide protection, you can cover certain scenarios only through tenant restrictions.”

The planning rules:

• Name every path your users reach Microsoft sign-in by (the office network, remote access, each browser, each platform) and the route that covers it; a request without the header is not covered.
• Where Windows devices hold the controlled data, the Windows route is the one Microsoft gives for data plane protection of Microsoft 365 resources; plan for its preview label.
• Pair each route with the Microsoft controls that cover what it leaves open, and write down which gap each one closes.

If the default block goes live before anyone lists the external tenants the business depends on, the first week brings outage tickets instead of a closed leak path. Microsoft’s guidance on the setup page starts from the block: “Keep the tenant restrictions v2 default policy that blocks all external tenant access from foreign identities”, and, for a move from tenant restrictions v1, it adds a partner tenant policy for each tenant on the old allow list. The prerequisites the same page lists begin with “Microsoft Entra ID P1 or P2”.

Microsoft accounts need their own decision. Microsoft says “Because user-level assignment isn’t available for Microsoft account tenants, the policy applies to all users of Microsoft accounts.” Application-level granularity remains, so the choice is which consumer-account apps, if any, stay allowed for everyone. Microsoft also notes that “Blocking the Microsoft account tenant doesn’t block device traffic from sources other than users, including:” and its first item is “Traffic for Autopilot, Windows Update, and organizational data collection.”

Two further lines bound the policy. Microsoft’s universal tenant restrictions page says “Tenant restrictions aren’t enforced when a user (or a guest user) tries to access resources in the tenant where the policies are configured.” And Microsoft’s cross-tenant access overview warns: “Changing the default inbound or outbound settings to block access could block existing business-critical access to apps in your organization or partner organizations.”

For visibility before enforcement, Microsoft’s Quarantine unsanctioned tenants page (last updated March 16, 2026) says “Enabling TRv2 in audit mode and applying TRv2 policies with GSA shows all activity including attempts to access foreign tenants.” That view depends on Global Secure Access. If you already run tenant restrictions v1 on a proxy, Microsoft says “Migrating tenant restrictions policies from v1 to v2 is a one-time operation.”

The planning rules:

• Inventory the external tenants and Microsoft account apps users legitimately need before the default block, and give each partner policy a named owner.
• Pilot on one group first, with a rollback written before the pilot starts.
• Record which device traffic the Microsoft account block leaves alone, so no one reads a working Windows Update as a policy failure.

When the tenant holding CUI or ITAR data is in GCC High, the route list shrinks, and a plan copied from a commercial tenant fails in two places. The first is Global Secure Access. Microsoft’s Known limitations for Global Secure Access page (last updated May 29, 2026) says: “Global Secure Access is available in the US Government Community Cloud (GCC), but isn’t yet supported in the US Government Community Cloud High (GCC-H), Department of Defense cloud, or other government or sovereign cloud environments.” Universal tenant restrictions run on Global Secure Access, so a GCC High or DoD tenant cannot use that route today. Microsoft gives no date on that page.

The second is requests that cross a cloud boundary. The known limitations section of Microsoft’s setup page opens with four sentences: “Tenant restrictions v2 is supported on all clouds. TRv2 does not enforce restrictions on cross-cloud requests at the authentication plane, so access is permitted during authentication. However, TRv2 does block cross-cloud requests at the data plane. As a result, when using Windows Group Policy (GPO), users will be unable to access TRv2-enlightened resources across cloud boundaries.” Microsoft’s cross-tenant access overview names the clouds it treats as different, pairing “Microsoft Azure commercial cloud and Microsoft Azure Government, which includes the Office GCC-High and DoD clouds”.

This guide’s reading, not Microsoft’s words: Microsoft does not say in one place that a GCC High device signing in to a commercial-cloud or consumer tenant is a cross-cloud request, but read together those lines suggest that it is. If so, the authentication plane does not stop that sign-in, and the Windows device route’s data plane protection, which Microsoft labels preview, carries the weight in a GCC High tenant, with the proxy route adding authentication plane protection for same-cloud tenants. Test it on the tenant’s own devices before anyone tells an assessor what is blocked: a sign-in to a commercial tenant, a consumer account, and an anonymous link, each from a managed Windows device and from a device on the proxy.

A GCC tenant is in a different position: Microsoft says Global Secure Access is available in GCC, so all three routes are open to it.

If a leak path looks like this one, check first that it really runs through a sign-in with an external account, because some do not.

• If the data leaves through sharing or a guest inside your own tenant, tenant restrictions do not apply there, as Microsoft’s universal tenant restrictions page says; the control is sharing and inbound settings. For two tenants the enterprise owns after a deal, see Managing Dual-Tenant Microsoft Complexity After a Merger or Acquisition.
• If it leaves through a Power Platform connector, Microsoft’s Cross-tenant inbound and outbound restrictions page (last updated December 16, 2025) says “Power Platform tenant isolation is different from Microsoft Entra ID-wide tenant restriction. It doesn’t impact Microsoft Entra ID-based access outside of Power Platform.” That control is covered in Power Platform DLP Policy Administration for Regulated Enterprises.
• If the question is finding CUI inside content, that is a data loss prevention question, not a sign-in policy.
• Tenant restrictions act on your networks and devices, in Microsoft’s own opening words. In this guide’s reading, a personal device that never touches your network or management is a device-access question for Conditional Access, not for this policy.
• Whether a regime or contract requires this control is for the export-compliance office and the contract. The ITAR program itself is covered in Redesigning an ITAR Export-Control Compliance Program to Be Efficient, Not Just Compliant.
• If Microsoft changes a preview label, or supports Global Secure Access in GCC High, parts of this guide change; re-read the cited Microsoft pages before relying on them.

When an outside team designs this policy, or your own team does, the same questions separate a plan an assessor can follow from a slide.

• Ask for an inventory of every path users reach Microsoft sign-in by, office network, remote, each browser and each platform, before any route is chosen.
• Ask for the route per path and the plane it gives, in writing, with Microsoft’s preview and general availability labels kept as Microsoft states them.
• Ask for the list of external tenants and Microsoft account apps the business needs, each with an owner, before the default block goes on.
• Ask for a pilot group and a written rollback.
• For a GCC High or DoD tenant, ask that the plan use only what Microsoft supports in that cloud today, and that cross-cloud behavior is tested on the tenant’s own devices.
• Ask for people who have implemented identity controls in CMMC and ITAR environments, and expect senior people rather than a handoff to a junior bench.
• Ask for a plain statement that your team owns and operates the policy after the project ends.

When a regulated enterprise takes this on, it needs a project with an end date: the policy design, the route chosen for each group of devices, the pilot and the handover, with embedded specialists where the internal team needs more hands for a period. i3solutions has deep experience implementing identity governance for enterprises in aerospace and defense manufacturing, financial services, and healthcare, including environments with CMMC and ITAR obligations. i3solutions is a Microsoft Systems Integrator with experience implementing identity and access management solutions for enterprises in regulated industries. i3solutions has been a Microsoft Partner with 30 years of enterprise technology delivery experience and has delivered 1,500+ Microsoft engagements across aerospace and defense, financial services, and health sciences. The people who do the work are senior and based in the US. An i3solutions engagement does not produce managed-service ownership, a replacement for the internal team, open-ended scope expansion, or vendor lock-in. This work sits within i3solutions’ Establish Identity as a Governed Enterprise Capability.