Incident Management Platform  ·  View 33 of 34  ·  7 · Assurance

Identity — Signing In When the Identity Provider Is the Outage

Federated login fails because the corporate identity provider is down. An incident commander still reaches the console, with less power and more scrutiny.

Editable source SVG draw.io All views
Incident commander Console Keycloak Corporate IdP Hardware key Audit events Security rotation 1. open console 2. OIDC redirect 3. federated login 4. timeout 5. offer break-glass 6. local account 7. WebAuthn challenge 8. signed assertion 9. 4 h session · responder role 10. break-glass used 11. notify, never page Identity — Signing In When the Identity Provider Is the Outage Break-glass accounts can acknowledge, resolve and edit incidents. They cannot edit schedules, policies or suppression rules, which can wait for the IdP. v 1.0 · owner Security Architecture · date 2026-09

Decisions

  • Keycloak brokers the corporate identity provider for normal logins and holds a small set of local break-glass accounts, each bound to a registered hardware key. Keycloak runs in the control plane, which is the only thing a console login needs (ADR-26).
  • Break-glass sessions last four hours and carry a responder role: acknowledge, resolve, change severity, post updates. Schedule, policy and suppression edits are unavailable, because those can wait for the identity provider and are the most damaging in the wrong hands.
  • Every break-glass login notifies the security rotation. It does not page them; the event is expected during an identity outage and suspicious outside one.

Accounts

  • About a dozen, held by on-call leads across the three timezones, each with two registered keys. Accounts are reviewed quarterly and exercised in the same drill as the control-plane rebuild.

Not needed for paging

  • Nothing on the paging path uses Keycloak or the corporate identity provider. Acknowledgement by keypress, SMS reply or app works throughout an identity outage.