Microsoft Entra External ID and Customer Identity
In this article
Summary
Microsoft renamed a lot of identity terminology over the past few years, and "External ID" is where most of the confusion lands. External ID isn't one feature — it's an umbrella covering two genuinely different scenarios. External ID for your workforce is what powers B2B collaboration and cross-tenant access: partners, vendors, and contractors getting into your existing tenant as guests. External ID for customers, CIAM, the subject of this Byte, is for people who have no employment relationship with you at all: shoppers, account holders, app users. They get their own external tenant, separate from your workforce directory, purpose-built for sign-up and sign-in at scale. If you've worked with Azure AD B2C before, External ID for customers is its successor: B2C stopped selling to new customers on May 1, 2025, and Microsoft Entra External ID is where all new CIAM investment is going.
The Three Building Blocks: Tenant, Flow, Brand
Every CIAM setup, no matter how complex it eventually gets, is built from the same three pieces.
- External tenant: A Microsoft Entra tenant created specifically for customer identities, entirely separate from your workforce tenant. This isn't optional hygiene; it's the boundary that keeps a customer account from ever touching internal resources.
- User flow: The configured sequence of steps a customer follows to sign up or sign in: which authentication methods are offered, what information gets collected, and what happens after. An app links to exactly one user flow, though a single flow can serve many apps.
- Company branding: The logo, colors, background image, and text that make the sign-up and sign-in pages look like your product instead of a generic Microsoft page. Branding lives at the tenant level and is pulled in by the user flow.
Nail these three, and everything else, social providers, custom domains, native authentication APIs, is a refinement on top, not a rebuild.
Choosing Sign-Up Methods: Email, One-Time Codes, and Social Identity
External ID supports several ways for a customer to prove who they are, and you choose which ones your user flow offers. Email and password is the most familiar option, and still the most common default. A one-time passcode sent by email removes the password entirely, trading a small amount of friction per sign-in for one less credential to leak. Social identity providers (Google, Facebook, Apple, or a custom OpenID Connect provider) let customers reuse an account they already trust, which measurably reduces sign-up abandonment. And for the security-conscious, passwordless methods including passkeys (FIDO2/WebAuthn) and the Microsoft Authenticator app are available even in a customer-facing flow. Most production setups offer at least two options: one password-based or passwordless method, plus one social provider, so customers pick whichever they already have set up.
Keep 'Em Separated
It's tempting, especially in a small organization, to add customer accounts to the same tenant you already use for employees, one less thing to manage, right? Resist it. A workforce tenant is governed by Conditional Access policies, role assignments, and licensing built around employees; a customer account dropped into that same directory either inherits protections it doesn't need or, worse, ends up with a path toward resources it should never reach. External ID's external-tenant model exists specifically so this separation is structural, not a policy you have to remember to configure correctly. Two audiences, two tenants, always.
Conclusion
Customer identity doesn't have to be an afterthought bolted onto your workforce tenant, External ID for customers gives it a proper home, built for scale and branded from the first click. Once your external tenant, user flow, and branding are in place, the same three-part model extends to every future customer-facing app.