3.3.1. B2B Collaboration and External Collaboration Settings
💡 First Principle: An invitation is a controlled tenant-boundary crossing: your side issues it, their side authenticates it, and the resulting guest object carries your policies (CA, MFA, reviews) while their side keeps the credentials. Every setting in this area tunes who may open that door and how far.
The flow: invite (portal, bulk CSV, Graph, or app-driven like Teams/SharePoint sharing) → email with redemption link → guest authenticates against their home identity per the fallback ladder → guest object (userType = Guest) appears with #EXT# UPN → you assign access (groups, apps, roles) like any principal. Redemption is once; thereafter the guest signs in directly.
External collaboration settings (Entra ID → External Identities) are the guardrails: who can invite (admins only → members → all users including guests — least-privilege stems narrow this), guest user access level (full member-like read → limited default → restricted, where guests see only their own objects), collaboration restrictions (allow-list or deny-list of target domains for invitations), and self-service sign-up via user flows for apps. Guests are subject to your CA policies — requiring MFA for guests is standard (see 3.3.2 for whether their home MFA can count).
⚠️ Exam Trap: Restricting who can invite is a different lever from restricting which domains can be invited. "Only allow collaboration with contoso.com" → collaboration restrictions (domain allow-list); "only the partnerships team may invite" → invite settings (and consider entitlement management instead, Phase 5, for governed self-service).
Reflection Question: Why does B2B redemption falling back to email one-time passcode matter for coverage — and what does it imply about which partners can't be excluded by purely technical means?
