Preview draft. Copy and visuals are pending review and may change before launch.

Practice

Authorization for offline and disconnected operation

The usual latency-versus-freshness tradeoff assumes a live source is at least reachable eventually, on demand. Genuine disconnection removes that assumption entirely.

← Back to the library

Governance, Incident Response, and Resilience · Published 2026-09-06

A more extreme version of an already-familiar tradeoff

An offline authorization cache stores a previously obtained decision locally for a device or application to rely on when it genuinely cannot reach the authoritative policy source — not a brief network hiccup, but real, sometimes extended disconnection: a field device with no signal, an app used somewhere without connectivity. This is a sharper version of the ordinary caching tradeoff, because there's no live source to check freshness against at all until connectivity eventually returns.

The design question this forces is stark precisely because there's no live check available during the gap: how long should a cached decision remain honored before the device simply refuses to act on it at all, given that the principal's actual authorization could have changed at any point during the disconnection with absolutely no way for the offline device to know.

What happens once connectivity comes back

Reconciliation is what closes this loop: comparing the decisions made locally during disconnection against what the authoritative source would have actually decided, once connectivity returns, and resolving any difference explicitly rather than silently. An action taken offline under a grant that's since been revoked needs a deliberate response once that's discovered — simply refreshing the cache for next time and moving on leaves whatever already happened during the disconnected window unexamined, whether or not it should have been allowed to happen at all.