External identity is the architecture for giving people outside your tenant controlled access to resources without turning every partner, supplier, consultant, or affiliated employee into a permanently managed internal account. Microsoft Entra supports several collaboration and multitenant patterns, and SC-300 candidates need to understand how access, trust, lifecycle, and Conditional Access fit together.
The Microsoft SC-300 scope includes external collaboration settings, inviting and managing external users, cross-tenant access settings, cross-tenant synchronization, and external identity providers such as SAML and WS-Fed. These capabilities become safer when paired with identity governance and explicit offboarding.
Choose the collaboration model before configuring trust
B2B collaboration creates an external user representation in the resource tenant so the person can access applications and Microsoft 365 resources according to policy. B2B direct connect is designed for particular cross-tenant collaboration scenarios and does not create the same local user representation. Cross-tenant synchronization automates creating, updating, and deleting B2B collaboration users across tenants.
The right choice depends on whether the relationship is an occasional guest, a strategic business partner, or multiple tenants owned by the same organization. Do not use the most automated model simply because it is available; use the one whose lifecycle and user experience match the relationship.
Control who can invite and what guests can see: External collaboration settings influence who can invite guests and how external users interact with the directory. Broad invitation rights may improve speed but can create uncontrolled guest growth. Very restrictive settings can make every partnership a central IT ticket.
Define invitation authority, guest directory visibility, allowed and blocked domains where appropriate, and ownership expectations. The important control is not merely whether a guest exists; it is whether someone can explain why the guest is present, what access was granted, and when that access should end.
Use cross-tenant access settings to express partner trust
Cross-tenant access settings let organizations define inbound and outbound collaboration policy with specific external Microsoft Entra tenants. They can influence which users and groups participate and how certain trust signals are treated across tenant boundaries.
Trust should be explicit and reciprocal where required. If one tenant expects another tenant’s authentication or device claims to satisfy policy, administrators need to understand exactly which claims are trusted and what happens when the partner changes its configuration. Partner trust is a security dependency, not just a convenience feature.
Apply Conditional Access to external access deliberately
External users can be targeted by Conditional Access, but their authentication context may originate in another tenant or identity provider. Policy design should consider which controls the resource tenant can evaluate directly and which claims it chooses to trust from the home tenant.
The existing Conditional Access remains useful: define the external population, target resource, relevant conditions, and required control. Test partner sign-ins carefully because a policy that is routine for employees can block external collaboration unexpectedly.
Use cross-tenant synchronization for multitenant lifecycle
Cross-tenant synchronization is a one-way provisioning process that can automatically create, update, and remove B2B collaboration users from a source tenant into a target tenant. It builds on the Entra provisioning engine and is especially useful when organizations operate multiple tenants and want users to collaborate without manual invitations.
The source tenant defines which users are in scope and maps attributes, while the target tenant controls whether synchronization is accepted. Because the process can deprovision users when they leave the source scope, it provides a stronger lifecycle than unmanaged duplicate accounts. Test with a small population before broad rollout.
Govern external access with access packages and reviews: Entitlement management can expose access packages to connected organizations, require approval, time-limit assignments, and review access periodically. This allows a project owner to grant a partner the exact group, application, or site access needed without giving the partner a permanent open-ended account.
When the assignment expires and no other governed access remains, the organization can apply cleanup behavior to the external account according to policy. This closes the common gap where a contractor leaves a project but the guest object and group memberships remain indefinitely.
Support external identity providers without losing governance
Organizations may configure external identity providers using supported federation protocols such as SAML or WS-Fed for specific collaboration scenarios. Federation changes where authentication occurs, but the resource tenant still needs clear authorization, Conditional Access, and lifecycle policy.
Claims from an external provider should be mapped and trusted deliberately. Attribute quality matters because group rules, access packages, or application authorization may depend on those values. A convenient federation becomes risky if nobody owns the relationship or verifies that external attributes remain accurate.
Design for mergers, subsidiaries, and partner boundaries: Multitenant organizations often need collaboration that feels internal while preserving separate tenant administration. Cross-tenant synchronization, multitenant organization features, Teams collaboration, and shared access patterns can reduce friction, but they do not erase tenant boundaries.
Decide which tenant is authoritative for each identity, which attributes can flow, where authorization is managed, and how users are removed. The Microsoft Entra ID is easier to reason about when each tenant relationship has an explicit source of truth.
Monitor the partner lifecycle, not just the initial invitation
External identity risk grows over time when guests accumulate access, partner employees change roles, or business relationships end. Review inactive external users, sign-in patterns, cross-tenant policy changes, access-package assignments, group memberships, and exceptions. Resource owners should be able to attest that access is still needed.
The core SC-300 principle is lifecycle control. Invite or synchronize the right external identity, grant only required access, enforce appropriate sign-in conditions, review continued need, and remove access automatically when the relationship ends. External collaboration is secure when the offboarding path is as deliberate as onboarding.
Distinguish authentication trust from resource authorization
An external user may authenticate in a home tenant or federated identity provider, but the resource tenant still decides what that identity can access. Trusting an MFA or device claim from a partner does not grant access to an application by itself. Group membership, app assignment, entitlement policy, and application authorization remain separate decisions.
This separation is critical during troubleshooting. A user can authenticate successfully and still be denied by Conditional Access, lack an application assignment, miss a required group, or fail the application’s own authorization. Follow the flow in order instead of assuming every access failure is a federation problem.
For security design, the separation lets organizations be flexible about authentication while remaining strict about resources. Partners can use their own identity systems, but the resource tenant can still limit which identities, apps, and entitlements are available.
Use attributes carefully across tenant boundaries
Cross-tenant synchronization can map attributes from a source tenant into target-tenant B2B users. Those attributes may later drive dynamic groups, lifecycle workflows, or access-package assignment. Decide which attributes are authoritative, which transformations are allowed, and how unexpected source values are handled.
A bad attribute mapping can scale an access error across thousands of users. Pilot synchronization, review provisioning logs, and test joiner, mover, and leaver cases before expanding scope. When an attribute becomes a security decision point, its quality and change control are part of the security architecture.
Do not synchronize more personal or organizational data than the collaboration scenario requires. Data minimization simplifies governance and reduces the impact of accidental exposure across tenant boundaries.
Make external offboarding measurable: External identity programs should track how quickly access is removed after a contract ends, a partner user leaves, a synchronized source account disappears, or an access package expires. Long-lived guest accounts with no owner are a measurable risk signal, not merely directory clutter.
Use access reviews, entitlement expiration, synchronization deprovisioning, inactive-user reporting, and application ownership to close the loop. For strategic partners, agree on responsibilities for identity changes so the resource tenant is not the last place to learn that a privileged partner employee changed roles months earlier.
The Microsoft security certifications repeatedly returns to the same theme: identity security is lifecycle security. External access is trustworthy only when onboarding, ongoing control, review, and removal are all deliberate.
External collaboration needs an exit strategy as much as an invitation process. Guest accounts and cross-tenant relationships should reflect the partner’s current business role, not remain indefinitely because access once worked. Cross-tenant access settings can establish how multifactor authentication and device claims are trusted, while entitlement management and access reviews can provide time-bounded packages and periodic recertification. The design goal is to make collaboration easy without turning every guest into a permanent exception. When a partnership ends or a user changes role, the organization should be able to identify and remove the access path without reconstructing its history from individual app permissions.
Match the external identity feature to the collaboration pattern
SC-300 scenarios often differ by one architectural clue. A one-off supplier who needs access to an application suggests ordinary B2B collaboration. Employees who must work across several tenants owned by the same enterprise may benefit from cross-tenant synchronization. A Teams shared-channel scenario can involve B2B direct connect. The feature follows the collaboration model rather than a generic desire to “share access.”
Then add governance. Decide who invites or synchronizes the user, which tenant remains authoritative, what Conditional Access applies, which resources are assigned, and how the account is removed. Cross-tenant automation reduces manual work, but it also increases the importance of correct scope because an error can provision many identities quickly.
Finally, keep external users distinct from unmanaged internal accounts. The purpose of External ID is to preserve the fact that another organization owns the identity while your tenant controls access to its resources. That separation supports clearer responsibility, safer offboarding, and more defensible audit evidence.
External collaboration should also have a business owner. Identity administrators can enforce tenant policy, but the sponsoring team is usually best placed to confirm that a partner relationship still exists. Combining technical lifecycle controls with accountable sponsorship keeps guest directories from becoming permanent archives of old projects.