Out of the box, any user in a Microsoft Entra tenant can invite guests from almost anywhere, and those guests rarely leave. Over a few years that produces thousands of external accounts with access to Teams, SharePoint and line-of-business apps, many belonging to people whose contracts ended long ago, plus trust relationships with other tenants that nobody reviews. This guide explains how external identities work in Entra ID (B2B collaboration, B2B direct connect and cross-tenant synchronisation), which settings control them, how an attacker can abuse them, and how to govern guests with access reviews and lifecycle controls. It is written for Entra administrators, identity governance teams and security engineers, and it builds on the general model in the Third-Party Access Guide.
Key takeaways
- Defaults favour collaboration, not control. B2B collaboration is enabled for all users with all external tenants, guest invitations are broadly allowed, and nothing about inbound guests is trusted or scoped until you configure it.
- Cross-tenant access settings are the trust boundary. Default and per-organisation inbound and outbound settings decide which users, groups and apps can collaborate, whether partner MFA and device claims are trusted, and whether another tenant may push users into yours.
- Cross-tenant synchronisation is powerful and abusable. It is designed for tenants inside one organisation; an attacker with privileged access can use it to move laterally or plant a persistent backdoor.
- Guests need a lifecycle. Sponsors, access packages with expiry and recurring access reviews that remove inactive guests are what stop sprawl; one-off clean-ups do not last.
- Every change is logged. Changes to cross-tenant access settings sit in the audit log category CrossTenantAccessSettings and are protected actions you can require step-up for.
How identity and access work in Entra external collaboration
Entra ID offers three ways for identities from another organisation to reach your resources. They behave very differently for governance.
| Mechanism | What appears in your tenant | Typical use | Default |
|---|---|---|---|
| B2B collaboration | A guest (or external member) user object, invited or created by entitlement management | Partners, suppliers and contractors using your apps, Teams and SharePoint | Enabled for all internal users with all external Entra organisations |
| B2B direct connect | No user object; mutual trust between two tenants | Teams Connect shared channels only | Blocked inbound and outbound for all external tenants |
| Cross-tenant synchronisation | External member or guest users pushed and kept updated by the source tenant | Multi-tenant organisations, mergers, subsidiaries | No users synchronised; inbound sync must be allowed per partner |
Microsoft's documentation states that B2B direct connect will not be extended beyond Teams Connect shared channels, so for most governance work the real questions are about guest objects and synchronised users.
Cross-tenant access settings
Cross-tenant access settings apply to other Entra tenants. They have a default configuration and optional organisational settings per partner tenant, which take precedence over the default. For each, you set inbound and outbound access separately for B2B collaboration and B2B direct connect, scoped to specific users, groups and applications. There is no limit on the number of organisations you can add.
- Inbound trust settings: you can choose to trust MFA, compliant device and Microsoft Entra hybrid joined device claims from the partner tenant. Trusting MFA means a guest who completed MFA at home is not prompted again; your Conditional Access still applies.
- Automatic redemption: "Automatically redeem invitations with the tenant" suppresses the consent prompt and invitation email only when both the home tenant (outbound) and the resource tenant (inbound) enable it. It is required for cross-tenant synchronisation.
- Cross-tenant sync (inbound): "Allow user synchronization into this tenant" and "Allow group synchronization into this tenant" decide whether a partner may push identities into you.
- Redemption order: sets primary identity providers and fallbacks (Microsoft account, email one-time passcode); at least one fallback must stay enabled.
- Consistency rules: user and group settings must not conflict with application settings. If you block all apps by default, Microsoft lists app IDs to allow so that MFA registration, Terms of Use and Office 365 Message Encryption still work.
External collaboration settings are separate and cover non-Entra identities as well: who can invite guests, what guests can see in the directory, whether self-service sign-up via user flows is enabled, and allow or deny lists of domains. Tenant restrictions v2 is a third, independent control that limits which external accounts your own users can sign in with on managed devices.
Admin roles and privileged access
Configuring cross-tenant access settings requires at least the Security Administrator role (or a custom role). External collaboration settings can be changed in the portal by Global Administrator or External Identity Provider Administrator. Trust settings, redemption order and scoping to specific users, groups or apps need Microsoft Entra ID P1 in the tenant; B2B direct connect needs P1 in both tenants.
| Setting area | Who can change it | Hardening point |
|---|---|---|
| Cross-tenant access settings (default and organisational) | Security Administrator or higher, or a custom role | Make eligible-only through PIM; require step-up via protected actions |
| External collaboration settings | Global Administrator or External Identity Provider Administrator in the portal | Restrict these roles; review assignments quarterly |
| Guest invitations | Depends on Guest invite settings; Guest Inviter role grants it when invitations are restricted to admin roles | Route invitations through entitlement management instead of ad hoc invites |
| Cross-tenant synchronisation jobs (source tenant) | Administrators able to manage the sync configuration (an application in the source tenant) | Treat as privileged; alert on scope changes |
Guests should never hold directory roles. If a partner administrator genuinely needs privileged access, use a time-bound PIM assignment on a specific scope with approval, and review it separately from ordinary guest access. The Storm-2949 Azure attack shows how a single cloud identity with broad rights can become tenant-wide data theft; an external account with the same rights is the same exposure with less oversight.
Integrations, API tokens and service accounts
External identities are not only people. Multi-tenant applications from suppliers appear in your tenant as service principals with consented permissions, and cross-tenant synchronisation itself runs as a provisioning configuration in the source tenant. Both are non-human access paths across the tenant boundary.
- Multi-tenant apps: a partner's app registered in their tenant, consented in yours, can hold application permissions to your data with no user in the loop. Govern consent and permissions as described in the Entra ID Applications and Consent Guide.
- Synchronisation as a provisioning identity: the source tenant is the source of authority for synchronised users, including their credentials. The target cannot reverse it. Sync runs on a fixed cycle of roughly 40 minutes, so changes in the source arrive with a delay.
- Deprovisioning behaviour: when a user is deleted, unassigned or falls out of the source's scoping filter, the target user is soft deleted and hard deleted after 30 days; disabling the source account blocks sign-in in the target. Deleting the cross-tenant policy does not remove previously synchronised users, so cleanup must be explicit.
- Test and legacy tenants: trust relationships with forgotten tenants are a real route in. In the Microsoft Midnight Blizzard breach, a legacy test tenant account without MFA led to a legacy OAuth application with elevated access to the corporate environment. Inventory every tenant your organisation owns and every partner tenant you trust.
How cross-tenant synchronisation can be abused
Vectra Research described two techniques in 2023 that use only native functionality. With privileged access to a compromised tenant, an attacker can find partner tenants where outbound sync is configured and add a compromised user to the sync scope, gaining an account in the partner tenant (T1199 Trusted Relationship, with the resulting T1078.004 Cloud Accounts). Or the attacker can configure the victim tenant to accept inbound synchronisation and automatic redemption from a tenant they control, then push new users in whenever they like (T1484.002 Trust Modification, T1136.003 Create Account: Cloud Account). The researchers reported not having seen it in the wild at the time. Microsoft's own documentation is clear that cross-tenant synchronisation is intended for use within an organisation, and recommends entitlement management for collaboration between separate organisations.
Logging and detection
Send Entra audit and sign-in logs to your SIEM; native retention is short. The events that matter most:
| What to watch | Where | Why |
|---|---|---|
| Changes to default or partner cross-tenant access policies | Audit log, category CrossTenantAccessSettings | New partners, new trust of MFA or device claims, inbound sync or automatic redemption enabled |
| Changes to cross-tenant synchronisation jobs and scope | Source tenant provisioning and audit logs | Users or groups added to scope outside change control |
| Guest invitations and redemptions | Audit log (user management, invitations) | Bursts of invitations, invitations by unexpected users, domains outside the allow list |
| External user sign-ins | Sign-in logs filtered on cross-tenant access type and home tenant ID | Guests signing in from unknown tenants or locations, to sensitive apps |
| Role or group changes for external users | Audit log, PIM | Guests gaining privileged roles or owner rights on groups and Teams |
Practical detection queries and log fields are covered in the Entra ID Sign-In and Audit Log Detection Guide.
Metrics that show governance is working:
- Number of guest accounts, and percentage inactive for more than 90 days (the default threshold in the Entra guest access governance report).
- Percentage of guests with a named sponsor and an expiring access package assignment.
- Number of partner tenants with organisational settings, and how many have been reviewed in the last 12 months.
- Percentage of guest invitations made through entitlement management rather than ad hoc.
- Count of external accounts holding privileged roles (target zero standing).
- Access review completion rate and removal rate for guest reviews.
Hardening baseline
Roll changes out in stages: report first, then restrict defaults, then add partner exceptions. Most settings take effect for new sign-ins, so test with a pilot partner and keep a record of the previous configuration for rollback.
- Inventory first. Export all guest users with last sign-in, inviter and group memberships; list every tenant with organisational settings; list multi-tenant apps with consent. Use the ID Governance dashboard's inactive guest view to size the problem.
- Restrict invitations. Change Guest invite settings away from "Anyone in the organization can invite guest users including guests and non-admins" to "Only users assigned to specific admin roles can invite guest users", and grant Guest Inviter, or better, publish access packages for partner access. See the Entra ID Entitlement Management and Access Packages Guide.
- Limit guest visibility. Set Guest user access to "Guest user access is restricted to properties and memberships of their own directory objects (most restrictive)" unless a documented business need requires the default.
- Use domain allow lists where feasible. Collaboration restrictions can allow only named partner domains; a deny list is a weaker fallback for organisations with many ad hoc partners.
- Tighten the default cross-tenant policy. Scope default inbound B2B collaboration to the apps and groups that external users actually need, and add organisational settings for real partners with their own scoping.
- Decide trust deliberately. Trust partner MFA only for partners whose MFA you have assessed; trust device claims only when your Conditional Access genuinely needs them. Apply Conditional Access policies that target guest and external users, requiring MFA and, for sensitive apps, terms of use.
- Keep inbound sync off by default. Allow user synchronisation into the tenant only for tenants inside your organisation, with automatic redemption limited to those tenants, and document each one.
- Protect the settings. Require step-up authentication for cross-tenant access changes through protected actions, and make the roles that can change them eligible through PIM.
- Put guests on a lifecycle. Create a recurring access review of guests, scoped to "Guest users only", with "Inactive users (on tenant level) only" selected, "Auto apply results to resource" on, "If reviewers don't respond" set to Remove access, and "Action to apply on denied guest users" set to "Block user from signing in for 30 days, then remove user from the tenant". See the Access Reviews Guide.
Decision guidance: a small organisation with a few partners can rely on a domain allow list, admin-only invitations and a quarterly guest review. A large or multi-tenant organisation should use entitlement management with connected organisations and sponsors for external partners, reserve cross-tenant synchronisation for its own tenants, and run partner trust reviews as part of supplier management. If you also need to stop your own users signing in to unknown tenants, add tenant restrictions v2.
Common misconfigurations
- Leaving default invitation settings. Any user, including guests, can invite more guests, so access spreads beyond anyone's knowledge.
- Trusting all partners' MFA in the default policy. Trust settings in the default configuration apply to every Entra tenant in the world, not just your partners.
- Inbound sync allowed for tenants outside the organisation. This hands another organisation the ability to create and control accounts in your tenant, with credentials you do not manage.
- Assuming deleting the policy removes users. Severing a sync relationship leaves synchronised users in place; they must be unscoped and deprovisioned first.
- One-off guest clean-ups. A single purge without recurring reviews and expiry is back where it started within a year.
- Guests as group or Team owners. External owners can add further members and change sharing, outside your review cycle.
Framework mapping
| Framework | Reference | Relevant control |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-2; AC-2(3); AC-20; AC-21; PS-7 | Guest account lifecycle and disablement, use of external systems, information sharing, external personnel |
| NIST CSF 2.0 | PR.AA-05; GV.SC-07; DE.CM-03 | Entitlements reviewed, third-party risk monitored over the relationship, activity monitoring |
| MITRE ATT&CK v20 | T1199; T1078.004; T1484.002; T1136.003 | Abuse of tenant trust, cloud account use, trust modification, cloud account creation |
Practitioner checklist
- Export all guests with last sign-in, inviter and memberships; report the inactive percentage monthly.
- Restrict guest invitations to admin roles or Guest Inviter and move partner access to access packages.
- Set guest directory access to the most restrictive level unless a documented need exists.
- Scope the default cross-tenant inbound policy to required apps and groups, and add organisational settings per real partner.
- Trust partner MFA and device claims only after assessment, per partner, never in the default policy.
- Allow inbound cross-tenant synchronisation only from your own organisation's tenants, and document each.
- Protect cross-tenant settings with PIM-eligible roles and protected actions requiring step-up.
- Run recurring guest access reviews that remove inactive and denied guests automatically.
- Alert on CrossTenantAccessSettings changes, sync scope changes and invitation bursts.
- Review partner tenant trust annually as part of supplier risk management.
Standards and references
- Microsoft Learn: Cross-tenant access overview
- Microsoft Learn: Configure external collaboration settings
- Microsoft Learn: What is cross-tenant synchronization
- Microsoft Learn: Monitor and clean up stale guest accounts using access reviews
- Microsoft Learn: B2B collaboration overview
- NIST: SP 800-53 Rev 5 Security and Privacy Controls
- Vectra Research: Microsoft Cross-Tenant Synchronization attacker technique
Related NHI Mgmt Group resources: Third-Party Access Guide · Entra ID Security Guide · Contractor Identity Lifecycle Guide · Entitlement Catalogue and Application Onboarding Guide