Who Did YouLet In?

Think about the different people who show up at your front door and how differently you treat each one. Your best friend walks in without knocking. A contractor arrives in a marked van with a work order. A stranger knocks and you look through the peephole before deciding. You already make risk-based trust decisions every single day.

The problem is most Entra tenants don't. Once a guest account lands in the directory, it's often treated the same regardless of who they are, where they came from, how strong their home tenant's security posture actually is, or whether they should still have access at all.

Before any configuration discussion, the trust model needs to be right. Guest accounts in Entra map directly to the kind of risk decisions you make at your front door every day.

The challenge is that Entra surfaces six distinct external user types, and they behave fundamentally differently in how they authenticate, where MFA completes, and what CA policy controls are safe to apply. Most tenants treat all six identically. That's where the gaps start.

When you configure a Conditional Access policy and select "Guest or external users," the portal gives you six checkboxes. Most admins check all of them and move on. That's a mistake. The populations behind those checkboxes behave fundamentally differently, and applying the wrong grant control silently blocks users instead of prompting them for MFA.

This is where the contractor analogy gets sharp. When you enable Trust MFA from home tenant in Cross-Tenant Access Settings, you're not just trusting the person. You're trusting the entire security posture of the tenant that issued their credential. The van looks right. The uniform looks right. But you don't know what's inside.

Most tenants run one guest CA policy. The right answer is two. Because b2bCollaborationGuest is a mixed population — Entra-backed AND non-Entra guests all land in the same bucket — applying authentication strength to it silently blocks non-Entra guests instead of prompting them for MFA.

Your best friend still has a key to your house from a project three years ago. You forgot they had it. They forgot they had it. But technically, they could still walk in.

This is the stale guest problem, and it exists in almost every tenant. The project ended, the contract finished, the partnership went quiet — but the accounts stayed. No one owns the offboarding. Nobody is watching the door after the visit ends.

The questions most organizations cannot answer: Who invited this guest? Does that person still work here? Is there a process for cleanup when the relationship ends? In most tenants, at least one of those answers is unknown.

The people you let into your house aren't all the same, and your security posture for external identities shouldn't treat them like they are. Guest identity is where the "identity is the perimeter" principle gets stress-tested by people entirely outside your control.

Getting this right means understanding what type of credential you're actually trusting, whether that trust is still warranted given the partner's security posture, and whether anyone owns the process for showing guests the door when the relationship ends.

This connects directly to everything else in this series. The CA policies that govern your own users have gaps when external identities enter the picture. The authentication methods you've invested in for your workforce don't automatically carry over. And groups, which we'll cover in the final post, are where guest access gets scoped and where the gaps compound when membership isn't maintained.