Bringing an outsider into your directory is a trust decision wearing the clothes of a convenience feature. Every guest, every partner tenant, every shared channel is a small extension of your perimeter to include people whose credentials you do not issue and whose devices you do not manage. The work of external identity is not making collaboration possible, which is easy, but deciding precisely how much of someone else’s security posture you are willing to inherit as if it were your own.
This is the eleventh article in the Entra ID series. The earlier ones governed the people who belong to you. This one is about the people who do not, and the settings that decide how far into your tenant they are allowed to reach.
A guest is a reference, not a credential
The foundational fact about business-to-business collaboration is the one people forget fastest. When you invite an external user, a real object is created in your directory, marked as a guest, but it holds no credential of its own. The person authenticates against their home organization, and your tenant holds a reference that trusts that home authentication and checks the guest’s eligibility to collaborate. This is why the account cannot be secured the way an employee’s can; you are not the identity provider, you are a relying party. It also frames every subsequent decision, because what you are really configuring is how much you trust the home organization’s sign-in on your behalf.
Around that object sit the collaboration settings that decide who can even create guests and what those guests can see. The default posture lets member users and certain admin roles issue invitations, and it limits what a guest can read about your directory to a restricted view rather than the full member experience. There is a more restrictive setting available that reduces a guest’s visibility further still, and I treat moving to it as a deliberate hardening step you take rather than something the platform applies for you. Alongside it, an allow or deny list can confine invitations to specific partner domains, which is the bluntest and often the most effective control, because the cleanest way to manage a partner you will never work with is to make them un-invitable in the first place.
Cross-tenant access is where the real trust is set
The collaboration settings decide who gets in; the cross-tenant access settings decide what you believe about them once they are in, and this is where the consequential design happens. The model has two layers, a default that applies to every other Entra organization and per-organization settings that override it for a named partner, so you can be cautious by default and specific where a real relationship warrants it. Out of the box the posture is conservative in exactly the right way: collaboration is allowed, but you do not trust the other tenant’s multifactor authentication or its device claims, and the more direct forms of connection are switched off. The trust settings are the levers that change that, and they are inbound only. You can choose to accept that a guest’s home tenant already performed multifactor authentication, and to accept its assertion that the device is compliant or hybrid joined, so that your Conditional Access honors those claims instead of demanding its own.
These trust settings are genuinely useful and genuinely consequential, and both halves of that sentence matter. Trusting the partner’s multifactor authentication removes a real friction, the double prompt where a guest who already proved themselves at home is made to prove themselves again and often cannot, because they have no strong method registered in your tenant. But trusting it means accepting the partner’s identity assurance as equivalent to your own for every user you scope the setting to, and trusting their device claims means accepting their device-management posture the same way. That is a defensible decision for an organization you actually know and an act of misplaced faith for one you do not, and the blast radius is every user covered by the setting, not just the well-behaved ones. The device dimension has a hard edge worth stating plainly: external users cannot register devices with your tenant, so a compliant-device requirement simply cannot be met by a guest unless you trust the home tenant’s device claims, which means applying managed-device policy to externals without that trust does not tighten security, it just blocks them.
Trusting a partner’s multifactor authentication means accepting their identity assurance as equivalent to your own. Do it for organizations you know.
Direct connect is a different kind of trust
Business-to-business direct connect is worth separating out because it does not behave like ordinary collaboration. It is the mechanism behind shared channels in Teams, and its defining property is that no guest object is created in your directory at all. Access is governed entirely by the mutual trust the two organizations configure and by membership of the shared channel, which means the relationship is organization-scoped and channel-mediated rather than expressed as individual accounts you can see and review in your own tenant. Enabling it is a mutual act, off by default and requiring both sides to permit it, and it carries a sharper dependency on the trust settings than collaboration does: where a guest facing an unmet multifactor requirement would be challenged, a direct connect user facing the same requirement without trusted multifactor is simply blocked. It is a powerful way to let two organizations work as one inside a channel, and precisely because there are no per-user objects on your side, it demands that you understand the trust you extended at the organization level, since that trust is the whole of the control.
Cross-tenant synchronization, which automates provisioning your own people as accounts across a family of tenants you own, belongs to this same family of features but points inward rather than outward. I covered its shape in the tenant-foundations article, and the thing to carry here is only that it is push-only, moves internal members rather than guests, and is a tool for a multi-tenant organization managing itself, not a way to collaborate with a genuine outsider.
Customers are a different product entirely
One clarification prevents a genuinely expensive mistake, because the word external covers two products that share almost nothing architecturally. Everything above concerns partners and guests inside your workforce tenant. Consumer and customer identity, the sign-up and sign-in of people using an application you publish, is served by a separate configuration, an external tenant standing apart from your workforce directory with its own users and its own flows. That customer platform reached general availability a couple of years ago and is the forward path for customer-facing identity. Its predecessor, the older consumer directory product, has reached end of sale, so new customers can no longer start on it, though existing deployments are supported for years yet and have a migration path. The mistake to avoid is treating the new customer platform as a rename of the old one; they are distinct, and a project that needs customer identity should start on the current platform rather than the legacy directory it superseded.
The partners who manage you, and the objects that pile up
Two operational realities round out the picture. The first concerns managed service providers, and it is a design choice with real security weight. Inviting a provider’s staff as guests and handing them roles works, but the better model for delegated administration is granular delegated admin privileges, which give the partner least-privilege, time-bound role assignments into your tenant through security groups without creating standing guest accounts at all. When an outside party will administer your environment, that scoped and time-bound path is preferable to a pile of guest objects holding directory roles, for the same reasons the whole series has favored least privilege and just-in-time access. The second reality is quieter and catches large collaborators: guests are directory objects, and directory objects are capped. A tenant that collaborates widely accumulates guest accounts that count against the same object ceiling as everything else, which is one more reason the lifecycle cleanup from the previous article matters, since a guest whose access has lapsed but whose object lingers is consuming a slot and widening the surface for no benefit.
External identity, in the end, is a sequence of explicit trust decisions: who may be invited, what you believe about their sign-in, whether you extend the deeper connection of a shared channel, and how you let outside administrators in. Made deliberately, each one is defensible. Made by leaving defaults unexamined, they quietly widen the perimeter to include everyone your organization has ever collaborated with. The last thing the series needs to cover is how you would even know, how you watch the identity plane and see what is actually happening across all of this, which is where we go next.
Entra ID
‹ Previous: [E 10] Access Reviews and Lifecycle Workflows
Next: [E 12] Watching Identity: Sign-in Logs, Audit, and Health ›
