Designed and ratified
Estimated 26.10.1· first week of October
Offline Operation
Staying signed in when the identity provider cannot be reached
Ships, plants, clinics and field sites lose the network, and a customer’s identity provider can be unreachable while everything local keeps working. RealmSSO’s design for that case is continuity, not a fresh login: a user who has already signed in once on a device would keep working on a token sealed into that device, released only behind the device’s own unlock, for a window the customer sets per connection. There is no platform default and no ceiling on that window, because it is precisely the offboarding latency the customer is accepting — someone disabled at their provider would keep working until it elapses. In the design, no device lock means no offline, an unconfigured window means offline stays off, and the unlock is a local gate that never reaches a server. Scope is native mobile applications; browsers and progressive web apps are out. This is a ratified design with no implementation behind it yet — published to be examined and argued with, not bought.
Why Offline Operation?
Everything you need for enterprise-grade identity federation.
Continuity, never a fresh login
Offline here means one thing: the customer’s own identity provider is unreachable. The design keeps a user who is already signed in working, on a token that was issued and sealed while their provider was reachable. It does not sign anybody in. While the only party able to vouch for a user cannot be reached, nothing can honestly mint new identity for them — that is the cost of customers owning their own identity, and it is not a gap a later release closes.
The window is the customer’s to set
How long a device may run disconnected would be configured by the customer, per connection. There is no platform default and no platform ceiling — the risk being priced is their own, so the number is theirs. It is designed to be set deliberately: an unconfigured window is not an unlimited one, it means offline is not configured and stays off.
The window is your offboarding latency
Stated plainly, because it is the first thing a security team asks: a user disabled at the customer’s provider would keep working offline until the window elapses. The check-in that reconnects the device is the only moment revocation is re-evaluated, so the window the customer chooses is exactly the delay they accept on offboarding. A short window means more frequent connectivity; a long one means longer-lived access after a departure. The design makes that trade explicit at the point where the number is set rather than burying it in documentation.
Device unlock gates the sealed token
The token would be sealed into the device keystore and released only behind the operating system’s own unlock — biometric or device PIN. Possession of the enrolled device plus that unlock is what the customer accepts in place of a fresh challenge at their provider, for the length of the window and no longer. Neither is ever presented to a server: the unlock decides only whether the client will use the token it already holds. It is a local gate the customer accepts, and nothing more than that — no challenge reaches the customer’s provider while their provider is unreachable, and this page will not pretend otherwise.
No device lock, no offline
If a device has no lock configured, it has nothing standing in for that challenge, so the design refuses it offline rather than degrading quietly. Requiring a device lock is the value a connection now starts with, so the safe posture is the one you get without configuring anything — though the client that would act on it does not exist yet. Past the end of the window the client is designed to stop and force an online sign-in, where the connection’s full provider-side authentication policy applies again.
Native applications only
Scope is native mobile applications, through an SDK RealmSSO would ship. Browsers and progressive web apps are excluded — not scheduled for later. The design depends on a hardware-backed key released only after an OS-verified unlock, and on storage that is not evicted; neither is something a web platform guarantees today. That exclusion would be revisited only if both become genuinely available, and measured rather than assumed.
Roadmap — and what survives an outage today
None of the above is built. It is a ratified design (ADR 0010, accepted August 2026) with no implementation: the SDK that would enforce the window and the unlock does not exist yet, so the two fields that would bound it — the maximum offline age and the device-lock requirement — are recorded by the API and enforced by nothing. Treat them as a contract awaiting its enforcer, not as live policy. What genuinely does survive a provider outage today is narrower and real: sessions that already exist continue for each hop’s configured lifetime, and offline-token continuity operates where the connection’s policy already enables it. If disconnected sites are your problem, we would rather hear from you while the design is still open.
Interested in early access?
This is a ratified design (ADR 0010, accepted August 2026) and nothing on this page is running in a deployment today. The SDK that would enforce the window and the device unlock is not built, so the two fields that would bound it — the maximum offline age and the device-lock requirement — are recorded by the API and enforced by nothing — do not plan against them as live policy. What does survive an outage today is narrower: existing sessions for each hop’s configured lifetime, and offline-token continuity where a connection’s policy already enables it. If disconnected operation is the problem you have, we would rather hear from you while the design is still open than after it is fixed.