Skip to content
Notes

Continuity briefing

Identity when the network is absent

Disconnection does not remove the need for identity. It changes which facts can be refreshed, which authority can be trusted locally and how long a decision may remain acceptable before reconciliation.

For Mission owners · identity architects · resilience teams 7 min read

Published
Reviewed
Revision
1.0
Owner
AstraSutra Editorial
In this note 5 sections

Decision model

Trust is prepared before the gap and reconciled after it

Trust is prepared before the gap and reconciled after itBefore disconnection, an operator pre-positions approved identities, verification keys, policy and bounded credentials. During the gap, the local environment verifies only what it can prove and queues evidence. A signed transfer carries evidence across the boundary, and reconnect triggers replay checks, reconciliation and a fresh authority decision.

Illustrative architecture, not a deployed topology. The gap removes live authority reach; it does not suspend expiry or make queued evidence equivalent to central confirmation.

In words

Before disconnection, an operator pre-positions approved identities, verification keys, policy and bounded credentials. During the gap, the local environment verifies only what it can prove and queues evidence. A signed transfer carries evidence across the boundary, and reconnect triggers replay checks, reconciliation and a fresh authority decision.

  1. Pre-positioned trust
  2. Visible network gap
  3. Bounded local operation
  4. Signed transfer and reconciliation

01

Disconnection turns freshness into a design decision

A connected identity system can ask whether an account is active, a credential has been revoked or a policy has changed. A disconnected system cannot assume those questions remain answered merely because yesterday’s verification succeeded. Its local state is a snapshot whose age grows with the outage.

Continuity begins by deciding which facts may be cached and which require a live authority. The answer should vary by consequence: reading a low-impact local record is not the same decision as releasing a privileged capability or exporting sensitive data.

02

Pre-position trust deliberately

Offline verification depends on material prepared while authority was reachable: approved identities, public verification keys, policy, credential bounds and a protected time or monotonic-state reference. That package needs an owner, a version and an expiry. A cache with no provenance is simply an old database.

Pre-positioning should also define negative space. Unknown identities, missing keys, expired policy and unverifiable signatures should fail closed. Emergency exceptions, if the mission requires them, should be separate, explicit and evidential—not a hidden fallback that turns absence of connectivity into unlimited local trust.

03

Bound the local decision

Credential life is the most visible bound, but it is not the only one. Local operation may also be constrained by data classification, device state, operation type, delegation scope, use count or a maximum duration since the last trusted synchronisation. The purpose is to make residual authority finite and reviewable.

A bounded decision does not guarantee that central state has not changed. It states how long the organisation is willing to act without learning that change. NIST SP 800-63’s lifecycle and privacy framing is useful here: identity assurance includes enrolment, authentication, lifecycle events and risk, not only a successful cryptographic check.

04

Queue evidence; do not pretend it has reconciled

Disconnected events can be recorded locally with protected ordering and later moved through a signed transfer. The transfer should bind its source and contents, reject replay and preserve gaps rather than smoothing them away. Until the receiving authority accepts and reconciles the record, the evidence remains queued—not centrally confirmed.

Reconciliation must be able to disagree. A local action may be authentic and still conflict with a newer central revocation or policy. The resulting outcome should distinguish accepted history, rejected history, conflict and missing evidence instead of reducing every return from the field to a green synchronised state.

05

Reconnect is a security transition

When communication returns, the system should refresh authority before resuming ordinary operation. It must check transfer integrity and replay, apply lifecycle changes, resolve conflicts and establish a new bounded state. Connectivity itself is not reconciliation; it merely makes reconciliation possible.

A strong evaluation rehearses the uncomfortable sequences: revocation during the gap, a credential expiring locally, a repeated evidence bundle, a clock disagreement, partial transfer and a reconnect that fails halfway. The objective is not seamlessness. It is a controlled, observable transition between two security states.