Cross-tenant access settings define which users, apps, and services from one tenant can authenticate, authorize, or share resources with another tenant. In IAM terms, they control inbound and outbound trust, often using policies for federation, consent, guest access, and conditional restrictions across separate organizational boundaries.
What Cross-Tenant Access Settings Control
Cross-tenant access settings sit at the boundary between separate organisations, so the core job is not just “can users sign in,” but which identities, apps, and services are allowed to cross that boundary at all, and under what trust conditions. They are the policy layer that shapes federation, guest access, and resource-sharing between tenants.
Because the control point is a boundary policy, its security value comes from narrowing trust to the specific partners, users, and applications that actually need it. A well-designed configuration reduces accidental exposure from broad collaboration defaults, while a weak one can silently expand trust far beyond the intended business relationship.
How Inbound and Outbound Trust Works
Cross-tenant settings usually have two directions. Inbound trust determines what your tenant accepts from an external tenant, while outbound trust governs what your tenant is willing to send or expose to another tenant. That distinction matters because many incidents arise when inbound and outbound assumptions are treated as the same problem, even though the risk profile differs in each direction.
These policies often intersect with federation, B2B collaboration, and app-to-app access. In practice, they influence whether an external user can be invited, whether a federated identity assertion is trusted, and whether an external application can obtain the level of access it requests. The control is therefore both an identity boundary and a trust boundary.
For organisations that manage many partnerships, the setting becomes a governance mechanism as much as a technical one. It defines which tenants are approved, which domains are blocked or allowed, and whether special conditions such as device compliance, MFA, or limited resource scopes must be satisfied before access is granted.
Why Cross-Tenant Settings Are Security-Sensitive
The main security issue is that trust can propagate faster than visibility. If cross-tenant rules are too permissive, a guest, partner user, or external service may reach data, apps, or administrative workflows that were only meant for internal identities. That can create privilege creep, unintended data sharing, and hard-to-see lateral movement across organisational boundaries.
These settings also influence how identity compromise spreads. If an attacker gains control of one tenant, weak trust policies can let that compromise extend into another tenant through accepted federation paths, overly broad app consent, or poorly constrained guest relationships. In other words, the danger is not only unauthorised sign-in, but trust reuse.
NHIMG’s Federation and Trust Relationships Guide is useful here because cross-tenant access is ultimately a trust-design problem, not just a directory feature.
Operational Signals and Governance Boundaries
Practitioners should treat cross-tenant settings as part of the broader identity governance surface. The settings should be reviewed whenever a new partner, acquired company, contractor population, or cloud collaboration path is introduced, because each new relationship changes the trust graph and the blast radius of misconfiguration.
Good governance usually means aligning the policy with real business need, then checking that the approved relationships are reflected in the actual tenant configuration. When the policy and configuration diverge, the organisation may believe it has restricted access while the effective trust path still remains open.
For a wider view of cross-cloud identity governance, Multi-Cloud Identity Guide helps frame how trust, privilege, and policy drift show up across cloud environments.
Risk and Threat Considerations
Cross-tenant access settings can create material exposure when trust is broader than the organisation realises. The common failure mode is over-permissive federation or guest access, which can enable data leakage, impersonation, or cross-tenant privilege escalation after one tenant or partner relationship is compromised.
Failure mechanism: An attacker abuses accepted trust, weak inbound restrictions, or overly broad external collaboration rules to move from one tenant context into another, then uses that trust to reach apps, data, or admin paths that were meant to stay isolated.
Impact: The result can include cross-tenant account takeover, unauthorised resource access, tenant-to-tenant lateral movement, and a larger blast radius than the organisation expected from a single compromise.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP API Security Top 10 addresses the attack surface, NIST SP 800-53 Rev 5 and CSA Cloud Controls Matrix set the technical controls, and ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-20 — Use of External Information Systems | Cross-tenant access depends on governing external system and tenant use paths. |
| IA-8 — Identification and Authentication (Non-Organizational Users) | External users crossing tenant boundaries require controlled external identity authentication. | |
| AC-3 — Access Enforcement | Cross-tenant settings enforce who may access resources across tenant boundaries. | |
| Recommendation — Restrict and monitor external tenant access paths before allowing cross-tenant use. Require strong authentication for external identities before trust is granted. Enforce boundary-specific access decisions for every external tenant relationship. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | Cross-tenant settings implement access control between separate organisational boundaries. |
| A.5.16 — Identity management | External tenant collaboration depends on governed identity relationships and trust. | |
| Recommendation — Define and enforce access rules for external tenant relationships. Maintain controlled identity governance for trusted external tenants. | ||
| CSA Cloud Controls Matrix | IAM — Identity and Access Management | Cloud tenant trust, federation, and guest access are core IAM concerns. |
| A&A — Authentication & Authorization | Cross-tenant access depends on verifying identities and authorising external access. | |
| Recommendation — Apply IAM controls to all cross-tenant trust and access paths. Validate external authentication and authorisation before sharing resources. | ||
| OWASP API Security Top 10 | API5 — Broken Function Level Authorization | Cross-tenant app and service access can fail when external callers reach functions they should not. |
| Recommendation — Verify that external tenants cannot invoke privileged functions by mistake. | ||
Practitioner Guidance
Why practitioners should care: Cross-tenant access is not a static allow list, it is a living trust policy that should reflect who is currently trusted, why that trust exists, and what conditions must still be met. If those assumptions are not reviewed, the tenant boundary becomes porous by default.
What to watch for: Pay close attention to partner relationships that were created for a single project but never removed, broad inbound trust inherited from legacy collaboration, and application consent paths that quietly outlive the business need that justified them. Those are common places where cross-tenant exposure accumulates.
Related resources from NHI Mgmt Group
- How do you configure cross-tenant access settings in Microsoft Entra ID?
- Who is accountable when a Kubernetes CSI driver allows cross-tenant storage access through path traversal?
- Why do shared-data multi-tenant serverless systems increase the risk of cross-tenant access?
- How should SaaS teams implement tenant context so cross-tenant access does not slip through authentication alone?