The Migration Nobody Finishes Quickly

Microsoft closed Azure AD B2C to new tenants on 1 May 2025. Existing tenants keep working, and support runs until at least May 2030, but every new capability now lands in Microsoft Entra External ID instead. B2C is not being switched off tomorrow. It is being left where it stands.

That gives most teams a long, unglamorous window. You cannot move a customer-facing identity platform in a weekend. User flows have to be rebuilt, custom policies reconsidered, applications repointed, and consent carried across without asking millions of customers to re-authorise. Realistically you announce the migration in one financial year and finish it in another.

For the whole of that window, you are running two customer identity estates at once. And both of them are full of App Registration secrets and certificates that expire.

Why This Is a Credential Problem, Not Just a Migration Problem

Customer identity tenants are the ones you can least afford to have go quiet. When an App Registration secret expires in a workforce tenant, an internal tool breaks and someone raises a ticket. When one expires in a CIAM tenant, your customers cannot sign in, and the first people to notice are the people paying you.

Migrations make this worse in three specific ways.

Ownership gets blurry. During a migration, the same application often exists twice. The B2C registration is still live because the old flow still serves some traffic; the External ID registration is live because the new flow is being piloted. Two sets of credentials, two expiry dates, and a genuine ambiguity about which team is watching which.

New registrations are created quickly and forgotten. Migration work generates App Registrations at a rate normal operations never does: pilots, parallel environments, integration test apps. They get secrets with default lifetimes and no owner in anyone’s calendar.

Attention moves to the new side. Once the External ID tenant is the interesting one, the B2C tenant becomes a maintenance concern. It still serves real traffic. Nobody is looking at it. That is precisely the shape of an outage.

What CertifyClouds Now Does

CertifyClouds already discovered and rotated App Registration credentials in Azure AD B2C tenants. As of this release, Entra External ID external tenants register the same way and run through the same workflows.

For each App Registration in a registered External ID tenant, discovery inventories:

  • The application name and client ID
  • Password credentials with their expiry dates
  • Key credentials (certificates) with their expiry dates
  • Resolved application owners, used for owner-scoped alerts
  • Expiry status: expired, expiring soon within 30 days, or valid

Rotation works the same way it does everywhere else in the product. You enable rotation on a credential, acknowledge the Key Vault targets it should propagate to, and CertifyClouds creates the new secret or certificate in the external tenant, writes it to every acknowledged target, and records the result and per-target propagation status in rotation history. Both secret and certificate rotation are supported. The Key Vault targets stay in your corporate tenant and are updated through the existing propagation workflow. Nothing new to learn, and nothing new to trust.

Expiry rules keep evaluating the discovered credentials and notifying whoever you have configured, including owner-scoped delivery to the application’s actual owners rather than a shared mailbox nobody reads.

The point of all this is not that External ID is supported. It is that the two tenant types behave identically, so your monitoring does not develop a seam exactly where your estate is most fragile.

What Is Genuinely Different

External ID is not a rebranded B2C, and pretending otherwise would set you up for a surprise. Three differences matter operationally:

No two-credential cap on organization-audience apps. B2C applications with a Microsoft-account audience are limited to two credentials, which forces an awkward replace-at-cap path during rotation. External ID’s organization-audience apps do not carry that limit, so the at-cap replacement behaviour simply does not apply to them.

No b2clogin.com. That domain is specific to B2C user flows. Anything in your tooling or runbooks that pattern-matches on it will not fire for External ID.

No trust framework keysets. External ID has no equivalent of B2C’s custom-policy trust framework keys, so there is no analogous keyset material to track.

None of these change discovery, rotation, Key Vault propagation, or alerting. They change what you should expect to see, which is a different and more useful thing to know in advance.

What It Does Not Do

Worth being direct about the boundary: CertifyClouds does not provide a migration cockpit. There is no per-tenant “migrated” state, no progress bar across your application inventory, no orchestration of the move itself. Tenant registration and credential operations are available side by side, and that is the extent of it.

If you want a tool that runs your B2C-to-External-ID migration, this is not that tool. If you want to be certain that no credential on either side of that migration expires without warning, that is exactly what this is.

Setting It Up

The setup shape is the same as any tenant CertifyClouds manages: a dedicated service principal inside the external tenant, with explicitly granted Microsoft Graph application permissions and tenant-wide admin consent.

Three permissions are required:

Permission Why
Application.ReadWrite.All Discover App Registrations and rotate their secrets and certificates
Organization.Read.All Test the connection and read tenant information
User.Read.All Resolve App Registration owners for owner-scoped expiry alerts

One warning is worth repeating because it fails quietly rather than loudly: without User.Read.All, discovery still completes. Microsoft Graph returns owner references without usable identity details, the resolved owner list comes back empty, and owner-scoped expiry alerts go out to nobody. Nothing errors. You simply stop being told.

Create the App Registration inside the external tenant rather than your workforce tenant, grant admin consent for all three permissions, then register the tenant in CertifyClouds with its kind set to External ID. Test the connection, run discovery, and the credentials appear alongside everything else.

Full walkthrough, including the Azure Portal steps and troubleshooting for the common permission failures, is in the Entra External ID Tenants guide.

Availability

Entra External ID tenant management is available on PRO and ENTERPRISE tiers, the same as B2C tenant scanning. Existing PRO and ENTERPRISE customers have it now: register an External ID tenant from the external tenant registry and it will be discovered on the next scan.

If you are partway through a B2C migration and cannot currently answer the question “which App Registration credential in either tenant expires next”, that is the gap this closes.