Cairn overview
Identity continuity · Government · Defence · Enterprise

Keep logging people in the day your identity provider goes down.

Modern identity has a hidden single point of failure: the cloud control plane — Okta, Entra, Active Directory, and the SAML/OIDC federation governments run on — has to be reachable for anyone to log in. When it isn't, the whole organisation stops authenticating even though the applications themselves are still running — the app is alive; identity is dead. Cairn explores a different assumption: that a new login can be admitted — and a compromised device revoked — after that control plane disappears, with no server in the loop.

DUAL-USE · CONTINUITY OF OPERATIONS

Because the issuer speaks the standard SAML / OIDC that government identity federation already runs on, this is continuity-of-operations against cyberattack for government and defence IT — a base, garrison or department kept authenticating, and able to lock out a compromised account, when its identity provider is ransomwared — as much as it is an enterprise break-glass tier.

Honest boundary: a TRL ~4–5 research prototype validated on commercial software (Keycloak, Grafana). It is applicable to, not deployed on, any government system.

SOVEREIGN CONTINUITY · THE CANADIAN ANGLE

The 2026 precedents are real: a US-controlled cloud can be cut off by an export order or a policy decision, not just an outage. Because Cairn has no foreign control plane in the loop, a Canadian department, base or hospital keeps authenticating on Canadian soil when a US cloud identity provider goes dark.

Proven end-to-end in the sovereign kill-switch drill, on real off-the-shelf software: foreign IdP cut off (unreachable) → the Canadian sovereign issuer logs a device into real Grafana with zero foreign control plane in the loop → a seized device is revoked offline → a post-quantum (ML-DSA-65) token is issued → the foreign IdP is restored. 8 / 8 steps, a signed audit that replays 9 / 9 byte-for-byte.

WHY THIS MATTERS

This isn't only a ransomware story — it's an architectural one. Today identity assumes the cloud is always reachable; the same failure hits a ransomware'd IdP, a cloud outage, a severed network, a disaster-recovery cutover, or any inherently disconnected site — a ship, a mine, a hospital under attack, an offshore platform, a forward operating base. RAID didn't stop disks failing; it made failure survivable. Kubernetes didn't stop servers crashing; it made crashes non-catastrophic. Cairn is the same move for identity — keep authentication, and revocation, operational when the control plane disappears. It's what I'd call identity continuity, alongside high availability, disaster recovery and business continuity.

Can a new user authenticate safely — and a compromised one be revoked — after the identity provider has disappeared?

THE IDEA

The interesting part isn't any single ingredient — not OIDC, not post-quantum, not the token format. It's the architecture: trust decisions move from a central authority to a continuously re-evaluated peer consensus, while still interoperating with the identity systems you already run. Put plainly: the identity control plane no longer has to be continuously reachable — the cloud becomes optional, not mandatory. Everything below is evidence for that one claim — that a new identity can be admitted, and a compromised one revoked, with no reachable control plane.

This combination — admitting new identities offline AND revoking them offline with no reachable control plane — is the differentiator. There is a commercial “identity continuity” category (e.g. Strata Identity), but it fails over between cloud IdPs and still assumes the cloud is reachable; SPIRE, Entra backup-auth and AD cached-logon each do at most one of admit / revoke, and none with no server at all. The gap is the no-reach-back, edge / air-gapped case. If there's prior art that admits and revokes with no server, I'd genuinely like to see it.

THE EVIDENCE

Six ways it was tested — pick one

Each tab is a real, re-runnable run — from an enterprise IdP outage to a government-style SAML federation to a real Kubernetes API server on managed cloud — the same claim attacked from a different angle.

PROOF · REAL SYSTEMS

On real enterprise software — Keycloak + Grafana

A real identity provider (Keycloak), a real off-the-shelf app (Grafana), real TLS — wired together, then the IdP is killed. The app keeps people logged in through Cairn, locks out a seized device, and hands authority back when the cloud returns. Eight steps, measured end to end.

cairn-mesh
THE IdP BLACKOUT DRILL   —   real, off-the-shelf enterprise software
  Keycloak 26 (the IdP)  ·  Grafana 13 (a real OIDC app)  ·  Cairn issuer  ·  Caddy TLS (pinned JWKS)

[1] NORMAL     user logs in through the central IdP (Keycloak) ............ OK   (325 ms)
[2] BLACKOUT   kill the IdP completely ................................... token endpoint DEAD
[3] EXISTING   a token the IdP already issued is still valid ............. OK
[4] NEW LOGIN  a NEW device authenticates into REAL Grafana — IdP down ... HTTP 200   (118 ms)
               its EdDSA token validated against the JWKS over TLS · authLabels = [JWT]
[5] COMPROMISE device declared seized  ->  revoked at the issuer ......... OK
[6] DENIED     the seized device is refused on its very next request ..... HTTP 403   (revoke->deny 12 ms)
[7] OTHERS     an uncompromised device keeps authenticating ............. HTTP 200   (0 false denies)
[8] RESTORE    bring the IdP back; normal login resumes ................. OK   (handoff 4.5 s)
[AUDIT] verify the issuer's own signed decision ledger .................. OK   (chain + sigs + replay)

RESULT: a real enterprise app kept people logged in — and locked out a compromised device —
        through a COMPLETE identity-provider outage, then handed authority back. Every decision
        is in a signed, replayable ledger.  Issuer footprint: 4.7 MB RAM.  One re-runnable script.

How this was validated

What it shows
A real enterprise app continuing to authenticate users — and revoking a compromised one — through a complete identity-provider outage, then handing control back. The full “identity continuity” claim, demonstrated.
Real / synthetic
All real, off-the-shelf software over real TLS: Keycloak 26 (IdP), Grafana 13 (the relying-party app), the Cairn issuer, Caddy 2.11 (TLS + pinned JWKS). The outage and the steps are scripted; the software, the cryptography and every number are real and verbatim.
Independent reproduction
The entire drill is one re-runnable script — anyone can stand up the same stack and watch Grafana accept a Cairn break-glass token while Keycloak is dead.
Measured
New-login-while-down: 118 ms. Revoke→deny: 12 ms. False denies: 0. Recovery handoff: 4.5 s. Token validated as a standard EdDSA JWT against the JWKS over TLS. Numbers are verbatim from the canonical drill run.
A real service, not a script
The drill runs the productized issuer: a config-driven service with persisted device enrollment, an admin CLI (enroll / revoke / rotate-key), key rotation with a multi-kid JWKS, health/metrics, and a signed, hash-chained audit ledger that replays byte-for-byte. It speaks both enterprise SSO standards — a standards-complete OIDC Provider (authorization-code flow) and a native SAML 2.0 IdP — so any OIDC or SAML app can use it as a drop-in failover IdP, with DPoP (RFC 9449) sender-constraining and an optional live-mesh admission gate. It is also crypto-agile by design — a pluggable signer (Ed25519 → hybrid → ML-DSA-65, RFC 9964) decouples the identity architecture from the signature algorithm, so the same issuer survives a cryptographic migration with the JWKS publishing both keys and relying parties moving one at a time. Post-quantum verification is now demonstrated live in the operator console — a real ML-DSA-65 signature verified in the browser, not merely available.
How it was produced
Verbatim from the drill run against the cairn-breakglass service. Full harness and reproduction under NDA.

This is still a lab drill on real components, not a fielded deployment — TLS is terminated at a reverse proxy, and a 48–72 h soak plus an independent security assessment remain before a customer pilot (see the failure envelope below). What's real: an unmodified enterprise app accepted the offline-minted token and kept working through the outage; the issuance was gated by a live mesh admission decision (a mesh revocation denies the next token); every decision is in a signed, replayable ledger; and the issuer speaks both OIDC and SAML with DPoP.

HOW IT COMPARES

Against today's outage answers

Identity-continuity features exist — but they assume the cloud is reachable, or only keep already-open sessions alive. None admits a fresh login and revokes a device with no server at all.

Identity continuity todayCairn break-glass
When the IdP is fully offlineCloud “backup auth” still needs the provider’s own cloud; a true outage stops new sign-ins.No server in the loop — a local issuer mints tokens with zero cloud reach-back.
New logins during the outageGenerally no — only tokens for sessions that were already open are re-issued.A new device is admitted offline if the mesh vouches for it (≥T anchors, ≥2 regions).
Revoking a compromised deviceDepends on the cloud to push revocation; little to nothing happens offline.No revoke message is sent: the next request is denied because the required peer endorsements are gone — nothing to jam, spoof or censor.
Token compatibilityProprietary or tied to the vendor.Standard OIDC / EdDSA JWT — accepted by stock relying parties (PyJWT, jose).
CryptographyClassical.Mesh transport + trust root are post-quantum (Rosenpass; hybrid ML-DSA-65). Tokens use standard EdDSA or ES256 — what OIDC apps and Kubernetes / cloud IAM accept today — with post-quantum ML-DSA-65 (RFC 9964) a config change.

Cairn complements your identity provider — it doesn't replace it. When the cloud is healthy, your IdP stays authoritative. Cairn is the break-glass path that keeps authentication alive and revocable for the hours or days the cloud is unreachable, then hands control back.

“Isn't this just Strata?”

Strata Identity's continuity is enterprise identity orchestration — a layer in front of your apps that fails over between cloud identity providers (Okta → Entra, cached policy). It's mature and it's the right answer when your problem is “one cloud IdP is down — route to another.” Cairn targets the case that model can't reach: there is no other cloud to fail over to.

  • No reach-back — Cairn decides locally, so it runs on-prem, at the edge, air-gapped, or in a disconnected tactical mesh, where an orchestration layer (itself a cloud dependency) isn't reachable either.
  • Admits new identities offline — not just re-issues for cached users — via mesh peer-vouches, with no server.
  • Revokes with no message — a compromised device drops out because its endorsements expire; nothing to push, jam or censor.
  • Post-quantum, sovereign / defence posture — PQ transport + trust root, built for contested and disconnected environments.

In one line: Strata fails over between cloud IdPs; Cairn keeps authenticating when there's no cloud at all. Different failure domain — complementary, not the same product. And the honest edge: Strata is a shipping, funded platform with real customers; Cairn is a TRL ~4–5 prototype in a niche Strata doesn't serve.

Where it stops working (the failure envelope)

Limits make a system easier to trust, so here are the real ones — the boundaries this architecture does not cross:

  • This is resilience, not prevention. Cairn keeps the identity layer operational when its control plane is unreachable. It does not stop ransomware itself, endpoint malware, local-disk encryption, or stolen credentials — those live outside the identity control plane and need their own defences. The claim is offline admission + offline revocation + standard-OIDC interop under the scenarios tested, not that an outage becomes a non-event.
  • Region independence is load-bearing. Admission requires vouches across ≥2 trust regions; if an attacker genuinely controls endorsers in two independent regions, the diversity rule is satisfied. The bar is “compromise two independent regions,” not infinity — but it is the assumption to get right.
  • A targeted jammer can force a liveness failure. Absence-based revocation can't be forged out of — but an adversary who can selectively jam until a node sees only one region can push it below quorum (a denial-of-service, not a trust break). Mitigated by over-provisioning vouchers and multi-path delivery; not eliminable (it's a fundamental availability limit).
  • Anchor compromise is bounded, not zero. The M-of-N trust anchor means one compromised anchor can't mint members; ≥M compromised anchors can.
  • The token side depends on authenticated JWKS distribution (TLS + a pre-pinned issuer key — the managed-cloud deployment uses Google-managed public TLS). Bearer-token replay is now closed by mandatory proof-of-possession: minting requires a DPoP proof bound to the device's enrolled key, and the issued token is sender-constrained (cnf.jkt). ES256 is shipped (for Kubernetes / cloud IAM); post-quantum ML-DSA is a config flip — and PQ verification is now demonstrated live in the operator console (a real ML-DSA-65 signature verified in the browser), not merely available.
  • Quantum posture is precise, not absolute. The mesh transport and trust root are post-quantum (Rosenpass; hybrid ML-DSA-65). Tokens default to EdDSA (what relying parties accept today). The deeper point is a design property, not an algorithm: the issuer is algorithm-agnostic — a pluggable signer spans Ed25519 → hybrid → ML-DSA-65 (RFC 9964), the JWKS publishes both keys, and relying parties migrate independently, no flag day. We don't claim quantum-secure tokens; we claim the architecture survives the cryptographic migration — of which ML-DSA is one expression.
  • Performance is not the bottleneck — the admission check measures at ~110 µs; full latency/bandwidth/CPU figures are on the Technical Validation page.

Honest status & references

  • TRL ~4–5. The hardened issuer is deployed on real managed cloud (Google Cloud Run, public HTTPS) and proven to interoperate with real software — Keycloak, Grafana, a government-style SAML federation, and a real Kubernetes API server. It ships admin-auth, mandatory proof-of-possession (DPoP), ES256 + ML-DSA agility, durable revocation and a signed replayable audit — and passed a 13/13 self red-team. What remains before a production pilot: a third-party penetration test, a security certification (CMVP), and multi-writer high availability. Mechanism and source under NDA.
  • • Token format: IETF RFC 8037 (Ed25519 / EdDSA for JOSE) and OpenID Connect Core 1.0. rfc8037 · openid.net
  • • Context — a single-IdP outage is a total-failure mode: the 2024 Change Healthcare ransomware incident and repeated Okta/Entra outages. Incumbent “backup authentication” only covers already-open sessions.
  • • Validated against production OIDC libraries: PyJWT and jose (the library NextAuth / openid-client build on).

Worried about your one front door?

Research prototype (TRL ~4–5). See how every Cairn result is produced on the Technical Validation page; design, source and the full validation set are under NDA.