A user on a corporate laptop can sign in to a personal or another organisation's Google or Microsoft tenant through the same login pages as your own, and copy your data there in seconds. URL filtering cannot separate the two, because sanctioned and unsanctioned accounts use the same domains. Tenant restrictions solve this at the identity layer: the sign-in service learns which tenants your network or device allows and refuses the rest. This guide explains how tenant restrictions work in Google Workspace and Microsoft Entra ID (Microsoft 365), the enforcement options for each, how to roll them out without breaking partner collaboration or device management, and how to measure them. It is written for identity, network and data protection engineers. Platforms are listed alphabetically.
This is an independent guide from NHI Mgmt Group, based on Google's and Microsoft's public documentation as of November 2026. It is not sponsored or reviewed by either vendor. Product features change, so confirm settings against each vendor's current documentation.
Key takeaways
- Tenant restrictions control outbound identity use. They limit which external accounts your users can use from your network or devices, which is a different control from guest access to your own tenant.
- Both platforms use an allow list signal. Google reads the X-GoogApps-Allowed-Domains header; Microsoft Entra ID reads a policy reference that points to tenant restrictions v2 settings in cross-tenant access settings.
- Enforcement needs a reliable path. Proxy header injection requires TLS interception of sign-in traffic; device and client-based options reduce that dependency.
- Allow lists must include machine identities. Service accounts and app sign-ins break if their domains or tenants are missing from the policy.
- Test before you block. Start with a pilot group, collect partner tenants and domains from sign-in data, then widen in rings with a documented rollback.
What tenant restrictions do and do not cover
Tenant restrictions answer one question: from this managed network or device, which organisations' accounts may sign in? They address data exfiltration to a personal or attacker-controlled cloud account, mapped in MITRE ATT&CK as T1567.002 Exfiltration to Cloud Storage and T1537 Transfer Data to Cloud Account, and the use of foreign cloud accounts (T1078.004 Cloud Accounts) from inside your estate. ATT&CK mitigation M1021 Restrict Web-Based Content is the closest mitigation mapping.
| Control | Direction | Question it answers |
|---|---|---|
| Tenant restrictions | Outbound, from your users and devices | Which external tenants and consumer accounts can my users sign in to here? |
| Guest and external sharing settings | Inbound, into your tenant | Which outside people can access my files, sites and teams? |
| Cross-tenant access (B2B) settings | Inbound and outbound collaboration | How do my users and partner users collaborate as guests, and whose MFA do I trust? |
| Data loss prevention | Content | Which sensitive content may leave, by any channel? |
Tenant restrictions do not stop a user sending data from an unmanaged personal device on a home network, and they do not inspect content. Pair them with sharing controls from the SharePoint and OneDrive Security Guide and content controls from the Data Loss Prevention (DLP) Guide. Inbound guest governance is covered in the Entra ID Cross-Tenant Access and B2B Guest Governance Guide.
Google Workspace: restricting sign-in to allowed domains
Google's mechanism is documented in the Workspace Admin Help article "Block access to consumer accounts". It stops users signing in to Google Workspace and Google Cloud services with accounts other than those your organisation provides, such as personal Gmail accounts or managed accounts from other domains.
The header and its values
The control is an HTTP header, X-GoogApps-Allowed-Domains, added to requests to *.google.com. Its value is a comma-separated list. Google's documentation lists these accepted values:
| Value | Effect |
|---|---|
Your domains (for example example.com) | Allows managed accounts from that domain; include your primary and every secondary domain |
consumer_accounts | Allows gmail.com and googlemail.com accounts; leave it out to block them |
visitor_accounts | Allows visitor accounts, so Drive sharing with non-Google users still works |
gserviceaccounts.com | Allows authenticated service accounts |
Enforcement options
- Web proxy: the proxy intercepts each
*.google.comrequest and adds the header. This requires TLS interception, routing all outbound*.google.comtraffic through the proxy, deploying the proxy's internal root CA to clients as trusted, and ideally a proxy rule that stops users inserting their own header. See the TLS Inspection Guide. - Chrome policy
AllowedDomainsForApps: the Chromium policy definition states that setting it turns on Chrome's restricted sign-in for Google Workspace, prevents users changing it, and appends theX-GoogApps-Allowed-Domainsheader to HTTP and HTTPS requests to google.com domains. It is defined for Chrome on desktop, ChromeOS and Android from version 51. Use it on managed Chrome where TLS interception is not in place. - ChromeOS setting: in the Admin console, Devices > Chrome > Settings > User experience > Sign-in to secondary accounts, allow sign-in only to listed Google Workspace domains. Google notes changes usually apply within minutes and can take up to an hour.
- Browser primary account: the Chrome policy
RestrictSigninToPatterntakes a regular expression (for example.*@example\.com) that limits which Google account can be set as the browser primary account. It governs the browser profile, not every Google service sign-in, so treat it as a complement.
Behaviour and limits to plan for
- User experience: blocked users see a page naming the unauthorised account and the domains where the service is available, and may see "This account is not allowed to sign in within this network."
- Scope of blocking: Google states that services requiring sign-in are blocked, while services that do not require sign-in, such as Google Search and YouTube, are not, and that the header does not necessarily prevent anonymous access.
- Delegated mailboxes: users who access delegated mailboxes in domains not in the header will see errors, so list those domains.
- URL filtering is not a substitute: managed and unmanaged accounts use the same URLs.
For broader Workspace hardening, see the Google Workspace Security Guide.
Microsoft Entra ID: tenant restrictions v2
Microsoft's current mechanism is tenant restrictions v2 (TRv2), configured in the Microsoft Entra admin center under cross-tenant access settings, or through Microsoft Graph. It limits which external accounts and applications users can sign in to from your networks and managed devices. Microsoft documents two protection types: authentication plane protection, generally available, which blocks sign-ins with external identities; and data plane protection, in preview at the time of checking (November 2026), which blocks access that bypasses authentication, such as anonymous Teams meeting joins, anonymous SharePoint access and use of infiltrated tokens.
The policy
- Default settings: Cross-tenant access settings > Default settings > Tenant restrictions > Edit tenant restrictions defaults. Default settings apply tenant-wide and cannot be scoped to individual users or groups.
- Partner (organisational) settings: per external tenant under Organizational settings; they override the default. Each has an External users and groups tab and an External applications tab, each with Allow access or Block access.
- Pairing rule: Microsoft cautions that if you block all external users and groups you must also block all external applications, and the reverse.
- Personal Microsoft accounts: create a partner policy for the Microsoft account tenant ID
9188040d-6c67-4c5b-b112-36a304b66dad. It applies to all consumer accounts; you can still allow specific apps by application ID. Per-user restriction is not available for consumer accounts. - Roles and licensing: at least Security Administrator to configure policies; Microsoft Entra ID P1 or P2.
Enforcement options
| Option | Protection | Where it works | Dependencies |
|---|---|---|---|
| Universal tenant restrictions (Global Secure Access) | Authentication plane; data plane for Microsoft Graph | Devices running the Global Secure Access client or behind a Global Secure Access remote network, across operating systems and browsers | Global Secure Access licensing; Microsoft traffic profile with Entra ID endpoints set to Tunnel; Global Secure Access Administrator and Security Administrator roles |
| Corporate proxy header injection | Authentication plane | Traffic through the proxy, including macOS, Chrome and .NET apps | TLS decryption of sign-in domains; header sent to login.live.com, login.microsoft.com, login.microsoftonline.com and login.windows.net |
| Windows device policy (Group Policy or Entra-managed, preview) | Authentication and data plane | Windows 10 and 11 with Microsoft Edge and enlightened apps | Current Windows updates; App Control for Business for apps that do not use the Windows networking stack |
Proxy header format: sec-Restrict-Tenant-Access-Policy: <TenantId>:<policyGuid>, where the policy GUID is the id of your default cross-tenant access policy object.
Universal tenant restrictions: configure the default and partner TRv2 policies first, then in the Entra admin center go to Global Secure Access > Settings > Session Management and, on the Universal Tenant Restrictions tab, turn on Enable Tenant Restrictions for Microsoft Entra ID and Microsoft Graph. Client coverage is covered in the Microsoft Entra Private Access guide.
Windows Group Policy: Computer Configuration > Administrative Templates > Windows Components > Tenant Restrictions > Cloud Policy Details, with the Microsoft Entra Directory ID, Policy GUID and the option Enable firewall protection of Microsoft endpoints. Browsers and tools that do not use the Windows networking stack, such as Chrome, Firefox and .NET applications, cannot send the signal; Microsoft documents using App Control for Business to block them or to tag them so they cannot reach Microsoft resources. See the App Control for Business (WDAC) guide.
Behaviour and limits to plan for
- Own tenant and guests: the policy is processed only for identities from a different tenant. Your own users and guests in your tenant are not evaluated.
- Anonymous access: proxy-based TRv2 does not block anonymous Teams, SharePoint or other unauthenticated access; the data plane options address part of this. Microsoft lists anonymous access to consumer OneDrive (
onedrive.live.com) as unsupported and suggests blocking that URL at the proxy. - Device traffic: blocking the consumer account tenant does not block non-user traffic such as Autopilot and Windows Update.
- Legacy signal conflicts: stop sending the older
restrict-msaheader to login.live.com, which conflicts with TRv2. - Admin portal access: administrators may see "Access denied" opening the Entra admin center for an allowed tenant; Microsoft documents a URL feature flag workaround.
Migrating from tenant restrictions v1
The original version used two proxy headers, Restrict-Access-To-Tenants (a comma-separated allow list of domains or tenant IDs) and Restrict-Access-Context (your own tenant ID). Microsoft's v1 documentation warns against injecting into the wildcard *.login.microsoftonline.com, because it includes device.login.microsoftonline.com and breaks device registration and device-based Conditional Access; exclude that host and enterpriseregistration.windows.net from inspection. To migrate, create a TRv2 partner policy for each tenant on the v1 allow list, then remove the v1 headers and the restrict-msa header from the proxy.
Where identity fits: service accounts and apps
Tenant restrictions affect machine identities as well as people, and most outages in rollouts come from them.
- Google service accounts: Google's documentation lists
gserviceaccounts.comas the value that allows authenticated service accounts and describes it as critical in the ChromeOS setting. Include it if workloads or tools on the restricted network authenticate as service accounts. - Microsoft service principals: TRv2 blocks service principal sign-ins from external tenants; a failed proxy-based attempt returns error
AADSTS5000211. Integrations and scripts that sign in to a partner's tenant need an explicit partner policy that allows the application. - Allow by application: partner policies in Entra can allow specific applications by application ID instead of whole tenants, which suits integrations better than opening all access.
Inventory these before enforcement; the Cross-Account and Cross-Tenant Access Guide covers the trust patterns involved.
Rolling out tenant restrictions
- Discover current use: from proxy logs and sign-in logs, list external domains and tenant IDs your users and workloads sign in to. Classify each as sanctioned partner, customer, consumer or unknown.
- Agree the allow list: your own domains and tenants, sanctioned partners, required service accounts or applications, and a decision on consumer accounts (block, or allow named apps only).
- Choose the enforcement path per device population: managed Windows (device policy), managed Chrome (browser policy), everything behind a proxy (header injection), roaming devices (client-based service edge).
- Pilot: apply to a small IT group. In Entra, start with partner policies and a default that you widen only after review; in Google, start the header on a pilot proxy policy or organisational unit.
- Validate: test your own account, an allowed partner account, a consumer account and an unknown tenant, on each device type, and confirm the expected allow or block.
- Expand in rings: department by department, with a request route for new partner tenants and a target turnaround time.
- Rollback: remove the header from the proxy rule or Chrome policy, switch the Entra default to allow, or turn off the universal tenant restrictions toggle. Document who may do this and record each use.
Decision guidance
| Situation | Recommended approach | Trade-off |
|---|---|---|
| Existing TLS-inspecting proxy for all office and VPN traffic | Header injection for both platforms | Coverage ends when devices leave the proxy path; certificate trust issues on some platforms |
| Mostly managed Windows fleet | Windows device policy for Microsoft plus App Control for unenlightened apps; Chrome policy for Google | Preview features; app control effort |
| Hybrid and remote workforce on mixed operating systems | Client-based enforcement through a security service edge or universal tenant restrictions, plus browser policy | Client deployment coverage becomes the control |
| Small organisation without a proxy | Browser policy (AllowedDomainsForApps) on managed Chrome and Entra device policy on Windows | Other browsers need blocking or management |
| Heavy partner collaboration | Partner policies scoped to applications and groups, with a fast approval route | Ongoing allow list maintenance |
The same approach applies to personal AI chat accounts used on corporate devices; see the Shadow AI Policy Template for the policy side.
Detection and measurement
- Google: proxy logs of requests where the header was applied and of block pages served; review attempts by user and by attempted domain.
- Microsoft: sign-in logs record cross-tenant sign-ins in both home and resource tenants with failure reasons; on Windows, the Event Viewer log Applications and Services Logs > Microsoft > Windows > TenantRestrictions > Operational records client-side enforcement; audit logs show policy changes.
- Policy change alerts: alert on any change to the cross-tenant access default or partner policies, the universal tenant restrictions toggle, the proxy header rule or the Chrome policy.
Metrics that show it is working:
- Percentage of managed devices with an active enforcement path (proxy, client or device policy).
- Blocked sign-in attempts per week to consumer and unknown tenants, trending down after user communication.
- Number of allow list exceptions and their median age since last review.
- Median time to approve a new partner tenant request.
- Count of business-impacting incidents (blocked legitimate work) per rollout ring.
For writing detections on proxy data, see the Proxy and Web Gateway Log Detection Guide.
Framework mapping
| Framework | Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev. 5 | AC-20, AC-20(1), AC-4, SC-7(5) | Use of external systems and limits on authorised use; information flow enforcement; deny by default, allow by exception |
| NIST CSF 2.0 | PR.AA-05, PR.IR-01, DE.CM-01 | Access permissions enforced; protection from unauthorised logical access and usage; network monitoring |
| ISO/IEC 27001:2022 Annex A | A.5.14, A.8.23 | Information transfer; web filtering |
| MITRE ATT&CK | T1567.002, T1537, T1078.004; mitigation M1021 | Exfiltration to cloud storage and to other cloud accounts; use of cloud accounts; restrict web-based content |
Common failure patterns
- Proxy-only enforcement: laptops leave the office and the control disappears with them.
- Forgotten secondary domains and service accounts: Google sign-ins fail for a subsidiary domain, or workloads break because
gserviceaccounts.comwas left out. - Blocking users but not applications in Entra: the pairing rule is ignored and access paths remain open.
- Unmanaged browsers on managed devices: Chrome policy is set but a second browser without policy is allowed to run, or Windows device policy is set without App Control for unenlightened apps.
- Wildcard header injection: injecting into every Microsoft login subdomain breaks device registration and device-based Conditional Access.
- Treating it as DLP: tenant restrictions block foreign sign-in but not anonymous uploads, unmanaged devices or content leaving through other channels.
Practitioner checklist
- Inventory external domains, tenant IDs, service accounts and applications in use before enforcing.
- Decide the consumer account position for each platform and record approved exceptions.
- Google: include every owned domain,
gserviceaccounts.comwhere needed and delegated mailbox domains inX-GoogApps-Allowed-Domains. - Microsoft: configure TRv2 default and partner policies, including the consumer account tenant, and block users and applications together.
- Pick an enforcement path for every device population and measure coverage.
- Control unmanaged browsers and apps that cannot carry the signal.
- Remove legacy v1 and
restrict-msaheaders after migrating to TRv2. - Pilot, validate with four test identities per device type, then expand in rings with a rollback owner.
- Alert on changes to tenant restriction policies, proxy header rules and browser policies.
- Review partner allow lists quarterly and remove unused entries.
Standards and references
- Google Workspace Admin Help: Block access to consumer accounts
- Chromium: AllowedDomainsForApps policy definition
- Chromium: RestrictSigninToPattern policy definition
- Microsoft Learn: Set up tenant restrictions v2
- Microsoft Learn: Universal tenant restrictions
- Microsoft Learn: Tenant restrictions (v1)
- NIST: SP 800-53 Rev. 5
- MITRE ATT&CK: Exfiltration to Cloud Storage
Related NHI Mgmt Group resources: Entra ID Cross-Tenant Access and B2B Guest Governance Guide · SharePoint and OneDrive Security Guide · Google Workspace Security Guide · Shadow SaaS and Unsanctioned App Discovery Guide · SSO Coverage Guide