Microsoft Entra External ID Primer (2026 Edition) — How It Differs from Workforce Entra ID, Architecture, and App Integration

Why I Wrote This Article

When you use Azure, an Entra ID tenant quickly becomes part of the foundation. Azure subscriptions are associated with a tenant, and Microsoft 365 runs on that same tenant. When building an internal system, it is therefore natural to conclude, “We can use Entra ID for authentication.”

That changes as soon as you build a service for users outside your organization.

• You cannot issue company accounts to customers
• You may want users to sign up with only a Google account or email address
• You do not want consumer accounts mixed into the employee directory

This is where Azure AD B2C and Microsoft Entra External ID come in. Their relationship can be confusing: the names are similar, and it is reasonable to wonder what will happen to B2C.

This article starts with the difference between Entra ID for the workforce and External ID for external users, then uses official documentation to explain the purpose of External ID, how to configure it, and how applications use it.

Table of Contents

• First, Clarify: An Entra ID Tenant Is the “Internal Container”
• There Are Two Ways to Bring in External Users
• B2B Collaboration: Invite Guests to Your Tenant
• The Relationship Between Azure AD B2C and External ID
• What External ID Is For
• Configuration Option 1: Create an External Tenant
• Configuration Option 2: Configure Sign-In Methods and User Flows
• Using External ID from an Application
• How Pricing Works
• Selection Checklist
• Summary
• Official Sources

First, Clarify: An Entra ID Tenant Is the “Internal Container”

First, let us clarify the role of the Entra ID tenant you already use.

According to the official documentation, every Azure subscription has a trust relationship with one Entra ID tenant. The subscription uses that tenant, or directory, to authenticate and authorize security principals and devices.

The relationship is asymmetric:

• A subscription can trust only one directory
• A tenant can be trusted by multiple subscriptions

Their responsibilities are also distinct.

Microsoft 365 and Intune also run on an Entra ID tenant. The official documentation calls the tenant configuration used to manage employees, internal business applications, and organizational resources a workforce tenant. This is the familiar tenant that is created automatically when you sign up for services such as Azure, Intune, or Microsoft 365.

In a typical environment, Azure, Microsoft 365, and internal applications are consolidated in the same workforce tenant. That structure is why Entra ID is a natural authentication choice for internal applications.

There Are Two Ways to Bring in External Users

How, then, should you handle users outside the organization? This is where Microsoft Entra External ID enters the picture.

External ID is not a single feature. It is a set of solutions for working with people outside your organization. The intended scenario depends on which tenant configuration you use.

Two points matter most.

First, you do not need a new tenant to collaborate with business partners. Use B2B collaboration in your existing workforce tenant and invite partners as guests. The next section covers this option in detail.

Second, to make your applications available to consumers or business customers, create a new tenant with an external configuration. The official documentation states that the first resource to create when using External ID for customer-facing applications is an external tenant. This tenant is separate from your workforce tenant.

Another practical distinction is that users in an external tenant have restricted default permissions. Accounts created when customers sign up do not receive the same directory permissions as employee accounts.

⚠️ External tenants do not support SSO to Microsoft SaaS applications such as Microsoft 365. Treat an external tenant as an authentication platform for your own applications, not as a replacement for a workforce tenant.

B2B Collaboration: Invite Guests to Your Tenant

Before focusing on external tenants, consider the other option. In many real-world scenarios, B2B collaboration is enough.

B2B collaboration lets you invite people outside your organization to your workforce tenant as guests so they can use your applications and services. The official documentation describes it as a way to share applications and services with external guests while retaining control of your own data. Guests do not need to have Microsoft Entra ID or an IT department.

From Invitation to Access

The process is as follows:

1. Invite: An administrator invites a guest from the Entra admin center. The invitation can apply to a directory, group, or application. When invited, the user is added to Entra ID with the Guest user type
2. Redeem: The guest follows the redemption URL in the invitation email or a direct link to the shared application. Invitations do not expire
3. Consent: During the first redemption, the guest must accept the privacy statement and terms of use. The consent status changes from PendingAcceptance to Accepted
4. Use the application: The guest signs in to the shared application with their own credentials

A user object is created in your directory, and its UPN contains the #EXT# identifier.

What Guests Can Access

This is directly relevant to the main question. B2B collaboration can share your own applications as well as Microsoft applications. The official comparison table lists the resources available through External ID as Microsoft applications or your own applications, including SaaS and custom-developed applications.

B2B collaboration therefore covers scenarios such as:

• Letting a contact at a partner company sign in to your custom line-of-business application
• Sharing documents with a partner through SharePoint or Teams
• Giving a contractor access to only part of an internal portal

How Invited Guests Sign In

Guests can sign in with the identity they already use. Supported identity providers include:

• Microsoft Entra account: For guests whose organization also uses Entra ID. This is allowed by default and requires no additional configuration
• Microsoft account (MSA): A personal Microsoft account
• Email one-time passcode: For guests who have neither of the preceding account types. It is enabled by default for new tenants
• Social identities such as Google: When allowed by a self-service sign-up user flow
• SAML / WS-Fed federation: When the guest organization has its own identity provider

If more than one method is available, use the redemption order in Cross-tenant access settings to control priority. Those settings also control which tenants can participate in B2B collaboration with your tenant.

Management and Billing

• Guests are managed in the same tenant as employees and are normally identified as guests. They can also be added to the same groups as employees
• In addition to invitations, you can use a self-service sign-up user flow to let guests register themselves
• Billing uses the same MAU model as External ID. Users whose UserType is Guest are included; users whose UserType is Member are excluded
• Policies such as Conditional Access are evaluated in the tenant that owns the resource, which is the inviting tenant

Choosing Between B2B Collaboration and an External Tenant

A simple rule of thumb is to ask: Is this person a business collaborator or a customer of your service? Start with B2B collaboration for the former and consider an external tenant for the latter.

The Relationship Between Azure AD B2C and External ID

This is probably the most common question. Here is what the official documentation says as of July 2026.

No New Purchases, but Existing Customers Can Continue

• As of May 1, 2025, Azure AD B2C is no longer available to purchase for new customers
• Existing Azure AD B2C customers can continue using the product
• The product experience remains unchanged, including the ability to create new tenants and user flows
• However, new tenants can be created only with Azure AD B2C P1
• Azure AD B2C P2 was retired for all customers on March 15, 2026
• Operational commitments for SLAs, security updates, and compliance remain unchanged
• Support will continue until at least May 2030

In addition, Azure AD External Identities P2 has been retired in Azure AD B2C tenants, so P2-only features are unavailable. P2 tenants were to be moved to P1 in stages by the end of March 2026 and billed at P1 rates. The documentation treats the P2 retirement and the end of new B2C sales as separate changes.

For New Deployments, Use External ID

The situation can be summarized as follows:

• You already use B2C: It is not shutting down immediately, so you have time to plan a migration
• You are building something new: An External ID external tenant is the default choice

The official documentation provides migration guidance for moving from B2C to External ID. It also acknowledges feedback that B2C custom policies are “too difficult to build and manage.” Microsoft is simplifying the new External ID platform so that custom policies are unnecessary and plans to provide a migration path for existing custom policies.

💡 The naming history can be confusing. The former Azure AD B2B collaboration is now positioned as part of External ID, under the name External ID B2B collaboration. It is still managed in the Entra admin center within a workforce tenant.

What External ID Is For

With that distinction in mind, choose an External ID external tenant when:

• You want to offer your SaaS or mobile application to consumers or business customers
• You want customers to sign up through self-service
• You want customers to sign in with an email address or a Google, Facebook, or Apple account
• You want the sign-in experience to match your brand without Microsoft branding
• You want to manage customer identities separately from the employee directory
• You want to add your own business logic to the authentication flow

An external tenant is not a good fit when:

• The goal is collaboration with business partners → Use B2B collaboration in a workforce tenant
• You are authenticating workforce applications → Use a standard workforce tenant
• You need SSO to Microsoft 365 → External tenants do not support it

Configuration Option 1: Create an External Tenant

The rest of this article assumes that you have chosen an external tenant. The overall process has five steps.

The official documentation describes the following procedure for creating an external tenant.

Prerequisites

• An Azure subscription, unless you choose the 30-day free trial
• The Tenant Creator role scoped to the subscription or to a resource group in the subscription

Creation Steps

1. Sign in to the Microsoft Entra admin center (entra.microsoft.com)
2. Go to Entra ID > Overview > Manage tenants
3. Select Create
4. Select External as the tenant type, then continue
5. If this is your first tenant, you can also select a 30-day trial tenant that does not require an Azure subscription
6. On the Basics tab, enter the tenant name, domain name, and country or region
7. On the Subscription tab, select the subscription and resource group
8. Create the tenant from Review + create

Several details cannot be changed later or commonly cause confusion:

• The location, meaning country or region, cannot be changed later
• Creating the tenant can take up to 30 minutes
• You cannot create an external tenant in the Azure portal. The Azure portal supports only workforce tenant creation. After creation, however, you can access the tenant from both the Entra admin center and the Azure portal
• If you select a country or region that supports the Go-Local add-on, such as Japan or Australia, options for the data storage location appear

After creation, switch to the target directory from Directories + subscriptions in the Entra admin center. On Tenant overview, confirm the tenant name, tenant ID, and primary domain. You will use these values directly in the application configuration.

Configuration Option 2: Configure Sign-In Methods and User Flows

After creating the external tenant, decide how customers will sign up and sign in. You configure that experience with a user flow.

A user flow controls elements such as:

• Sign-in methods and external identity providers
• Attributes collected during sign-up, such as name, postal code, and country of residence; custom attributes are also supported
• Company branding and language customization

Available Sign-In Methods

Local accounts

• Email address + password
• Email address + one-time passcode (OTP)

With OTP, users enter a temporary code sent by email each time they sign in. This lets you operate without storing passwords.

Federation

• Google
• Facebook
• Apple
• Microsoft Entra ID tenant
• Custom OIDC
• SAML / WS-Fed

With social or other federated identities, users first see the Microsoft sign-in page and then choose an identity provider by default. Add the domain_hint parameter to the sign-in URL to send them directly to a specific provider, for example, domain_hint=google.

Operational Considerations

Three behaviors become especially important in production:

1. Changing the sign-in method affects only new users. Existing users continue using the method they selected when they first signed up. If you change from email + password to email + OTP, existing users are still prompted for a password
2. SMS cannot be used for first-factor authentication or self-service password reset. In an external tenant, SMS is available as second-factor verification for an additional charge
3. Federation is available only with browser-delegated authentication. Native authentication, described below, supports only local accounts: email + OTP and email + password

Using External ID from an Application

Now let us look at the application implementation. First, consider the relationship among the application, external tenant, and identity provider.

Choose an Authentication Method First

The official planning guide recommends choosing the authentication method before registering the application. There are two options.

As noted earlier, social sign-in and federation require browser-delegated authentication.

Register the Application

Register the application in the external tenant to establish trust with Entra ID. The required settings depend on the authentication method.

The redirect URI sent in the authentication request must exactly match a redirect URI registered for the application. A mismatch produces an invalid_request redirect URI error.

The MSAL Authority Is Different

The most visible implementation difference is the authority. Its format differs between workforce and external tenants.

For a workforce tenant, use this format:

authority: `${cloudInstance}${tenantId}`;

For an external tenant, point to ciamlogin.com with the tenant-specific subdomain:

authority: `https://${tenantSubdomain}.ciamlogin.com/`;

Set tenantSubdomain to the subdomain portion of the primary domain. For example, if the primary domain is contoso.onmicrosoft.com, use contoso.

Keep Branding Consistent with a Custom URL Domain

External tenants support custom URL domains. With a custom domain, users remain on your domain during authentication instead of being redirected to ciamlogin.com.

Configure MSAL as follows. Set clientId to the application (client) ID, and put the tenant ID in the authority path.

const msalConfig = {
  auth: {
    clientId: '11112222-bbbb-3333-cccc-4444dddd5555',
    authority: 'https://login.contoso.com/aaaabbbb-0000-cccc-1111-dddd2222eeee',
    knownAuthorities: ['login.contoso.com'],
  },
};

If you omit knownAuthorities, MSAL redirects to the default host. Custom URL domains are not supported in workforce tenants; this feature is specific to external tenants.

Authorization and Token Customization

Applications can use the same authorization mechanisms available with workforce tenants:

• Define app roles, assign them to users or groups, and receive them as token claims
• Use security groups for RBAC. In an external tenant, group optional claims are limited to group object IDs
• Include user attributes in access tokens and make attribute-based authorization decisions

You can also use custom authentication extensions to add claims from an external system immediately before token issuance. This is how you add your own business logic to the authentication flow.

How Pricing Works

External ID uses MAU (Monthly Active Users) billing, based on the number of unique external users who authenticate during a calendar month.

Keep these points in mind:

• Core features are free for the first 50,000 MAU
• Premium add-ons have no free tier
• MAU is calculated across workforce and external tenants linked to the subscription
• In an external tenant, every user is billable regardless of UserType. This includes users who hold administrator roles
• In workforce-tenant B2B collaboration, users whose UserType is Guest are billable; users whose UserType is Member are excluded

To enable correct billing and feature access, link the tenant to an Azure subscription. If usage remains within the free allowance, the bill is 0 yen, but usage data still appears in Cost analysis.

⚠️ Prices can change. Always check the official pricing page before making a cost decision.

Selection Checklist

Use these questions to guide the decision:

• Are you authenticating employees, business partners, or general customers?
• For business collaboration, is a workforce tenant with B2B collaboration sufficient?
• For general customers, have you planned for a new external tenant?
• Do you need SSO to Microsoft 365, which external tenants do not support?
• Have you finalized the tenant location, meaning country or region, which cannot be changed later?
• Does the required sign-in method call for browser-delegated or native authentication?
• Does the design incorrectly assume that SMS can be the first factor?
• Will you use a custom URL domain, or is ciamlogin.com acceptable?
• What are the expected MAU, the effect of the 50,000 MAU free allowance, and the need for add-ons?
• If you have existing Azure AD B2C assets, have you confirmed the migration approach?

Summary

• Azure subscriptions and Microsoft 365 are associated with the internal container called a workforce tenant
• A subscription can trust only one directory
• External users follow one of two paths: B2B collaboration in a workforce tenant or CIAM in an external tenant
• If business partners only need access to your application, inviting them as B2B guests is sufficient. You do not need a new tenant
• Azure AD B2C has not been available for new purchases since May 1, 2025. Existing customers will be supported until at least May 2030
• For new deployments, an External ID external tenant is the default choice
• An external tenant can be created only in the Entra admin center, and its location cannot be changed later
• The key implementation details are an authority under <subdomain>.ciamlogin.com and an exact redirect URI match
• Billing is MAU-based, and core features are free for the first 50,000 MAU

It sounds simple to say, “Entra ID is for internal users, and External ID is for external users.” In practice, however, external users split into business collaborators and customers of your service. Make that distinction first, and the rest of the design becomes much easier.

Official Sources

• Introduction to Microsoft Entra External ID
• Workforce and external tenant configurations in Microsoft Entra External ID
• What is Microsoft Entra B2B collaboration?
• B2B collaboration invitation redemption
• Add and manage B2B collaboration users in the Microsoft Entra admin center
• Identity providers for External ID in workforce tenants
• Supported features in workforce and external tenants
• Associate or add an Azure subscription to your Microsoft Entra tenant
• Create an external tenant
• Create a sign-up and sign-in user flow for an external tenant app
• Identity providers for external tenants
• Planning for customer identity and access management
• Microsoft Entra External ID pricing and billing overview
• Microsoft Entra External ID frequently asked questions
• Azure AD B2C: Frequently asked questions (FAQ)
• Plan your migration from Azure AD B2C to External ID