Tenant Restrictions is a network control that limits which Microsoft Entra tenants can be accessed from a device or browser. It works by filtering sign-in traffic so users can reach only approved tenants, helping organisations reduce shadow IT and constrain data exposure across tenant boundaries.
What Tenant Restrictions does in practice
Microsoft Entra Tenant Restrictions are a network-side control for constraining which Entra tenants can be reached from a managed device or browser session. That makes them useful when the organisation wants to narrow where users can authenticate, not just what they can do after sign-in.
The control is most effective when paired with a clear allow list of sanctioned tenants, because it can turn tenant discovery and sign-in into a bounded activity rather than an open-ended one. It is especially relevant in environments where users routinely interact with multiple tenants through Microsoft 365, partner portals, or external collaboration flows.
Why tenant filtering matters
Without tenant-level filtering, users can be drawn into unsanctioned SaaS tenants through phishing, lookalike tenants, copycat collaboration invitations, or well-meaning but unmanaged external workflows. Restricting tenant access reduces the chance that a browser session lands in an unapproved Microsoft Entra tenant and starts exposing identity data, files, or collaboration content to the wrong boundary.
This is also a control for limiting shadow IT at the point of sign-in. If users can only access approved tenants, the organisation reduces the spread of unmanaged tenant relationships that can bypass procurement, security review, or retention policy.
How it fits with other identity and access controls
Tenant Restrictions is not a replacement for Conditional Access, guest governance, or privileged access controls. It works earlier in the path, by reducing which tenants are reachable in the first place, while those other controls govern authentication strength, role assignment, guest lifecycle, and access decisions inside the tenant.
That sequencing matters because tenant reachability and tenant authorisation are different problems. A user may be well-authenticated and still land in the wrong tenant if the organisation has not constrained cross-tenant browsing and sign-in routes.
For broader cross-tenant governance, see Entra ID Cross-Tenant Access and B2B Guest Governance Guide, which covers trust settings, guest access reviews, and cross-tenant sync risk. For a wider view of tenant-level hardening, Entra ID Security Guide places tenant restrictions alongside Conditional Access, workload identity controls, and break-glass planning.
Operational considerations for rollout and review
Because tenant restrictions are a network control, they need careful scoping across browsers, managed endpoints, proxies, and remote access paths. Organisations should expect exceptions for support, testing, mergers, and external collaboration, then review those exceptions regularly so the allow list does not quietly expand into a policy bypass.
Detection and troubleshooting are also important. If users report blocked sign-ins to legitimate tenants, the issue may be policy drift, an incomplete allow list, or a routing path that is not carrying the restriction headers as intended.
Risk and Threat Considerations
Tenant Restrictions helps reduce cross-tenant exposure, but it can fail open if traffic bypasses the intended filtering path or if sanctioned exceptions are too broad. It also does not stop abuse inside an approved tenant, so it should be treated as boundary reduction, not a complete trust control.
Failure mechanism: Attackers or users can still reach unsanctioned tenant resources when browsing occurs outside the controlled path, when exceptions are too permissive, or when an approved tenant itself is compromised and used as the foothold for further access.
Impact: The result can be shadow IT, unintended data exposure across tenant boundaries, and greater opportunity for phishing, consent abuse, or cross-tenant persistence.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5, CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-4 — Information Flow Enforcement | Tenant restrictions enforce which tenant sign-in flows are allowed from managed endpoints. |
| AC-6 — Least Privilege | Tenant filtering narrows access to only the tenants users should reach. | |
| IA-5 — Authenticator Management | Tenant restrictions reduce exposure of sign-in journeys that rely on tokens and other authenticators. | |
| Recommendation — Enforce approved tenant access paths and block unapproved sign-in destinations at the network boundary. Limit access paths to the minimum tenant set required for the user’s role. Control how authenticators are used across tenant sign-in paths and revoke them when no longer needed. | ||
| CIS Controls v8 | CIS-6 — Access Control Management | The control is fundamentally about constraining approved access paths and reducing unauthorized tenant access. |
| CIS-8 — Audit Log Management | Tenant restriction deployments need visibility into blocked and allowed sign-in activity. | |
| Recommendation — Define and enforce approved tenant access boundaries and remove exceptions that are no longer needed. Monitor tenant access attempts and review blocked sign-ins for policy drift or abuse. | ||
| NIST CSF 2.0 | PR.AA-05 — Least Privilege | Tenant restrictions reduce reachable tenants to the minimum approved set. |
| Recommendation — Restrict tenant reachability to only the identities and collaboration targets that are explicitly approved. | ||
Practitioner Guidance
Governance implication: Treat tenant restrictions as an enforceable tenant-access policy, not a one-time browser setting. Ownership should sit with identity and network security together, because the control only works when allow lists, exception handling, and collaboration requirements are reviewed as one policy surface.
What to watch for: Review newly added tenants, support exceptions, and repeated sign-in blocks as signals that the approved boundary may no longer match business reality. If the approved set is not actively maintained, the control either becomes too permissive or starts breaking legitimate work.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on November 2, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org