Join our Newsletter — 33% off our NHI Course
Home› FAQ› Governance, Ownership & Risk› How do you configure universal tenant restrictions in…
Governance, Ownership & Risk

How do you configure universal tenant restrictions in Microsoft Entra?

← Back to all FAQ
By NHI Mgmt Group Editorial Team Updated October 20, 2026 Domain: Governance, Ownership & Risk

Configure universal tenant restrictions by applying a policy that limits sign-ins to approved Microsoft Entra tenants across supported access paths. Start with a pilot, define the allowed tenant list, and confirm your managed devices or network controls enforce the policy consistently. Then monitor blocked sign-ins and maintain an exception process for approved external collaboration.

What universal tenant restrictions actually control in Microsoft Entra

Universal tenant restrictions are about constraining where users can sign in from, not about blocking every external collaboration scenario. The practical value is that they reduce token theft and tenant impersonation risk by limiting access to approved Microsoft Entra tenants, while still allowing a controlled set of partners or guests. That means the policy has to align with your actual collaboration model, not just your directory configuration.

Because the control sits in the access path, it should be treated as part of a broader sign-in policy design. If you rely on managed devices, conditional access, or network controls, the tenant restriction should reinforce those controls rather than duplicate them. The important question is whether a sign-in to an unapproved tenant is truly impossible on all supported paths, or only blocked in one client or browser flow.

How to configure the policy so it holds up in practice

Start with a pilot scope and a very explicit allowed-tenant list. A small rollout lets you confirm which users, apps, and collaboration scenarios depend on cross-tenant access before you enforce it broadly. This is also where you verify that the policy is applied consistently across the access paths your organisation actually uses, because inconsistent enforcement is a common reason these controls appear enabled but still fail at the edge.

Once the tenant list is defined, test the policy from the same device and network conditions your users use in production. If managed devices are part of the design, confirm that device state is not the only enforcement point. If network controls are part of the design, confirm that remote and unmanaged access cannot bypass the restriction through a different client path. A policy is only as strong as its weakest supported sign-in route.

For broader identity hardening around Entra, the Active Directory and Entra ID Hardening Guide is a useful companion because universal tenant restrictions work best when they are part of a larger access-control design. For operational context on sign-in controls and audit logging, Microsoft 365 Security Guide covers the adjacent controls that make tenant restrictions easier to validate and sustain.

What to watch after rollout, and where exceptions belong

After deployment, monitor blocked sign-ins closely enough to distinguish normal partner activity from genuine misconfiguration. The most useful signal is not just the number of blocked attempts, but whether they cluster around a specific app, population, or location that indicates an approved path is being broken. If blocks are frequent during business operations, the allowed-tenant list or the supporting access path is probably incomplete.

Exception handling matters because universal tenant restrictions can create friction for external collaboration if they are too broad or too rigid. Keep exceptions narrow, documented, and time-bound, and make sure they are reviewed against the actual business need. For privileged access and administrative workflows, pair the tenant restriction with tight role governance so the exception process does not become a standing bypass.

If you need a control reference for how this should be operationalised, the Privileged Identity Management (PIM) Guide helps frame how approval, activation, and time limits should work when exceptions touch privileged access. If you want a concrete example of why tenant and app restrictions matter, Storm-1283 OAuth apps abuse 2023 illustrates how Entra-based trust can be abused when access paths and app credentials are not tightly constrained.

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 and CIS Controls v8 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.

FrameworkControl / ReferenceRelevance
NIST SP 800-53 Rev 5AC-3 — Access EnforcementEnforces tenant-based sign-in restrictions as an access decision.
IA-5 — Authenticator ManagementTenant restriction depends on managing the credentials and tokens that carry sign-in authority.
AU-2 — Event LoggingBlocked sign-ins and exceptions require logging for validation and review.
Recommendation — Enforce approved-tenant access boundaries for sign-in paths. Manage sign-in credentials and tokens so restricted tenants cannot be used. Log blocked sign-ins and review exception activity for drift.
ISO/IEC 27001:2022A.5.15 — Access controlUniversal tenant restrictions are an access-control measure for external sign-ins.
A.8.5 — Secure authenticationThe policy depends on reliable authentication and sign-in enforcement across access paths.
Recommendation — Define and enforce approved-tenant access rules for external sign-ins. Verify authentication flows honor the tenant restriction consistently.
CIS Controls v8CIS-6 — Access Control ManagementTenant restrictions are a practical access-control safeguard for cloud sign-ins.
Recommendation — Restrict external sign-ins to approved tenants and review exceptions.

Practitioner Guidance

What to verify: Confirm that the restriction is enforced on every supported sign-in path your users actually use, including browser, desktop, and mobile access. If one path is exempt, treat the control as incomplete until that gap is explained and accepted.

Common mistake: Do not assume a correct tenant list means the control is effective. The usual failure is inconsistent enforcement between managed and unmanaged endpoints, or between interactive sign-ins and app-mediated access.

Decision rule: If a blocked tenant is part of a routine partner workflow, fix the allow list and the surrounding access design first. If the tenant is not business-approved, keep the block and investigate whether the sign-in attempt indicates user error, misrouted collaboration, or malicious access.

Practitioner takeaway: Universal tenant restrictions are most effective when they are treated as an enforceable access boundary, not a configuration checkbox, and when exceptions are temporary, evidence-backed, and tightly owned.

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.

NHIMG Editorial Note
Reviewed and updated by the NHIMG editorial team on October 20, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org