Multi-tenant applications and partner integrations create trust chains that attackers can abuse for cross-tenant lateral movement.

Preface

Third-party SaaS and vendor apps introduce external dependencies into Entra tenants. A compromised partner registration can become a conduit into your directory.

Modern organizations are connected to dozens of other tenants: SaaS providers whose apps hold Graph permissions, managed service providers with delegated admin rights, subsidiaries, joint ventures, and suppliers whose staff are guests in Teams. Each connection is a trust relationship. Most were created one at a time, by different people, and are rarely reviewed together.

Problem

Attackers compromise a service provider tenant, register a malicious multi-tenant app, and solicit consent downstream. After consent, they inherit permissions in the target tenant without defeating that tenant's direct authentication defenses.

The same principle applies more broadly. If a partner tenant is compromised, its users may still hold guest access to your SharePoint sites, its admins may still hold delegated rights over your tenant, and its applications may still hold consented permissions to your mail and files. Your own MFA and Conditional Access policies protect your users, but they do little against access that was already granted to someone else.

How Trust Chains Are Abused

  • Consent phishing: a user is lured to approve a multi-tenant app requesting delegated permissions such as reading mail or files. The app receives tokens without ever knowing the user's password.
  • Compromised legitimate vendors: an app you already trust is taken over in its home tenant, for example by adding a credential to its registration. Every customer that consented to it is now exposed, and nothing changes in your tenant.
  • Delegated administration: service providers with broad standing admin access over customer tenants are an attractive target, because one compromise reaches many customers.
  • Guest accounts: external users whose home accounts are compromised keep whatever access they have in your tenant, and their authentication strength is set by their home tenant unless you enforce your own.

Solution

Align with NIST SP 800-53 AC-3 and CIS Control 16:

  1. Hardened Cross-Tenant Access Policies: Restrict which external orgs can collaborate, and which of their users, groups and applications are allowed in.
  2. Mandate inbound trust settings: Decide deliberately whether to accept MFA and device compliance claims from each partner tenant, and enforce MFA for incoming external users through Conditional Access.
  3. Continuous consent audits: Review and revoke over-privileged third-party integrations.

Supplier relationship controls, such as ISO/IEC 27001:2022 Annex A 5.19 to 5.22, help put these reviews on a regular schedule with named owners.

Design Guidance

Default deny, explicit partners

Cross-tenant access settings have a default configuration and per-organization overrides, each with inbound and outbound settings for B2B collaboration and B2B direct connect. A defensible baseline restricts the defaults and adds named partner organizations with the specific users, groups and applications they need. Outbound settings matter too: they control which external tenants your users can sign in to as guests, which limits data leaving through partner tenants.

Trust partner signals only when you trust the partner

Inbound trust settings let you accept MFA, compliant device or hybrid joined device claims from a partner tenant, which avoids double prompts. Enable them only for partners whose controls you have assessed. For everyone else, guests should satisfy MFA registered in your tenant.

Lock down consent

Restrict user consent to verified publishers and low-impact permissions, or disable it, and enable the admin consent workflow so requests reach a reviewer instead of being blocked silently. Admin consent for application permissions should follow the same change process as granting an admin role.

Least privilege for service providers

For Microsoft partners, use granular delegated admin privileges (GDAP) with time-bound, role-specific relationships, and remove legacy broad delegated access. Require partners to use your Conditional Access requirements where the relationship type allows it.

Implementation Steps

  1. Discover: list cross-tenant sign-ins by partner tenant, external service principals, guest users and delegated admin relationships.
  2. Classify partners by business need and sensitivity of the data they reach.
  3. Configure organizational settings for the partners you keep, then tighten the default settings. Test with a pilot group first, since changing defaults affects every external tenant.
  4. Apply Conditional Access to guest and external users, including MFA and session controls for sensitive apps.
  5. Review consent grants, remove unused third-party apps and reduce permissions on the rest.
  6. Schedule access reviews for guests and partner groups, with an owner who can approve or remove access.

PowerShell: List Third-Party Enterprise Apps

Connect-MgGraph -Scopes "Application.Read.All"
Get-MgServicePrincipal -All |
    Where-Object { $_.AppOwnerOrganizationId -and $_.AppOwnerOrganizationId -ne "your-tenant-id" } |
    Select-Object DisplayName, AppId, AppOwnerOrganizationId | Format-Table

The owning tenant is exposed as AppOwnerOrganizationId. The output includes Microsoft first-party apps, which are owned by Microsoft tenants; filter those out to focus on third parties, then review each remaining app's delegated grants and application role assignments.

Monitoring and Detection

In Microsoft Sentinel, watch for new consent grants, changes to cross-tenant policy and unusual inbound external access: 

// New application consent
AuditLogs
| where OperationName == "Consent to application"
| extend Actor = tostring(InitiatedBy.user.userPrincipalName)
| extend App = tostring(TargetResources[0].displayName)
| project TimeGenerated, Actor, App, Result
// Changes to cross-tenant access settings
AuditLogs
| where OperationName contains "cross-tenant"
| project TimeGenerated, OperationName,
    Actor = tostring(InitiatedBy.user.userPrincipalName), Result
// Inbound sign-ins by home tenant
SigninLogs
| where TimeGenerated > ago(30d)
| where HomeTenantId != ResourceTenantId and ResultType == "0"
| summarize SignIns = count(), Users = dcount(UserPrincipalName) by HomeTenantId

A home tenant that appears for the first time, or a sudden rise in activity from an existing partner, deserves a check with the business owner of that relationship.

Common Mistakes

  • Changing default settings without a discovery phase, which breaks legitimate collaboration and leads to the restriction being rolled back.
  • Trusting all partners' MFA claims by default instead of per partner.
  • Leaving user consent open to any app and any permission.
  • Forgetting outbound settings and focusing only on who can come in.
  • No owner for each relationship, so nobody can say whether a partner still needs access.

Where to Start

Restrict user consent and enable the admin consent workflow this week; it closes the most direct path. Then run the third-party app inventory and the inbound sign-in query, build a list of real partners, and use it to configure organizational cross-tenant settings before tightening the defaults.