Your identity provider is a single point of failure.

2026-10-19 · TenantFlex

Most resilience plans have a page on the identity provider, and most of those pages say the provider has an SLA. That is true, and it is not a plan. When the identity provider is unavailable, every application that federates to it is unavailable, including the ones you would use to coordinate the incident. The question is not whether the provider will stay up. It is what you would do on the day it does not, or the day it is compromised, or the day you have to leave it faster than you intended.

Three ways to lose the identity provider

• Outage. Rare, but not theoretical, and when it happens it is total for every federated application at once. Your SLA credit arrives in the next invoice. Your users wait.
• Compromise. An attacker with administrative access to the identity tenant can change any application's configuration, add themselves to any assignment, or mint tokens. Recovery means knowing what the configuration was before, which most organisations do not.
• Exit under pressure. A regulator, an acquirer or a renewal that goes wrong can make leaving the provider urgent. The migration that takes nine months when planned is the same migration when it is not.

Why the usual answers fall short

"We have break-glass accounts." Those get an administrator into the identity provider. They do nothing for users trying to reach applications through it.

"We export the configuration." An export is a point-in-time file. Without a diff against the live tenant, you cannot tell what changed, and without a restore path you cannot put it back. Most exports have never been restored from.

"We have a second tenant." An empty one, usually. A standby tenant with no applications in it is a landing zone, not a standby.

What a standby actually requires

Regulators have started to write this down. DORA asks financial entities in the EU to maintain and test exit and recovery plans for critical ICT providers, and the identity provider qualifies for most of them. Stripped of the regulatory language, a credible standby has four properties.

1. A restorable backup. Every SSO application captured on a schedule, with each capture compared to the last so you know what changed and when. Restorable means field by field, not "re-import the file and hope".
2. A second tenant with the applications already in it. Possibly at a different provider, so the failure modes are not shared. The applications are recreated there ahead of time, with their own certificates, and refreshed when the primary changes.
3. A rehearsed cutover. Someone has run it, for a pilot group, in a change window, with a log. The log is what you show the auditor, and it is what tells you the standby had drifted.
4. A way back. Failing back once the primary is recovered is the same job in reverse, and it has to reconcile whatever changed during the outage.

The part people underestimate

The applications. Keeping a standby tenant in step with the primary means recreating every SSO application in it and keeping them current, which by hand is a migration you never finish. This is why "we have a second tenant" so often means an empty one. The standby only becomes credible when recreating a hundred applications is a job that runs, not a project that starts.

A rehearsed cutover, on paper

When	What	Evidence
Nightly	Capture the primary tenant. Diff against the last capture.	Capture log, diff per application
Quarterly	Refresh the standby from the primary. Run a cutover for a pilot group in a change window.	Execution log, owner sign-off
On the day	Run the job for the full scope. Owners repoint from their hand-off bundles.	Execution log, time to restore
After	Run the reverse job. Reconcile what changed during the outage.	Execution log, reconciliation list

That table is also the evidence section of a resilience audit. If you cannot fill in the right-hand column today, the identity provider is a single point of failure, and the SLA is not a plan.