Cross-Tenant Access in Microsoft Entra: The Supply-Chain Vector Almost Nobody Closes

The question nobody asks in the security review

If you open Microsoft Entra > External Identities > Cross-Tenant Access Settings in your tenant today, and the "Default settings" section says Allow access for Inbound and Outbound, your organisation is trusting — automatically and unaudited — every other Microsoft Entra tenant on the planet.

Every one. No exceptions. No allow-list. No review.

It's the Microsoft 365 default since 2021. And it's the technical reason attacks that pivoted from a compromised supplier to a Banxico, Pemex, or several Mexican retailers in 2024-2025 aren't anomalies — they're the configuration asking to be exploited.

Why this control is invisible

Unlike MFA or Conditional Access, Cross-Tenant Access Settings (CTAS) don't appear in most security dashboards. They're not weighted heavily in Microsoft Secure Score. They don't surface in a shallow audit. The public docs are reasonable — but assume an E5 admin already knows the implication, which is rarely true in Mexican mid-market.

The result: a company at 100% MFA, with Conditional Access tuned, DLP active, and the full Defender XDR stack, can still be pivoted in fifteen minutes if a partner — a marketing vendor, an accounting firm, a consulting agency — suffers a compromise and the attacker sends a guest invitation from the partner's tenant.

What a real attack looks like

Reconstructed from publicly reported LatAm incidents 2024-2025:

1. Initial compromise in a partner tenant: successful phishing against an admin user at the accounting-services provider.

2. Pivot to trusted CTAS: the attacker now controls a user in a tenant that the target (the Mexican target company) treats as trusted because CTAS Default = Allow.

3. Guest invitation auto-accepted: the attacker invites themselves (as a partner user) into the target tenant. The invitation passes because the company's CTAS Defaults don't block it.

4. Local MFA bypass: the attacker gets the target to trust the partner's MFA claim ("they did MFA on their side, don't require MFA here"). Worst-case, but it's the default in Entra before explicit trust posture is configured.

5. Access to shared resources: the attacker (now a legitimate guest in the target tenant) accesses shared SharePoint sites, partner Teams channels, exposed OneDrive files. If sites carry sensitive info — and they usually do because they were "for sharing with the partner" — exfiltration is trivial.

6. Persistence: the attacker registers devices in the target tenant, configures forwarding rules, installs apps with broad permissions. When the partner detects the original compromise and rotates credentials, access to the target persists.

All of it happens because trust was granted by default, not by decision.

The regulatory shift that's already here

• CNBV Circular Única de Bancos: Chapter IX on outsourcing and third parties demands granular, auditable, reviewable access controls. CTAS Default = Allow doesn't survive the first supervisor question.
• NIST CSF v2.0: the Protect function, AC-3 category, requires explicit boundary controls between internal and external identities. CTAS Default = Allow is the opposite of an explicit boundary.
• ISO/IEC 27001:2022 Annex A 5.20: supplier relationships. Requires formal agreements, scoped access, periodic review. Doesn't work when the "agreement" is "every tenant in the world, automatically."
• LFPDPPP Arts. 35-36: transfers to third parties must respect the privacy notice, purposes, and consent unless a statutory exception applies. A guest invitation auto-accepted into a foreign tenant does not by itself document that analysis.

Twenty-four months ago, "we have MFA on all users" was a sufficient answer. It isn't anymore. CTAS is the next layer any serious auditor will ask about.

How to close the door without breaking operations

Step 1: Switch Defaults to Block

In Microsoft Entra > External Identities > Cross-Tenant Access Settings:

• Default tenant settings · Inbound access: Block access (B2B collaboration + B2B direct connect).
• Default tenant settings · Outbound access: Block access.
• Trust settings: Do NOT trust the partner's MFA claims, device-compliance claims, or Hybrid Azure AD join claims by default.

Done. The attack surface for unnamed tenants is now zero.

Step 2: Build the real allow-list

List every partner that DOES need access. For each:

1. Partner's tenant ID (not the domain — the GUID).

2. Named contact (the person at the partner who signs the agreement, not info@).

3. Business justification (why this partner needs B2B access).

4. Minimum scope: specific users or groups? specific apps? Never "all users, all apps."

5. Trust posture: do we trust their MFA or require fresh MFA here? The safe answer is the second.

6. Review date: 6 months max. Beyond that, the partner may have changed hands.

Every allow-list entry is a conscious, documented, reviewable decision: a technical control that can contribute evidence to NIST, ISO, or applicable sector requirements.

Step 3: Conditional Access that assumes distrust

Configure a Conditional Access policy that applies to guests / external users:

• Require fresh MFA at every login (don't trust the source tenant's claim).
• Block access from non-compliant devices.
• Limit session duration to 8 hours.
• Log every external-user access to unified audit (Purview).

Step 4: Sweep existing guests

Before locking Defaults, audit existing guest accounts in the tenant (Microsoft 365 admin → Users → Guest users). For each:

• Still needed? (If the partner no longer works with the company, remove.)
• Excessive permissions? (Trim group memberships and app assignments.)
• In the CTAS allow-list? (If not, add the source tenant or remove the guest.)

Common traps

Trap 1: "We'll break partner integrations"

CTAS Default = Block only affects tenants NOT in the allow-list. Partners with established relationships work exactly the same — provided they're in the allow-list. If you broke an integration, it's because it wasn't documented. That's a process failure, not a control failure.

Trap 2: Trusting the partner's MFA claim

Entra lets you "trust the MFA claim from the partner tenant." Tempting for reducing friction. Dangerous because it imports the partner's security posture: if the partner has weak MFA (SMS, push without number-matching) and the attacker bypasses it, that "successful" MFA is accepted into your tenant. Safe default: no trust. Require fresh MFA every time.

Trap 3: Allow-list that grows unreviewed

A 2026 allow-list with 30 partners, never reviewed, by 2028 has partners that no longer exist, partners acquired by others, partners where the named contact has changed jobs. Each is an unmanned door. Semi-annual review is the floor.

Trap 4: Treating Outbound as a soft control

Outbound Block = nobody in YOUR tenant can be invited as a guest into OTHER tenants. Sounds draconian until you remember: every time an employee accepts a guest invitation, they carry a corporate identity into a tenant you don't control. If the remote tenant is compromised, that identity — and the resources it has touched — are compromised too. Outbound Default = Block is the honest control.

How to measure success

Three metrics, reviewed quarterly:

1. Tenants in the allow-list: does the list match current real partners? (Any delta is cleanup work.)

2. Active guests by source tenant: does each guest map to an allow-list entry? (If not, orphan guest — remove.)

3. Conditional Access activations for external users: how many times did MFA fire on a guest this quarter? (Zero means the control isn't applying.)

Implementation checklist

• [ ] Inventory of current partner tenants (with tenant IDs, not just domains)
• [ ] CTAS Defaults set to Block for Inbound + Outbound
• [ ] MFA claim trust, device claim trust, Hybrid AAD claim trust disabled by default
• [ ] Allow-list built with justification + review date + minimum scope per partner
• [ ] Conditional Access policy applied to external users (fresh MFA, compliant device, 8h session)
• [ ] Existing guest sweep run (via audit-guest-accounts)
• [ ] Unified audit enabled for external-user activity tracking
• [ ] Semi-annual allow-list review on the corporate calendar
• [ ] High-privilege external-access alerts routed to CISO

First step: discover which tenants you trust today

Before changing Defaults, you need to know which external tenants you're trusting today and what guests you already carry. Our free scan evaluates the 155 Microsoft Graph rules of the 201-rule library — including CTAS configuration, guest accounts, and Conditional Access for external users — and delivers the verdict in minutes. The 46 Azure Resource Manager controls add on with admin consent.

Scan your tenant free →

---

Sources cited in this article:

• NIST Cybersecurity Framework v2.0 (NIST IR 8531, 2024) — Protect function, PR.AC-3 category
• ISO/IEC 27001:2022 Annex A 5.20 — Supplier relationships; A 8.4 — Access to source code
• CNBV Circular Única de Bancos — Chapter IX, outsourcing and third-party services
• LFPDPPP (Mexico), Art. 36 — International transfers of personal data
• Microsoft Entra Cross-Tenant Access Settings — official documentation