A partner tenant can become a trusted access path long before anyone notices it. One permissive default setting, an outdated guest group, or an unreviewed cross-tenant synchronization job can give external identities more reach than your security model allows.
A disciplined Entra cross-tenant access audit identifies those risky paths before they become an incident, an audit finding, or an offboarding failure. The work spans Microsoft Entra ID cross-tenant access settings, Conditional Access, guest lifecycle controls, partner records, and sign-in evidence. Whether you are managing connections with external Microsoft Entra organizations or standard B2B collaboration, this checklist helps you secure your environment without treating every external connection the same.
Key Takeaways
- You must evaluate inbound and outbound controls independently, as each direction requires its own dedicated review process.
- Default settings deserve as much scrutiny as partner-specific organizational settings because defaults apply to every unlisted external tenant across your B2B collaboration environment.
- Trust settings allow you to accept external claims such as multifactor authentication and device compliance, but these configurations do not replace the need for robust Conditional Access policies.
- Cross-tenant synchronization requires tight scoping, consistent credential oversight, and recurring checks to prevent unexpected provisioning behavior.
- Every approved partner tenant needs a documented business owner, purpose, data scope, review date, and offboarding path to maintain a secure posture.
Establish the Audit Scope Before Opening Entra
Start by defining what counts as an external relationship in your environment. Microsoft Entra cross-tenant access settings govern collaboration between your tenant and other Microsoft Entra tenants. They specifically apply to B2B collaboration and B2B direct connect, while cross-tenant synchronization introduces its own provisioning controls for identity providers.
Don’t limit the review to well-known suppliers. Include subsidiaries, merged companies, managed service providers, joint ventures, customer tenants, and test tenants. External Microsoft Entra organizations that began as a short proof of concept may still have active organizational settings years later.
The Microsoft overview of Entra cross-tenant access distinguishes between default settings and organizational settings. That distinction should shape the audit. Default settings catch every tenant without an explicit configuration. Organizational settings create exceptions, often for trusted partners or high-value collaboration scenarios.
Build an approved-partner register before reviewing technical settings. At minimum, capture the external tenant’s verified tenant ID, legal organization name, technical contact, internal business owner, collaboration purpose, data classification, allowed applications, approval date, and scheduled review date.
Tenant display names are not reliable identifiers. Names can change, and different organizations can use similar names. The tenant ID belongs in the register, change tickets, evidence files, and exception approvals.
Treat each external tenant ID as a security boundary. A familiar company name is not evidence that its tenant should receive trusted access.
Also identify who owns the review. Identity teams can inspect policy configuration, but procurement, legal, data owners, and application owners may need to validate the business purpose. Without that confirmation, technical teams often preserve access because nobody can confidently approve its removal.
The 2026 Entra Cross-Tenant Access Audit Checklist
Review the Default settings first, then compare every Organizational settings entry against the approved partner register. Record the current state, policy owner, evidence source, and remediation ticket for every failed item.
| Audit item | How to verify | Risk if misconfigured | Recommended action |
|---|---|---|---|
| Default inbound B2B collaboration policy | In the Microsoft Entra admin center, check Inbound access settings for B2B collaboration users, groups, and applications. | Unlisted tenants may access apps or resources under a broad default allowance. | Limit inbound access to required users and groups. Use partner-specific rules for exceptions. |
| Default outbound B2B collaboration policy | Review Outbound access settings for B2B collaboration, checking if all users can collaborate with external tenants. | Users may join external tenants that have not passed business or security review. | Restrict outbound collaboration where policy requires it. Allow approved groups or tenants where possible. |
| Partner-specific organizational settings | Compare each organization listed under Organizational settings with the approved partner register. | Old suppliers, test tenants, or duplicated entries can retain access without a current business need. | Remove unapproved tenants. Set a recurring review date for every remaining entry. |
| Inbound B2B direct connect | Review Inbound access settings for each partner’s B2B direct connect configuration and scope. | External users may enter Teams shared channels under a broader scope than intended. | Restrict to named partner tenants, approved groups, and approved Teams use cases. |
| Outbound B2B direct connect | Inspect Outbound access settings for B2B direct connect rules for users, groups, and partner organizations. | Internal users may access shared channels in unapproved external tenants. | Limit outbound access to business-approved groups and documented partner tenants. |
| Cross-tenant trust settings | For each partner, inspect Trust settings for multifactor authentication, compliant devices, and hybrid Microsoft Entra joined devices. | Trusting weak or unverified external claims can weaken local access decisions. | Enable claim trust only after partner assurance review. Require local controls when assurance is insufficient. |
| Conditional Access coverage | Review Conditional Access policies that target Guest users, applications, device requirements, and authentication strength. | A cross-tenant policy may allow a connection that Conditional Access does not properly control. | Apply Conditional Access to the resource and risk level. Exclude only documented break-glass accounts. |
| Guest invitations and external collaboration | Review invitation settings, including automatic redemption and redemption order for external identity flows. | Broad invitation rights create unmanaged guest accounts and exposure to consumer or unapproved domains. | Limit invitations to approved roles or groups. Maintain domain restrictions when they fit the business model. |
| Guest access reviews | Inspect active access reviews for guest users, groups, and privileged roles. | Guest access can persist after projects, contracts, or employment relationships end. | Run recurring reviews for sensitive groups and applications. Remove denied or unreviewed access promptly. |
| Cross-tenant synchronization | Review each Cross-tenant synchronization configuration, including scope filters, provisioning logs, and quarantine events. | Broad scoping can create or update external accounts at scale without intended authorization. | Scope to approved users or groups. Validate lifecycle ownership and alert on provisioning errors. |
| Application assignments | Review enterprise applications with guest assignments, external user access, and delegated permissions. | A guest may retain access to SaaS data after group membership or a project changes. | Remove obsolete assignments. Require application owners to attest to external access. |
| Sign-in and audit log monitoring | Query Entra sign-in logs for external users, access types, and target applications. | Unauthorized policy changes or anomalous partner sign-ins may go unnoticed. | Send logs to Microsoft Sentinel or your SIEM. Alert on cross-tenant policy changes and high-risk sign-ins. |
| Emergency and privileged access | Review guest accounts, external identities, and synchronized accounts assigned to privileged Entra roles. | External identities can gain tenant-wide administrative reach. | Avoid standing external privileges. Use Privileged Identity Management, approval, MFA, and time-bound activation. |
The table identifies the control points, but the audit should not end with a configuration export. Each entry needs a decision: retain, restrict, remediate, or remove. An allow all setting can be appropriate for a low-risk collaboration environment, but it requires a documented owner and a clear reason.
Review Inbound and Outbound Access Separately
Inbound access settings control what identities from another tenant can do in your environment, while outbound access settings govern what your own users can do when interacting with external resources. These directions answer different risk questions and should never share a single approval by default.
For B2B collaboration, review which external users or groups can access your applications. Broad inbound access settings may be acceptable for low-risk Microsoft 365 collaboration, yet they rarely fit finance systems, engineering repositories, or privileged administration tools.
Outbound access settings deserve equal attention. Your users can expose company data when they access resources in a destination tenant. A user who joins an unapproved external tenant may share files, participate in Teams shared channels, or grant that organization visibility into identity metadata. In this relationship, your organization acts as the home tenant for the user, while the external environment functions as the resource tenant.
B2B direct connect requires extra care because it supports shared channels in Microsoft Teams without creating a traditional guest account in the resource tenant. The B2B direct connect guidance explains the model and its relationship to Teams shared channels.
Keep direct connect approvals narrow. Document the specific partner tenant, internal group, Teams use case, data classification, and owner. General permission for an entire partner workforce is a tenant-specific policy choice, not a safe baseline.
Microsoft Entra evaluates your cross-tenant access policy before the collaboration experience proceeds. However, resource-level permissions still matter. A cross-tenant allow rule does not grant access to every SharePoint site, team, enterprise application, or Azure resource. Application owners must still control authorization inside their individual services.
Validate Trust Settings Against Zero Trust Principles
Trust settings often receive less attention than allow and block rules, but they deserve rigorous scrutiny. Microsoft Entra allows you to configure trust settings to accept multifactor authentication, device claims, and hybrid joined devices from another tenant. While these trust settings can streamline user experiences by reducing repeated prompts for external users, they effectively outsource identity assurance to an external environment.
The Microsoft guidance for B2B collaboration trust settings makes an important distinction: accepting an external claim for multifactor authentication does not inherently satisfy your local security requirements. Instead, your Conditional Access policies remain the final authority, determining whether the target application requires further verification, device compliance, or other controls.
Review the partner’s security posture before enabling any trust option. Confirm who administers that tenant, whether they enforce strong multifactor authentication, and how they manage compliant devices. You should obtain this confirmation through a formal, documented security review rather than an informal email thread.
Zero Trust architecture mandates that access decisions must evaluate identity, device, application, location, risk, and session context. When you rely on external signals, cross-tenant trust provides inputs for these decisions, but it should never replace local Conditional Access policies.
For high-sensitivity applications, prefer applying local requirements, such as specific authentication strengths, checks for compliant devices, session restrictions, and user risk conditions. Because these are tenant-specific policy decisions, you must document the rationale and the approving authority for each configuration.
Avoid a common error: enabling trust for a partner and assuming every external user has automatically met your organizational standard. A claim only provides genuine value if your security team fully understands and accepts the partner’s internal compliance policies.
Apply Least Privilege to External Identities
Applying the principle of least privilege starts with scope. Guest users should be assigned through groups tied to a specific project, application, or data set. Avoid direct assignment to broad Microsoft 365 groups, all-company Teams, administrative units, or enterprise applications that grant expansive permissions.
Group naming should make the relationship clear to auditors. A label such as Partner-Contoso-Project-Orion-Read tells reviewers far more than a generic title, helping ensure that guest users are only granted the specific access required for their work. The group owner should be an internal employee who can confirm whether the relationship remains active.
Privileged roles require stricter governance. External identities should not hold standing Global Administrator, Privileged Role Administrator, Application Administrator, or Azure Owner assignments unless a documented exception requires it. Even in those rare cases, use Microsoft Entra Privileged Identity Management for eligible, time-bound access that includes approval workflows and strong authentication.
Regularly audit external identities that own applications, service principals, Azure subscriptions, resource groups, or privileged groups. Ownership can provide indirect administrative power even when the user has no explicit directory role. A guest who owns an enterprise application, for example, may influence assignments or settings depending on the permissions granted.
Access reviews are the practical enforcement mechanism for maintaining these controls. The Microsoft Entra access reviews overview covers how to manage reviews for group and application membership. For sensitive collaboration groups, assign reviewers who understand the project and can identify dormant access.
Set your review cadence based on risk. A monthly review may fit high-value data or privileged access, while a quarterly or semiannual review may be sufficient for lower-risk partner collaboration. Expiration dates, inactivity, contract end dates, and project milestones can all trigger an earlier review to ensure access remains relevant.
Audit Cross-Tenant Synchronization as a Provisioning System
Cross-tenant synchronization is distinct from standard B2B invitations. Because cross-tenant synchronization functions as a powerful provisioning system, it can automatically provision, update, and deprovision B2B collaboration users across tenants. While this functionality is ideal for structured multi-tenant organizations, it also increases the impact of an improperly defined scope rule.
Review every synchronization configuration within the source tenant. Confirm the target tenant ID, configuration owner, provisioning scope, attribute mappings, assigned users or groups, and the accidental deletion threshold. Carefully check the provisioning logs for errors, skipped users, unexpected creations, and quarantine events.
A synchronization job should always serve a clearly defined business purpose. A generic label like “Corporate affiliate access” is insufficient. Your internal register should identify the source population, target applications, expected user count, deprovisioning rules, and the designated owner in both tenants. As part of your audit, investigate the consent prompt experience for synchronized users. By configuring appropriate trust settings, administrators can suppress the consent prompt for trusted partners, ensuring a seamless experience for those guest identities.
Credential management is also a critical component of your review. Audit the authorization, consent, and administrative ownership for each configuration. Remove former administrators, rotate credentials according to your organizational policy, and investigate any configuration that lacks a current owner.
Before changing a production scope, test the configuration with a small group and confirm the results in both tenants. A broad group assignment can inadvertently create thousands of guest objects. Cleanup is time-consuming, and downstream applications may have already processed those identities before you can revert the changes.
Collect Evidence That Survives the Next Audit
Screenshots help during a review, but they age quickly. Pair them with exported policy data, timestamps, reviewer names, ticket references, and a written decision. Keep evidence in a controlled repository that compliance teams can access without relying on an individual administrator’s mailbox.
Microsoft Graph supports programmatic inspection of cross-tenant access policies through the crossTenantAccessPolicy resource. Use API exports to compare current settings with a known approved baseline. A repeatable export also helps detect configuration drift after mergers, partner onboarding, or administrative changes. When managing complex Microsoft cloud settings across multi-cloud environments, these automated exports become essential for maintaining a unified security posture.
Log review should cover both successful and failed external sign-ins. Failed attempts can reveal partners using unsupported devices, missed policy communication, or attempts from tenants that should not have access. In addition to monitoring tenant restrictions to prevent unauthorized outbound data exfiltration, ensure you audit events related to cross-tenant policy updates, enterprise application assignments, group membership, and role changes. Regularly reviewing these cross-tenant access policies ensures that external identity lifecycles remain aligned with your security requirements.
A useful evidence package includes:
- The approved partner-tenant register with tenant IDs and review dates.
- Cross-tenant default and organizational-setting exports.
- Conditional Access policy evidence for external identities and protected applications.
- Guest, group, application, and role access-review results.
- Cross-tenant synchronization configuration and provisioning-log extracts.
- Remediation tickets with accountable owners and closure dates.
Set a formal review interval, then add event-driven reviews. A merger, supplier termination, new Teams shared-channel rollout, major application onboarding, or security incident should trigger a targeted cross-tenant access assessment.
Common Findings That Need Immediate Attention
Some findings should move directly into remediation rather than wait for the next quarterly meeting. One example is an organizational setting for a tenant that has no business owner or contract record. You must proactively vet these external Microsoft Entra organizations to ensure every connection serves a valid business purpose. Another high-risk finding is a guest account with privileged directory or Azure access.
Broad default inbound rules also need attention when sensitive applications rely on weak resource-level permissions. Review the complete path: cross-tenant access policy, Conditional Access, application assignment, group membership, and in-app authorization. A strong policy at one layer cannot repair weak controls at another.
Trusting partner MFA claims without an assurance decision is another common gap. A secure mutual trust relationship requires you to either document why the partner’s MFA control meets your standard or require your own Conditional Access challenge for the application. The same review applies to compliant-device and hybrid-joined-device claims.
Finally, investigate synchronization configurations that target dynamic groups with changing membership. The scope can expand without anyone editing the sync job. Group ownership, membership rules, and provisioning logs all need monitoring.
Frequently Asked Questions
How often should we conduct a cross-tenant access audit?
At a minimum, organizations should perform a comprehensive review of all external tenant relationships and policy settings on a quarterly basis. However, event-driven reviews should occur immediately following significant changes, such as organizational mergers, the termination of a supplier contract, or the deployment of a new shared-channel collaborative workflow.
Does trusting a partner’s MFA claim satisfy my local compliance requirements?
Accepting an external MFA claim reduces friction for the user but does not automatically meet your specific security standards. You must first conduct a formal assurance review of the partner’s security posture and ensure your local Conditional Access policies remain the final authority for granting access to sensitive resources.
Why should we document business owners for every external tenant?
Technical teams often struggle to remove external access because they lack the business context to determine if a relationship is still active. Assigning an internal business owner ensures there is an accountable party responsible for confirming the ongoing necessity of the access and initiating offboarding when the partnership concludes.
Can we rely on default settings for all external partners?
Default settings are intended as a baseline and should not be used as a permanent solution for established business partners. It is best practice to move known, recurring partners into organizational settings where you can apply specific, narrow policies tailored to their actual requirements.
Conclusion
A strong Entra cross-tenant access audit treats every partner tenant as a defined, reviewable relationship. Every mutual trust relationship, organizational exception, trust setting, application permission, and provisioning job requires clear evidence and a named owner.
To effectively manage third-party risk involving external Microsoft Entra organizations, you must maintain a current partner register tied to narrow policy scopes and recurring access reviews. Whether acting as the resource tenant providing access or the home tenant managing user identities, the goal remains the same: when a partnership no longer has a documented purpose, that access should be terminated immediately.
