Microsoft Entra External ID: What Made It to GA (November 2025 – February 2026) — Part 1

What changed and what's worth knowing

Microsoft Entra External ID has had a busy six months. Between November 2025 and February 2026, Microsoft shipped several features that moved from preview to general availability — some of them genuinely useful, a few that fill gaps that should have been there from the start. This two-part post covers what hit GA in Part 1, and what's still sitting in public preview in Part 2.

I want to be practical about this: not every GA announcement changes how you should build things today. Some of these features are table stakes. Others open up scenarios that weren't possible before — particularly around machine-to-machine auth and regional data residency. I'll flag which is which.

What is Entra External ID? It's Microsoft's CIAM (Customer Identity and Access Management) platform for external tenants. You use it when you need to give customers, partners, or external users their own branded sign-in experience — separate from your corporate Microsoft 365 identity. Think: customer portal, consumer app, partner extranet.

Workforce tenants vs external tenants

Before getting into features, it's worth being clear about what an "external tenant" actually is, because Microsoft uses "tenant" for everything and it gets confusing fast.

Your Microsoft 365 subscription uses a workforce tenant — that's where employees sign in, where Exchange Online lives, where your Conditional Access policies protect corporate apps. You don't want customers in there.

An external tenant is a separate Microsoft Entra ID directory created specifically for your customer-facing applications. It has its own branding, its own user base, its own policies. The two are isolated from each other by default.

The MAU billing model is worth understanding early on. You get 50,000 free MAUs per month on External ID. After that, it's billed per active user per month — a user counts if they authenticate at least once in that calendar month. This is fundamentally different from workforce licensing, which is per-licensed seat regardless of activity.

November 2025: regional data residency goes GA

The first significant GA of this period was regional expansion. Microsoft brought the External ID Go-Local add-on to Australia and Japan. This matters for organisations with data residency requirements under local regulations — Australia's Privacy Act, Japan's APPI, or industry-specific compliance frameworks that require customer data to stay within national borders.

Before this, External ID data resided in US or EU regions only. If you were building a customer portal for an Australian bank or a Japanese e-commerce platform, you either accepted US/EU residency or looked at alternatives. Neither option was ideal.

The Go-Local add-on keeps your external tenant's data — user profiles, authentication logs, session data — in the selected geography. With Australia and Japan now available, the supported regions are: United States, European Union, Australia, and Japan.

One thing to know about Go-Local: The data residency commitment applies to user data at rest. Network traffic for authentication still routes through Microsoft's global infrastructure. If your compliance requirement is specifically about data storage location rather than network routing, Go-Local covers it. If you need full in-country network path, that's a different conversation involving private connectivity options.

January 2026: three features hit GA together

Session controls via Conditional Access

Session controls in Conditional Access manage what happens after a user authenticates — not just whether they get in, but how long their session lasts and whether the browser remembers them. This was already available in workforce tenants; it's now GA for external tenants too.

Two controls matter here:

• Sign-in frequency forces re-authentication after a set number of hours or days, regardless of whether the session token is still valid. Useful for sensitive apps — banking portals, healthcare, anything where indefinite sessions are a risk.
• Persistent browser session controls whether the "Stay signed in?" prompt appears and whether sessions survive browser restarts. For a consumer shopping app, persistence is fine. For a healthcare portal handling patient records, probably not.

You configure these through Conditional Access policies in the external tenant, scoped to specific apps or applied broadly. The policy settings are under Session controls in the CA policy editor — same location as workforce tenants.

Client credentials flow (machine-to-machine)

This one's a genuine capability addition, not just parity with workforce tenants. The OAuth 2.0 client credentials grant is now GA in external tenants, which means your backend services, daemons, and APIs can authenticate to External ID using application credentials — without any user involved.

If you're building a multi-tenant SaaS product, you likely have backend systems that need to act on customer data without a human in the loop:

• A billing service reading customer subscription state
• A notification pipeline sending emails on behalf of customers
• An analytics exporter that aggregates usage per customer account
• A data sync job that runs overnight without user interaction

Before this was GA, External ID couldn't serve as the identity layer for these machine-to-machine scenarios. You'd bolt on a separate system for service-to-service auth — an unnecessary complication. Now the whole identity surface, user-facing and machine-facing, can run through External ID.

Licensing note: The client credentials flow in External ID requires the M2M Premium add-on. It's not in the base External ID pricing. The add-on is priced per application token rather than per user, so the cost model differs from MAU-based user authentication. If you have only a handful of backend services, the cost stays manageable. Worth running the numbers before committing.

Per-app branding themes

Before this, External ID branding was tenant-wide — one logo, one colour scheme, one background for every app in the tenant. That's workable for simple deployments, but it falls apart if you're running a white-label product or multiple distinct brands from a single external tenant.

The branding themes feature lets you create per-application branding configurations. Each app registration can be assigned its own theme with:

• Logo and background image
• Colour scheme (background, foreground, button accent colours)
• Custom CSS overrides for finer control

There's a live preview in the Entra admin center. The old workflow was "configure, deploy, load the sign-in page, squint at it, repeat" — the preview removes that loop for most changes. You configure themes under External Identities → User experiences → Branding themes, then assign each theme to one or more app registrations.

February 2026: usability and auth flow improvements

Custom banned password lists

Microsoft already maintains a global banned password list covering common passwords, keyboard patterns, and known breached credentials. These are automatically blocked when users set passwords in Entra. The custom list extends that with strings specific to your organisation.

Your customers pick poor passwords. If your product is called "Contoso", a meaningful share of your customer base will try "Contoso1" or "ContosoPass123" or "contoso2024". Those aren't in Microsoft's global list — they're specific to you. Now you can block them.

You configure the custom list under Authentication methods → Password protection in the external tenant. You add strings rather than full passwords — the system derives variations automatically (case changes, common character substitutions like @ for a, 3 for e). Up to 1,000 custom entries. The change takes effect for new password creation and resets; it doesn't retroactively invalidate existing passwords.

Sign-in with username or alias

Standard External ID local accounts are email-based. Users sign in with the email address they registered with. That's fine for general consumer apps, but a lot of industry-specific CIAM scenarios need a different primary identifier:

• A bank where customers sign in with their account number
• An airline with a frequent flyer number as the customer identifier
• A health portal where the patient ID is the login credential
• An insurance portal where policy numbers identify customers
• A retail loyalty program using membership numbers

The alias sign-in feature (GA February 2026) lets users with local accounts sign in using a secondary identifier instead of their email address. The alias is assigned to the user via the Microsoft Graph API — you update the identities collection on the user object and add a signInType of userName with an issuerAssignedId set to the alias value. Each user can have one alias, and it must be unique within the tenant.

A few constraints worth knowing: this only works for local accounts (email + password). Social identity providers and federated accounts can't use aliases — those are controlled by the external IdP, not External ID. And the alias is currently read-only from the user's perspective; they can't set it themselves through the self-service profile flow.

Device authorization grant flow

The OAuth 2.0 device authorization grant (RFC 8628) handles authentication for devices that don't have a usable browser or keyboard — smart TVs, IoT sensors, printers, CLI tools. The device displays a short code and a URL; the user goes to that URL on their phone or laptop, enters the code, authenticates normally, and the original device gets the access token. Credentials never touch the constrained device.

This flow has been available in workforce tenants for years (it's what az login uses when you're on a headless server). Making it GA in external tenants opens it up for customer-facing scenarios:

• A smart TV streaming app where customers sign in to their subscription account
• An industrial IoT console that authenticates against your customer identity system
• A CLI tool you distribute to customers that needs to act on their behalf
• A kiosk or shared device where typing credentials is impractical

The MFA requirement still applies — if your Conditional Access requires a second factor, the user completes it on the verification device (their phone), not on the constrained device. That's actually the right behaviour: the smart TV never needs to know your authenticator app exists.

All six GA features at a glance

A quick reference covering all the GA features from this period — release date, who needs them, and whether they cost extra:

Official Microsoft docs

What's still in preview

Not everything shipped GA in this period. The most interesting work-in-progress feature is just-in-time password migration — a way to migrate customers from an existing identity system to External ID without a bulk migration event. There's also WAF integration with Akamai and Cloudflare, and MFA Conditional Access authentication context for external tenants. Part 2 covers all of that in detail.

Share this: