Break-glass recovery

This will happen to someone. An administrator changes a role map, mistypes an audience, rotates a certificate, or removes their own admin mapping — and then nobody in the organisation can sign in.

It is a recoverable situation, and recovery is a restore, not a guess.

Why it is recoverable

Every write to your single sign-on configuration first appends the previous configuration to a revision history. The working configuration is still there after the change that broke it.

Level 1 — you can still sign in

Single sign-on → Configuration history → Restore on the revision before the breaking change.

This is the common case, because the person who made the change often still has a live session. Do this before signing out.

If you have just made a change and it looks wrong

Do not sign out to “test it properly”. Open a private window instead, or use test login, which runs the full pipeline without ending your session.

Level 2 — nobody in your organisation can sign in

Contact Seylo support.

A platform administrator can restore your configuration from the same revision history. Platform administration is deliberately not a role claim from your directory, so your broken identity provider is irrelevant to it — this is a normal operation, not special tooling.

Every action taken on your behalf is written into your audit trail as well as ours, so you can see in your own export exactly what was done and when.

Level 3 — no identity provider works at all

This is the case where even our own directory is unavailable, or a self-hosted deployment’s only provider is the broken one.

Recovery then requires filesystem access to the application database — a local operator running a recovery tool on the host itself.

Why there is no emergency URL or recovery password

A recovery path reachable over the network is a second way in, and a second way in is a second thing to attack. There is no token, no bypass flag and no emergency password anywhere in the product — either would be a credential that exists whether or not anybody is locked out.

The recovery tool authenticates by something an attacker on the internet does not have: access to the machine.

If you self-host, make sure at least one person on your team has that access and knows they have it. That is the whole of your level-3 plan.

Prevention

Three things, none of which take long, and together they remove almost all of this page:

1. Configure and test-login a second provider before changing the first. A second working way in turns a lockout into an inconvenience.
2. Set base roles. With a base role of viewer, a mapping mistake degrades to “everyone can read” rather than to “nobody can do anything”. See role mapping.
3. Keep at least two administrators, ideally whose accounts do not depend on the same single thing.

Before you change SSO configuration

A short checklist worth running each time:

• Is there a second working way to sign in right now?
• Are base roles set?
• Have I run test login against the new configuration?
• Am I making this change from a session I can keep?