The Cost of an Expired B2C Tenant Secret Nobody Remembered

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 different. It 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 one reaches zero, you do not lose a service. You lose the ability for anyone to 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 certificates. B2C signs the tokens it issues. If the signing certificate expires, token issuance stops. Not “social login stops” but every sign-in for every user, because there is no valid key to sign the token with.
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 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 five, and they are 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. At the moment the signing certificate expires, 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, so the clock that matters is the trust clock. 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

The fix is not heroics on the day. It is removing the conditions that make a B2C expiry possible:

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.
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.
Alert on lead time, not on failure. A useful alert fires thirty, fourteen, 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.
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

This is the blind spot CertifyClouds was built to remove. Its B2C tenant scanning treats the B2C directory as a first-class part of your estate. It discovers the App Registrations, secrets, and certificates inside the B2C tenant, puts them on the same expiry timeline as the rest of your Key Vaults, and sends owner-aware alerts with real lead time before anything expires. The tenant nobody remembered becomes one more line on a dashboard somebody actually reads.

An expired certificate that takes customer login offline is one of the most preventable incidents in cloud operations. It only happens because the credential was invisible. Make it visible and the outage does not happen.

CertifyClouds discovers credentials across your entire Azure estate, including the B2C tenant most tools never look at, on a single dashboard with expiry timelines and configurable alerts at the thresholds your team cares about. B2C tenant scanning is included in Pro. Try it free with a 30-day Pro trial.