Azure AD B2C to Entra External ID: plan users, passwords, policies and cutover safely

Azure AD B2C is no longer sold to new customers, its P2 tier and ID Protection have been retired, and every organisation still running customer sign-in on it now needs a plan to move users, credentials and custom policy logic to Microsoft Entra External ID while keeping sign-in working and account security intact. The service is still supported, so this is a planned migration rather than an emergency, and some B2C security features have been retired, so custom policy logic needs to be rebuilt on the new platform. This guide covers the official timeline, the two migration modes Microsoft documents, how to rebuild Identity Experience Framework (IEF) logic, how to move users and passwords, custom domains, MFA and fraud controls, and how to test and roll back. It is written for CIAM architects, identity engineers and application owners. The vendor-neutral foundations of customer identity are in the Customer IAM (CIAM) Guide; this page is specific to the Microsoft move.

This is an independent guide from NHI Mgmt Group, based on Microsoft's public documentation as of November 2026. It is not sponsored or reviewed by Microsoft. Product features change, so confirm settings against Microsoft's current documentation.

Key takeaways

• There is time, but not unlimited time. Microsoft's B2C FAQ states end of sale for new customers from 1 May 2025 and support until at least May 2030. Use the window to migrate deliberately, not to postpone.
• The security baseline has already changed. P2 was retired in B2C tenants by the end of March 2026, taking ID Protection risk-based policies with it. Review what your user flows relied on now, not at cutover.
• Custom policies are rebuilt, not ported. Microsoft maps IEF logic to custom authentication extensions and states that one-to-one parity is not guaranteed. Inventory every technical profile and orchestration step first.
• Bulk user migration is always required. Passwords can be preserved through just-in-time migration on the OnPasswordSubmit event or a B2C-initiated harvest, both of which create a credential validation API you must protect against brute force.
• Cutover is an application project. Every app moves to new endpoints and token validation, and a custom URL domain plus blocking the default ciamlogin.com domain closes a bypass path.

What is changing and why

Azure AD B2C was Microsoft's original customer identity service, built on a dedicated B2C tenant type with user flows for common journeys and custom policies (XML documents executed by the Identity Experience Framework) for everything else. Microsoft Entra External ID for customers runs on an "external tenant" configuration of the Entra platform, shares the workforce Conditional Access engine (in reduced form) and replaces arbitrary XML orchestration with a fixed set of user flows extended by event-based APIs called custom authentication extensions.

For security teams the important differences are structural, not cosmetic:

• Extensibility model: IEF let you chain REST calls, claims transformations and conditional steps in any order. External ID exposes defined events (TokenIssuanceStart, OnAttributeCollectionStart, OnAttributeCollectionSubmit, OnOtpSend, and OnPasswordSubmit for password migration), so complex journeys must be redesigned around those hooks.
• Policy engine: B2C access controls map to Entra Conditional Access, but external tenants support only a subset: device platform and location conditions; block, require MFA or require password reset as grant controls; sign-in frequency and persistent browser session as session controls.
• Risk detection: Microsoft Learn lists ID Protection and ID Governance as not available in external tenants, so risk-based sign-in policies need another source (fraud and bot protection services or your own signals).
• Endpoints: applications use an authority of the form https://<tenant-subdomain>.ciamlogin.com/ instead of the B2C b2clogin.com host and policy-specific paths, so token issuers and validation code change.
• Legacy flows: resource owner password credentials (ROPC) are not supported in external tenants; native authentication is the documented route for apps that render their own sign-in UI. See the Legacy Authentication and ROPC Retirement Guide.

Official timeline and current status

All dates below are as stated on Microsoft Learn when checked on 8 November 2026. Microsoft notes that migration plans and feature timelines evolve, so confirm against the linked pages and your account team before committing dates.

"At least May 2030" is a minimum, not an announced retirement date. The FAQ gives both 15 March 2026 and "by the end of March 2026" for the P2 change; treat the P2 features as gone in all B2C tenants.

Who and what is affected

• Every B2C tenant owner: no forced cutover yet, but no new investment on the platform, and the P2 risk features are already removed.
• Tenants built on custom policies: the largest effort. Journeys using REST technical profiles, claims transformations, custom OIDC or SAML identity providers configured in XML, or age gating need redesign. Microsoft states age gating is not currently supported in External ID, and that third-party identity providers configured through B2C custom policies are not supported; social providers must be rebuilt with External ID's built-in federation.
• Tenants that relied on P2: any user flow condition that used sign-in risk or user risk now has no effect in B2C and has no direct equivalent in an external tenant.
• Application teams and ISVs: each application must be updated to External ID endpoints and token validation; Microsoft notes ISVs cannot complete migration until every customer-facing app is updated.
• Very large tenants: above roughly 5 million directory objects, Microsoft documents High Scale Compatibility (HSC) mode, with its own feature limits.

Finding affected systems and identities

Build the inventory before choosing a migration mode. The aim is a list of everything that issues, consumes or extends B2C tokens.

Identity angle: the REST APIs, policy keys and IdP client secrets behind a B2C tenant are non-human identities with direct influence over customer authentication. Record an owner, rotation date and decommission date for each. See the How to find expiring app secrets and certificates in Entra ID.

Migration options

Standard migration or HSC mode

Microsoft states HSC mode provides no added benefit below the high-scale thresholds and requires you to accept its functional limitations. For a security team the HSC gaps (no passkeys, no step-up Conditional Access) are material, so document compensating controls before choosing it.

Replacing custom policy logic

• Token enrichment: claims fetched from a CRM or entitlement API move to TokenIssuanceStart.
• Sign-up validation: email domain checks, invitation codes and duplicate detection move to OnAttributeCollectionStart and OnAttributeCollectionSubmit.
• Custom OTP delivery: a custom email provider for one-time passcodes uses OnOtpSend.
• Access rules: B2C access policies move to Conditional Access within the supported subset.
• Mobile UI: embedded sign-in moves to native authentication SDKs (local accounts only).

Every extension endpoint must authenticate Microsoft's calls and validate inputs; treat it as part of the authentication path, with the same change control as the identity provider.

Users and passwords

1. Bulk create users through Microsoft Graph, with a Boolean extension property (Microsoft's example is toBeMigrated) set to true and a unique, strong random password where the real one is not available. Plan for Graph throttling on large runs; Microsoft publishes a B2C to External ID migration tool sample on GitHub.
2. Choose a password strategy: just-in-time (apps move to External ID first; the OnPasswordSubmit extension validates the password against B2C, writes it to the new account and clears the flag) or B2C-initiated (apps stay on B2C while a custom policy calls a REST API, typically an Azure Function, to validate and write credentials in the background).
3. Time-box coexistence: Microsoft advises that JIT works best when coexistence is time-boxed. Users who never sign in are not migrated and must reset their password.
4. Prefer skipping passwords where you can: federated users and users moved to passwordless methods need no credential migration, and email OTP or passkeys remove the password from the new tenant entirely. See the Passwordless and Passkeys Guide.

The validation API in either pattern accepts a username and password and answers yes or no: it is a credential stuffing oracle (ATT&CK T1110.004) if exposed. Microsoft's guidance is to protect it against brute force and stop serving requests above a threshold. Restrict callers, rate limit per account and per source, log every call and switch it off on the planned date.

Custom domains, MFA and fraud controls

• Custom URL domain: a reverse proxy such as Azure Front Door fronts the tenant, with a CNAME from the branded host to the Front Door endpoint. Move all apps to the same domain, because the browser session is stored per domain.
• Block the default domain: Microsoft recommends blocking <tenant>.ciamlogin.com through a support request once the custom domain works, so attackers cannot bypass the proxy's WAF or use the default host for denial of service.
• MFA: external tenants support email OTP, SMS (as a second factor only) and passkeys (sign-in and MFA, not sign-up), enforced through Conditional Access. Plan passkey enrolment rather than defaulting to SMS.
• Fraud and bots: without ID Protection, account takeover and sign-up abuse need third-party bot and fraud protection integrations (documented for standard deployments) or a WAF in front of native authentication endpoints. See the Bot Management Guide and the Account Takeover Prevention Guide.

Testing and rollback

1. Build the destination tenant fully (apps, user flows, federation, Conditional Access, extensions, monitoring) before any production user data is copied, as Microsoft's guide requires.
2. Test every journey: sign-up, sign-in, password reset, MFA enrolment, social sign-in, token claims, API calls and native authentication, with test users of each identity type.
3. Pilot one low-risk application with a percentage of traffic, compare sign-in success rates and support ticket volumes with the B2C baseline.
4. Keep B2C authoritative until cutover in the B2C-initiated pattern, so rollback is a configuration change in the app, not a data restore.
5. Define rollback per app: the previous authority, client ID and token validation settings kept deployable; users who changed passwords in External ID during JIT may need a reset if you roll back, so communicate that risk.
6. Decommission in order: disable the validation API, rotate and delete policy keys and IdP secrets, then remove the B2C app registrations.

What to monitor

• Sign-in success and failure rates per app in External ID against the B2C baseline.
• Calls to the credential validation API: volume, failure ratio, distinct sources (alert on spikes).
• Count of users still flagged for migration, trending to zero before the coexistence end date.
• Requests reaching the default ciamlogin.com domain after the block request (should be none).
• Passkey and MFA enrolment rate in the new tenant.

Risks of doing nothing

• Risk controls to replace: ID Protection has been retired for B2C tenants, so risk-based blocking configured there no longer runs; plan its replacement on Entra External ID.
• Compressed migration later: a large custom policy estate rebuilt under deadline pressure invites shortcuts such as long-lived validation APIs and copied secrets.
• Unsupported components: NIST SP 800-53 SA-22 expects replacement plans for components approaching end of support; auditors will ask for one well before 2030.
• Feature stagnation: new authentication capabilities land in External ID, not B2C.

Common failure patterns

• Porting IEF journeys step by step instead of redesigning around extension events, producing brittle extensions.
• Leaving the JIT validation API running indefinitely, unauthenticated or without rate limits.
• Copying B2C policy keys and IdP client secrets into the new tenant instead of issuing new ones.
• Migrating some apps to a custom domain and leaving others on the default host, breaking SSO and leaving a bypass path.
• Assuming Conditional Access in an external tenant matches workforce features, then finding the needed condition is unavailable.

Framework mapping

Practitioner checklist

• Record the official dates and your own target cutover date in the risk register, with SA-22 as the control reference.
• Export every custom policy file and map each orchestration step to an extension event, Conditional Access rule or a decision to drop it.
• Decide standard migration or HSC mode, documenting accepted feature gaps and compensating controls.
• Build and test the external tenant, including monitoring in Log Analytics, before copying production users.
• Bulk migrate users with a migration flag; choose JIT or B2C-initiated password migration and set a coexistence end date.
• Protect the credential validation API with caller restriction, rate limits, logging and a planned shutdown.
• Deploy a custom URL domain for every app, then request blocking of the default ciamlogin.com domain.
• Plan passkeys and email OTP as primary methods, with fraud and bot protection replacing lost ID Protection.
• Rotate and delete B2C policy keys, IdP secrets and app registrations after cutover.

Standards and references

• Microsoft Learn: Azure AD B2C FAQ (end of sale and P2 retirement)
• Microsoft Learn: Plan your migration from Azure AD B2C to External ID
• Microsoft Learn: Migrate from Azure AD B2C to Microsoft Entra External ID
• Microsoft Learn: Migrate users and credentials to External ID
• Microsoft Learn: Supported features in external tenants
• Microsoft Learn: Custom URL domains in External ID
• NIST: SP 800-53 Rev 5 Security and Privacy Controls

Related NHI Mgmt Group resources: Customer IAM (CIAM) Guide · Identity Platform Migration · Conditional Access Guide · CIAM Buyer's Guide