The Tenant Nobody Owns

Every other secret in your estate has a blast radius you can reason about. A backend service loses a database credential and one service degrades. An internal API drops an App Registration secret and a scheduled job fails until someone notices.

An Azure AD B2C tenant is the front door to your product. Every customer, every login, every “Sign in with Google” button routes through it. And in most organisations it was stood up once, during launch, by someone who has since changed teams or changed companies. It lives in its own separate tenant, outside the subscriptions your monitoring actually watches. Nobody runs a weekly review of it because nobody believes they own it.

So the credentials inside it quietly count down, and when the wrong one reaches zero, nobody can log in.

What Actually Expires Inside a B2C Tenant

The reason B2C outages are so disorienting is that the thing that expired is rarely the thing people were watching. A B2C tenant holds several independent credentials, each with its own clock:

  • Token signing and encryption keys. If you use custom policies (the Identity Experience Framework), B2C signs its tokens with a key you manage as a policy key. When that key expires and there is no newer valid key in the same keyset, Microsoft’s docs say B2C “won’t be able to use the expired key”. Every sign-in fails, for every user. Tenants that only use the built-in user flows don’t manage these keys themselves.
  • Identity provider secrets. Each external login option (Google, Facebook, Microsoft, Apple, a partner’s SAML or OIDC IdP) is wired up with a client secret. On custom policies it is stored as a policy key in the B2C tenant. When the Google secret expires, the “Sign in with Google” path returns an error while everything else keeps working, which makes it harder to diagnose.
  • Custom policy keys and REST API secrets. If you run custom policies (Identity Experience Framework), your user journeys call out to REST endpoints and reference signing keys. Those secrets and certificates expire too, and they fail mid-journey, after the user has already typed their password.
  • App Registration secrets inside the B2C tenant. The applications registered in the B2C tenant, including the ones your own apps use to talk to it, carry client secrets on the same one or two year timer as any other App Registration.

Each of these is a separate countdown, set on a different day, by a different person, for a different reason. There is no single expiry date to put in a calendar. There are several, scattered across a tenant you log into twice a year.

Why It Is Worse Than a Normal Secret Expiry

A normal expired secret is an internal problem. You see it in your logs, you fix it, customers never knew. A B2C expiry inverts every part of that.

The blast radius is one hundred percent of your users, instantly. There is no gradual degradation. On a custom-policy tenant, the moment the signing key expires with no replacement, the next login attempt fails, and so does every one after it. New customers cannot sign up. Existing customers cannot get back in. Anyone whose session happened to expire is now locked out of a product they are paying for.

It is customer-facing. An internal outage costs engineering hours. A login outage costs customer confidence. People remember the day they could not get into their account, and they tell other people about it. For a SaaS product, “I could not log in for three hours” is the kind of sentence that ends up in a renewal conversation.

Your existing monitoring almost certainly does not see it. This is the part that catches teams out. Your secret scanners, your cost alerts, your subscription dashboards are all scoped to your corporate tenant and its subscriptions. The B2C tenant is a separate directory. It does not show up in the subscription list you scan. The credentials inside it are invisible to the tooling you trust to catch exactly this problem.

There is no owner to escalate to. When the incident starts, the first twenty minutes are spent working out who configured B2C, whether anyone still has admin on that tenant, and which of the five possible credentials actually expired. That investigation time is pure downtime, and it happens while customers are locked out.

What It Costs, In Real Terms

Put numbers on it. Take a product with even a modest paid base, say a few thousand active customers. During a B2C signing certificate outage:

  • Revenue stops at the door. No one can log in, so no one can buy, upgrade, or use the paid features they are mid-session on. For an e-commerce or self-serve SaaS flow, that is direct, measurable lost revenue for the full duration.
  • Support load spikes immediately. “I can’t log in” tickets and chats arrive in a wall the moment the outage starts. Your support team is now firefighting a problem they cannot fix, on a tenant they do not have access to.
  • Engineering scrambles on an unfamiliar surface. The people who can fix it are learning the B2C tenant layout in real time, under pressure, often without standing admin rights because it was set up by someone else years ago.
  • The reputational tail is the expensive part. The outage ends in hours. The screenshots, the status-page incident, the “is this service reliable” doubt in a procurement review months later: that is the cost that does not show up on the same day, and it is the one that lingers.

The certificate that caused all of this cost nothing to renew. It needed someone to know it existed and to act a week before it expired. The entire incident is the price of that one missing piece of visibility.

How To Stop It

Heroics on the day won’t fix this. Remove the conditions that make a B2C expiry possible:

  1. Scan the B2C tenant the same way you scan everything else. The credentials in it are not special, they are just somewhere your normal tooling does not look. Bring the B2C tenant into the same inventory as your corporate Key Vaults and App Registrations so its certificates and secrets appear on the same expiry list.
  2. Track every credential type, not just the obvious one. Signing certificates, IdP secrets, policy keys, and App Registration secrets all need to be on the radar. The one you are not watching is the one that expires.
  3. Alert on lead time, not on failure. A useful alert fires well ahead, for example thirty and seven days out, to a destination a human reads, while there is still time to rotate calmly. An alert that fires when login is already down is just an incident notification.
  4. Give the tenant an owner and a routine. Even a quarterly review of “what expires in the B2C tenant in the next ninety days” turns a future outage into a calendar task.

Where CertifyClouds Fits

CertifyClouds covers the App Registration side of this. Its B2C tenant scanning discovers every App Registration in the B2C tenant and the client secrets and certificates on each one, puts them on the same expiry timeline as your Key Vaults, and, once an admin turns on app owner emails, alerts each application’s owners before anything expires. It can also rotate those credentials and write the new value to the Key Vaults that hold it.

It does not read policy keys. The custom-policy signing keys and identity provider secrets described above still need a check in the B2C portal, under Identity Experience Framework > Policy keys. Put a recurring review of that page on the tenant owner’s calendar, and give every key an expiry date you will see coming.

Microsoft stopped selling B2C to new customers on 1 May 2025, and new customer identity work now goes to Entra External ID. If you are running both during a migration, you have two customer identity tenants to watch. See credential monitoring for both B2C and Entra External ID.

CertifyClouds puts your Key Vaults, your workforce App Registrations and your B2C App Registrations on one expiry timeline, with alerts at the thresholds your team chooses. B2C tenant scanning is included in Pro. Try it free with a 30-day Pro trial.

Further Reading