4.2 Cross-Tenant Access Settings
Key Takeaways
- Cross-tenant access settings define inbound and outbound B2B collaboration and B2B direct connect behavior for external Microsoft Entra tenants.
- Default settings apply to all external tenants that lack a more specific organizational configuration; organizational settings override defaults for named partner tenants.
- Inbound controls what users from other tenants can access in your tenant; outbound controls what your users can access in other tenants as guests or direct-connect users.
- Trust settings can accept MFA, compliant device, and hybrid Entra join claims from the home tenant so partners are not forced to re-satisfy those factors in the resource tenant.
- Customize per partner when a relationship needs tighter allowlisting, broader access, different trust of device/MFA claims, or B2B direct connect enablement that should not apply globally.
Cross-tenant access settings as the partner boundary
After you understand guest invitations, you need the settings that decide which external tenants may collaborate with you, in which direction, and whether you trust their MFA and device signals. Cross-tenant access settings in Microsoft Entra ID provide that control plane for B2B collaboration and B2B direct connect.
These settings complement — not fully replace — classic external collaboration settings (who can invite, guest directory visibility, domain allow/deny). Think of collaboration settings as guest lifecycle and invite posture, and cross-tenant access settings as tenant-to-tenant access and trust posture.
Default settings versus organizational settings
Cross-tenant access configuration has two layers:
| Layer | Scope | Purpose |
|---|---|---|
| Default settings | Apply to all external Microsoft Entra tenants unless overridden | Baseline inbound/outbound collaboration and direct connect posture for the world |
| Organizational settings | Apply to a specific partner tenant ID | Partner-specific allow, block, user/group scope, application scope, and trust overrides |
Evaluation idea for the exam: more specific organizational settings for a partner take precedence over defaults for that partner. Everyone else keeps the default.
Why defaults matter
If defaults allow inbound B2B collaboration broadly, any external tenant’s users might be invitible/collaborative subject to other controls. Hardening often starts by:
- Keeping outbound/inbound B2B collaboration available only as business requires.
- Leaving B2B direct connect disabled in defaults (it is more intimate connectivity).
- Adding organizational exceptions for strategic partners (shared channel partners, M&A tenants, subsidiaries not yet consolidated).
If defaults are too open, one-off partner projects inherit more access path potential than intended. If defaults are too closed, every new partner requires an organizational entry before work can start — which may be exactly what highly regulated orgs want.
Inbound versus outbound
Always read scenario language for direction:
| Direction | Question it answers | Example |
|---|---|---|
| Inbound | What can users from other tenants do in my tenant? | Fabrikam users access Contoso’s apps as Contoso guests |
| Outbound | What can my users do in other tenants? | Contoso users join Fabrikam tenants as guests or use direct connect |
You can allow inbound collaboration from a partner while blocking outbound so your employees cannot accept arbitrary external guest relationships — or the reverse. Directionality is a classic SC-300 discriminator.
B2B collaboration in cross-tenant settings
For B2B collaboration, inbound/outbound settings typically express:
- Whether collaboration is allowed or blocked for that direction.
- Which users/groups from the external tenant (inbound) or your tenant (outbound) are in scope — all users versus only selected groups.
- Which applications are accessible — all applications versus only selected apps (where the setting model supports application scoping).
This is how you implement “only the Partner-Project-A security group from Fabrikam may access only AppX and AppY in Contoso,” rather than opening the entire tenant relationship.
B2B direct connect (concepts)
B2B direct connect is a cross-tenant connectivity model designed for seamless collaboration scenarios such as shared channels in Microsoft Teams with external participants, without always using the classic guest object experience the same way B2B collaboration does.
Conceptual differences useful for SC-300:
| Aspect | B2B collaboration | B2B direct connect |
|---|---|---|
| Primary mental model | Invite external user as guest in resource tenant | Cross-tenant connection for specified scenarios (for example Teams shared channels) |
| User object pattern | Guest user object commonly present in resource tenant | Connection-oriented; not identical to classic guest invite lifecycle |
| Configuration | Collaboration + cross-tenant inbound/outbound collaboration settings | Must be explicitly enabled in cross-tenant access (often blocked by default) |
| Trust | Trust settings for MFA/device claims still relevant | Also governed by cross-tenant access organizational configuration |
| Typical use | Apps, SharePoint, classic guest access | Tight partner collaboration experiences like shared channels |
Exam bias: if the scenario emphasizes Teams shared channels with an external organization, look for B2B direct connect and organizational cross-tenant settings for that partner tenant — not only “send a guest invite CSV.”
Both sides of a direct-connect relationship generally need compatible configuration. One tenant enabling outbound direct connect does not magically force the partner to accept inbound direct connect.
Trust settings (MFA, compliant device, hybrid join claims)
When external users access your resources, your Conditional Access policies may require MFA or compliant / hybrid-joined devices. Without trust, partners might be challenged again in the resource tenant even if they already satisfied strong authentication and device posture at home.
Trust settings in cross-tenant access let the resource tenant accept claims from the home tenant:
| Trust option | Effect when enabled for a partner |
|---|---|
| Trust multifactor authentication | Honor MFA performed in the user’s home tenant so resource CA MFA grants can be satisfied by home MFA claims |
| Trust compliant devices | Honor device compliance claims from the home tenant’s device management |
| Trust Microsoft Entra hybrid joined devices | Honor hybrid join device claims from the home tenant |
When trusting is good
- Strategic partners with mature Conditional Access and Intune (or equivalent) posture.
- Reducing friction for executives collaborating across subsidiaries in a multi-tenant organization.
- Aligning with Zero Trust while avoiding double prompts that drive shadow workarounds.
When to be careful
- You do not know the partner’s MFA strength or device compliance quality.
- Partners allow weak second factors or lack device management.
- Regulatory requirements demand your tenant re-evaluate controls rather than defer to home claims.
Trust is typically configured per organizational partner (and may appear in defaults carefully). Blindly trusting MFA/device claims from all external tenants in defaults is rarely the secure baseline.
Customizing per partner tenant
Create organizational settings when the partner relationship differs from your global default.
Common customization triggers
- M&A or multi-tenant org — broader inbound/outbound access and trust of MFA/device claims between corporate tenants.
- High-risk vendor — inbound collaboration limited to one group and few apps; do not trust device compliance.
- Teams shared channels — enable B2B direct connect only for that partner organization, keep it blocked in defaults.
- Block a problematic tenant — organizational block overriding a more open default.
- Outbound lockdown — prevent your users from accepting guest invites from untrusted tenants while still allowing inbound customers you carefully invite.
Configuration workflow (conceptual)
- Identify partner tenant ID (not only vanity domain — domains can be ambiguous; tenant ID is precise).
- Add organizational settings for that tenant.
- Set inbound B2B collaboration (users/groups, applications, allow/block).
- Set outbound B2B collaboration as business requires.
- Configure B2B direct connect inbound/outbound only if needed.
- Set trust for MFA / compliant device / hybrid join deliberately.
- Validate with a pilot user: invite/redeem or shared channel path, then review sign-in logs and CA results.
- Document owners and review cadence — partner access is not set-and-forget.
Interaction with other controls
Cross-tenant access settings do not eliminate the need for:
- External collaboration settings (invite permissions, guest visibility, domain allow/deny).
- Conditional Access (grant/session controls for guests and partner access).
- Entitlement management / access packages for joiner packages and expiration.
- Access reviews for continued need.
- Application assignment and least-privilege app roles.
A partner allowed by cross-tenant settings still fails if CA blocks them, if they lack group assignment, or if SharePoint sharing is disabled. SC-300 scenarios often require picking the correct missing control, not enabling everything.
Scenario patterns to memorize
| Scenario | Likely setting focus |
|---|---|
| “Only Contoso tenant users from group G may access App A in Fabrikam” | Organizational inbound B2B collaboration scoping users/apps |
| “Stop our employees from joining random external tenants as guests” | Tighten outbound B2B collaboration defaults or use selective outbound allows |
| “Shared channel with Partner X” | Organizational B2B direct connect for Partner X |
| “Partners keep getting MFA prompted though home tenant already enforced MFA” | Enable trust MFA from that partner organization |
| “Accept partner compliant devices for CA” | Trust compliant device claims for that org; ensure CA still designed correctly |
| “Default locked; open one subsidiary fully” | Keep strict defaults; broad organizational override for subsidiary tenant |
Exam traps
- Confusing inbound (them → you) with outbound (you → them).
- Editing defaults when the requirement is a single partner exception (or the opposite).
- Enabling B2B direct connect globally in defaults for one Teams project.
- Expecting trust settings to replace Conditional Access rather than satisfy specific grant conditions via accepted claims.
- Using domain name alone without ensuring the correct tenant ID in organizational settings.
- Forgetting both tenants may need coordinated configuration for direct connect.
What is the relationship between default cross-tenant access settings and organizational cross-tenant access settings?
Contoso wants Fabrikam employees to access Contoso apps as guests, but Contoso employees must not be able to accept guest access into Fabrikam. Which directional focus is required?
A resource tenant enables trust of multifactor authentication claims from a partner organization. What is the intended effect?
Which scenario most clearly calls for enabling B2B direct connect in organizational cross-tenant access settings rather than relying only on classic guest invites?