# Recover from an SSO lockout

Requiring single sign-on for a domain means only that domain's connection can
admit the people whose address is on it. If the provider stops signing anyone in
— an expired client secret, a revoked application assignment, a Conditional
Access policy that matches nobody, a deleted group — none of them reaches the
company, including the administrators who could turn the requirement back off.

Members on a domain you never registered are unaffected: their password,
passkey, and personal Google, Apple, or Microsoft sign-ins still reach the
company. **If one of them is an administrator, there is no lockout** — they can
turn the requirement off on the SSO page themselves. What follows is for the
case where every administrator is on a required domain.

Recovery then goes through LedgerBee support.

## Contact support

Email [support@ledgerbee.com](mailto:support@ledgerbee.com) from an address on
the domain the company has verified, and state:

- the company name,
- which domain requires single sign-on, and that it has locked every
  administrator out,
- what changed at your identity provider, if you know.

LedgerBee confirms you are an administrator of that company before changing
anything, out of band from the email itself. Expect a phone call to a number on
record or a request to publish a one-time `TXT` record in the verified domain.
An email alone does not establish who you are, and the lockout has already
proved the account's normal sign-in path is unavailable.

Once you are verified, LedgerBee turns the requirement off on every domain at
that company. Every other sign-in method reaches the company again immediately:
passwords, passkeys, and personal Google, Apple, or Microsoft accounts that
already had access. The connections and the verified domains are left as they
are, so nobody loses access and each domain is ready to require again once its
connection works.

The change is recorded in the company's own activity log under
**Settings → Organization → Change log**, with who made it, when, and the value
before and after. Read it once you are back in.

## Reduce the chance of needing this

| Do this | Why |
| --- | --- |
| Track your client secret's expiry date | An expired secret is the most common cause, and the provider gives no warning |
| Re-run the check (**Check again**, or just save) after any change at the provider | It is what proves your provider still accepts the stored credentials |
| Keep the `TXT` record published | A lapsed record does not lock anyone out, but it does pause linking new members by email address |
| Keep one administrator on an address you have not registered | Their password or passkey still reaches the company, so the requirement can be turned off in-product |

A requirement is not relaxed automatically when the provider stops answering. One
that switched itself off whenever a network lookup failed would be no
requirement at all, and the most common failure leaves the provider serving its
discovery document while refusing every user — so nothing would detect it.