What should you do in the first hour when your identity provider is down?

Identity is the plane everything else lands on. When Okta, Entra ID, or Google Workspace fails — or is taken — the lockout is simultaneous: email, chat, ticketing, cloud consoles, the password manager, often the monitoring stack. The failure mode isn't one system down; it's your ability to respond down. This checklist covers the first hour. Print it, or store it somewhere that doesn't need SSO to open — a copy behind your IdP is a copy you don't have.

Minutes 0–10: Triage — outage or compromise?

• Check the provider's status page (from a device that doesn't need SSO): a declared global incident points to outage.
• Scan for compromise signals: unexpected MFA prompts reported by users, unfamiliar admin accounts or role grants, changed federation or conditional-access policies, password resets nobody requested, admins locked out while user auth still works.
• Pick the working assumption and say it out loud. Outage → workaround-and-wait posture. Compromise → assume every in-band channel is readable; nothing sensitive gets typed into corporate email, chat, or tickets from this point.
• When in doubt, respond as if compromise. Downgrading later costs nothing; upgrading later means the attacker watched your first hour.

Minutes 10–20: Establish command out-of-band

• Activate the out-of-band channel — the one that doesn't authenticate through the affected IdP (what that means and how to set one up).
• Summon responders with acknowledgment, not broadcast: page phones by voice/SMS, track who confirmed, escalate past who didn't.
• Name the incident lead and the scribe. The scribe starts the timestamped log now — decisions, times, names. This log is tomorrow's insurer/regulator timeline.
• Set the update rhythm (e.g., every 20 minutes on the channel) so people stop improvising side conversations in potentially compromised tools.

Minutes 20–45: Restore capability surgically

• List the systems that actually need admin action right now — usually a short list: the IdP's own emergency admin, the primary cloud console, the EDR/security console, DNS. Everything else can wait.
• Release break-glass credentials for that list only, through the approval path. Quorum release, each access alerted and logged. The emergency is the reason the control exists, not a reason to skip it.
• Do not mass-disable SSO or MFA to "restore access" — that opens every account to direct attack at the worst possible moment. Restore narrowly.
• If compromise is suspected: from the emergency admin path — revoke active sessions and refresh tokens, freeze federation/conditional-access changes, snapshot IdP audit logs before they age out or get purged, and disable the suspicious admin principals.
• Record every credential used — which, by whom, approved by whom, for what. You'll rotate all of them afterward.

Minutes 45–60: Stabilize and communicate

• Decide the user-facing message — what employees are told, on which channel they can actually receive it (their email may be down too: pre-registered personal endpoints are what makes this reachable), and who is allowed to say it.
• Check regulatory clocks if compromise is on the table: DORA and NIS2 both carry early-notification deadlines measured in hours, not days. Note the decision and its time in the log either way.
• Confirm the containment perimeter — what's frozen, what's isolated, what's still trusted — and post it to the channel so responders stop re-deciding it.
• Schedule the first review checkpoint and hand the running log to whoever owns the after-action.

Afterward: the gaps this hour just found

Every real IdP incident and every good tabletop of this scenario surfaces the same handful of gaps. Close them while the memory is fresh:

1. Break-glass credentials locked behind the thing that failed — move them to storage independent of the identity plane, quorum-released, alert-on-access.
2. No pre-enrolled out-of-band channel — responders swapped personal numbers mid-incident. Enroll everyone now, verify in the next drill.
3. Stale rosters — the emergency contact list was two hires out of date; the departed admin still held a keyshare.
4. No log — the timeline had to be reconstructed from memory for the insurer. Attributed, timestamped logging should be a by-product of responding, not a chore after it.
5. Rotate everything the hour touched — every break-glass credential used gets rotated and re-sealed; the post-use review gets written (your break-glass procedure should require both).

Glassbreak exists to make items 1–4 already true before the bad day: quorum-gated break-glass storage independent of your IdP, pre-enrolled E2EE chat/calls and voice/SMS/email alerting with acknowledgment tracking, and append-only attributed logs — producing the evidence pack your insurer or auditor asks for afterward. But the checklist stands on its own: run it against whatever you have, and let the gaps it finds set your to-do list.