Disconnected and Austere Operations

Andi Lamprecht ·2026-05-11· 22 min read· Draft

1. Why Disconnected Operations Matter

Many of the operations ATOMx must support cannot assume connectivity at the time and place of flight: rural infrastructure inspection, disaster response, wildfire perimeter surveillance, federal training ranges, remote logistics, and cross-border or austere deployments. Public safety responders who need to verify a drone overhead may also be operating in a degraded-comms environment.

Disconnected operation is therefore a first-class capability requirement. The system must:

• Allow a drone to fly with a fully verifiable authorization even when it cannot reach ATOMx
• Allow an authorized field user (law enforcement, public safety, airspace authority) to verify identity, authorization, and conformance using only locally received RF signals plus pre-cached or sideband-fetched material
• Preserve the same audit and accountability properties as connected operation, with reconciliation when connectivity returns

The design principle is pre-cleared trust, deferred reconciliation. Authorization is established online while connectivity is available, packaged into a signed offline capsule, and verified locally during the disconnected window.

What Changes When You Go Offline

Connected mode is the primary operational mode and the baseline. Disconnected mode preserves the same trust properties through different mechanisms.

2. Identity, Organizations, and Trust Hierarchy

2.1 The Organization Model

Every actor in ATOMx — including individual humans — belongs to an organization in the ATOMx identity and access management (IAM) system. The organization’s type determines what its members can do. This is the same model used across the rest of the ATOMx platform; disconnected operations inherit it.

A pilot is modeled as an individual user who is also the sole member of a single-person organization of type Pilot. This preserves the rule that every user belongs to an org while reflecting that an individual pilot can carry personal regulatory responsibility (for example, under Part 107 recreational and commercial sUAS rules).

A pilot is always affiliated with one or more operators. The pilot org is the unit of personal responsibility; the operator org is the unit of organizational responsibility. Flight authorization requires both — ATOMx will not issue an authorization for a pilot who is not currently affiliated with an active operator unless the pilot’s regulatory category permits self-operation.

Field verifiers are users of an Authority org. A police officer doing roadside drone verification, an FAA inspector, or a public-safety responder is just a member of an Authority-type org with the field-verification permission. There is no separate “field verifier” org type.

    flowchart LR
    User[Individual User] -->|member of| Org[Organization]
    Org --> Auth["Authority<br/>e.g., FAA, state police"]
    Org --> Manu["Manufacturer (OEM)<br/>e.g., DJI, Skydio"]
    Org --> Op["Operator<br/>e.g., Part 135 carrier"]
    Org --> Pilot["Pilot<br/>single-person org"]
    Pilot -. affiliated with .-> Op
    Auth -. issues authorizations to .-> Op
    Auth -. issues authorizations to .-> Pilot
    classDef otype fill:#eef3ff,stroke:#1f6feb
    class Auth,Manu,Op,Pilot otype
  

2.2 Trust Hierarchy

Each org type maps to a certificate chain rooted at the ATOMx Root Certificate Authority (CA). All certificates are independently rotatable; compromise of one chain does not compromise the others.

The Root CA is held in a Hardware Security Module (HSM) — a tamper-resistant hardware device that holds cryptographic keys and performs signing operations without ever exposing the private key. The Root HSM is kept offline; it is brought online only for infrequent, audited key ceremonies that sign new intermediate CAs.

    flowchart TB
    Root["<b>ATOMx Root CA</b><br/>HSM-backed, offline"]
    Root --> OEMCA["Manufacturer Intermediate CA<br/>per OEM org"]
    Root --> OpCA["Operator Credentialing CA"]
    Root --> PilotCA["Pilot Credentialing CA"]
    Root --> AuthCA["Authority Credentialing CA"]
    OEMCA --> ACert["Aircraft Identity Cert<br/>hardware-bound, per airframe"]
    OpCA --> OpCert["Operator Org Cert"]
    OpCert --> OpUser["Operator User Cert<br/>per human"]
    PilotCA --> PCert["Pilot Cert<br/>per individual"]
    AuthCA --> AOrg["Authority Org Cert"]
    AOrg --> ADev["Managed Field Device Cert"]
    AOrg --> APerson["Person-Bound Field Credential<br/>for verifiers"]
    classDef root fill:#fff7d6,stroke:#b58900
    classDef inter fill:#eef3ff,stroke:#1f6feb
    class Root root
    class OEMCA,OpCA,PilotCA,AuthCA inter
  

2.3 The ATOMx Root CA

The Root CA is held in an HSM and kept offline. It signs only intermediate CAs — never end-entity certificates. Root key ceremonies are infrequent and audited under dual control. The Root public key is the only trust anchor that needs to be embedded in aircraft secure elements, authority field devices, and integrating systems.

2.4 Manufacturer, Aircraft, Operator, Pilot, and Authority Onboarding

The lifecycle events that issue and bind credentials — OEM CA provisioning, factory aircraft minting, operator registration, pilot enrollment, authority and field-verifier credentialing — are documented in their own pages:

• Onboarding Manufacturers
• Onboarding Aircraft
• Onboarding Operators and Pilots
• Onboarding Authorities

This page assumes those events have happened and focuses on what makes the resulting credentials verifiable offline.

2.5 Why the Chain Works Offline

Every aircraft ships with the ATOMx Root public key as an immutable trust anchor inside its secure element, plus its identity certificate signed by its OEM’s intermediate CA. Authority field devices ship with the same Root anchor. This means the chain of trust for any in-flight aircraft can be validated entirely offline by anyone holding the ATOMx Root public key plus a current Manufacturer CA list — no contact with ATOMx required during the flight.

The technical foundation is in PKI and Chains of Trust; the hardware substrate is in Aircraft Hardware Identity.

3. Aircraft Lifecycle Recap

The aircraft moves through a sequence of states from factory floor to active flight. Each transition is gated by a signed event recorded in the ATOMx audit ledger. The full state model and entry conditions are in Onboarding Aircraft §3; the diagram is reproduced here for reference because the disconnected sections below assume it.

    flowchart LR
    M(Manufactured) --> R(Registered)
    R --> P(Pilot-Assigned)
    P --> C(Connected-Ready)
    C --> A(Authorized-for-Flight)
    A --> F(Flying)
    F --> Re(Reconciled)
    Re --> C
    C --> X([Revoked])
    classDef active fill:#eef3ff,stroke:#1f6feb
    classDef terminal fill:#ffe1e1,stroke:#b91c1c
    class M,R,P,C,A,F,Re active
    class X terminal
  

3.1 How Aircraft Reach the Internet

Most consumer and prosumer drones today do not have their own cellular modem. The dominant connectivity topology is:

    flowchart LR
    Aircraft -->|proprietary RF<br/>BT / OcuSync / Lightbridge| Ctrl[OEM Handheld Controller]
    Ctrl -->|USB or Bluetooth| Phone[Pilot Mobile Device<br/>OEM or third-party app]
    Phone -->|cellular / Wi-Fi| Internet
    Internet --> ATOMx
  

The pilot’s phone provides internet access to the controller, which relays data and commands to the aircraft. ATOMx works within this topology: the operator app on the phone is the data path that delivers Authorization Packages, capsules, and revocation data to the aircraft, and that uploads flight logs from the aircraft. Some larger or commercial-class aircraft have an onboard cellular modem and connect directly; this is treated as a simpler degenerate case of the same flow.

What needs to be placed on the aircraft

For full ATOMx participation, the aircraft must hold:

Mechanisms to load it

Whichever mechanism is used, the aircraft’s secure element verifies the ATOMx signature on every loaded artifact and refuses anything that does not chain to the embedded Root.

Routine check-in contents

Whenever the aircraft has connectivity through any of these paths, it performs a routine check-in over mutual TLS (Transport Layer Security with both sides authenticating each other’s certificates). Each check-in exchanges:

Routine connection is essential even if the next flight will be disconnected: it is how the aircraft acquires the next Authorization Package, capsule, and revocation snapshot before going offline.

4. Flight Planning and Offline Capsule Generation

4.1 Authorization Always Happens Online

This separation matters: it lets ATOMx enforce its full set of checks (airspace deconfliction, credential validity, regulatory constraints, jurisdiction, dynamic restrictions) at issuance time, and then produce a self-contained authorization that holds up without further server contact during the flight.

Because the issuance moment can be decoupled in time from the flight moment, ATOMx supports several authorization profiles for operators and pilots who need to fly in austere environments:

All four profiles produce the same capsule format. They differ only in the size of the validity window and the scope of the approved-operation geometry. Time-bounded and blanket authorizations are subject to stricter conformance and audit requirements because the trust horizon is longer.

4.2 Plan Submission and Authorization

While connected, the pilot submits a flight plan or operating area through the operator app. ATOMx validates pilot, operator, and aircraft credentials, checks airspace, deconflicts, and produces a signed Authorization Package per the standard connected flow (see System Design §2.1).

For disconnected flights, ATOMx additionally produces an Offline Capsule that contains everything an aircraft and an authority field verifier will need during the flight without connectivity.

4.3 Offline Capsule Composition

The capsule is a compact signed object. Its contents are tuned to fit constrained channels and to be independently verifiable.

The capsule is signed by ATOMx with a key chained under the Root. Authority field devices and aircraft only need the Root public key to validate the chain.

What “envelope encryption” means here

The protected claims (pilot identity, operator details, control-station location) are envelope-encrypted: the actual data is encrypted with a one-time random data-encryption key, and that data-encryption key is itself encrypted with a long-lived key managed by ATOMx’s Key Management Service (KMS). The capsule carries both: the encrypted data and the wrapped data-encryption key. To decrypt, the receiver must hold (or be able to obtain a release of) the unwrapping key inside its secure enclave.

This pattern lets ATOMx issue distinct wrapped keys for different recipient classes (e.g., one wrap for authority field devices in a given jurisdiction, another for the aircraft itself) without re-encrypting the bulky payload, and lets keys be revoked or rotated without invalidating already-encrypted data.

    flowchart TB
    subgraph ATOMx["ATOMx (online at issuance)"]
        Plan[Flight Plan]
        Ids[Pilot / Operator / Aircraft Certs]
        Auth[Authorize: validate, deconflict]
        Mfst[Sign Authorization Package Manifest]
        EnvE[Envelope-Encrypt Protected Claims via KMS]
        Build[Assemble & Sign Offline Capsule]
        Plan --> Auth
        Ids --> Auth
        Auth --> Mfst
        Mfst --> Build
        EnvE --> Build
    end
    Build --> A[Aircraft Secure Element<br/>via operator app / controller / direct cellular]
    Build --> B[Authority Field Devices<br/>pre-synced cache for jurisdiction]
    classDef recipient fill:#fff7d6,stroke:#b58900
    class A,B recipient
  

The capsule has two independent recipients and travels through two independent channels:

• The aircraft receives it through the connectivity topology described in §3.1 (typically: ATOMx → operator app on phone → OEM controller → aircraft secure element). The aircraft uses it during flight to produce live broadcast attestations and to enforce its own conformance.
• Authority field devices receive it through their MDM-managed sync with ATOMx, scoped to the jurisdictions and time windows their org is responsible for. They use it to validate broadcasts they observe and to perform protected disclosure when authorized.

These two paths are separate. The aircraft cache is single-capsule (the one for its current flight). The authority cache is a rolling pre-distribution of every capsule whose approved-operation geometry intersects the authority’s jurisdiction within a given time window.

4.4 Capsule Transfer to Aircraft

The capsule is transferred to the aircraft through whichever connectivity mechanism is available at planning time (see §3.1). The aircraft’s secure element verifies the ATOMx signature and the chain to the Root, confirms the airframe serial matches its own, and stores the capsule. Multiple capsules may be staged for back-to-back disconnected flights.

If the aircraft cannot validate the capsule signature, validity window, or airframe binding, it refuses to enter Authorized-for-Flight state.

5. Disconnected Flight and Local Broadcast

Once airborne with a loaded capsule, the aircraft transmits identity, telemetry, and authorization proof entirely over short-range RF. There is no assumption of reach-back to ATOMx during the flight.

5.1 Time Tampering as a Threat Surface

In an offline window, the only authoritative time anchor a verifier can rely on is the one inside the capsule and inside the field device’s secure enclave. A drone could attempt to fly outside its validity window by manipulating its onboard clock; an attacker could spoof Global Navigation Satellite System (GNSS) signals to inject false time; a verifier device could have its operating-system clock rolled forward or back.

ATOMx layers several mitigations:

The general principle: time is a credential, and the system does not trust any single time source. Aircraft and field devices each independently track their last trusted ATOMx time anchor in tamper-resistant hardware, and degrade gracefully when their confidence in current time is low.

6. Authority Field Verification

A user inside an authority org with the field-verification permission performs verification on a managed device. The flow:

    sequenceDiagram
    autonumber
    participant Drone as Aircraft
    participant FV as Authority Field App
    participant SE as Device Secure Enclave
    participant Cache as Local Capsule Cache
    Drone-->>FV: BT / Wi-Fi broadcast (token, hash, live signature)
    FV->>SE: Person + device credential check
    SE-->>FV: Active credential, scope OK
    FV->>Cache: Lookup capsule by hash
    alt Cache hit
        Cache-->>FV: Offline Capsule
    else Cache miss
        FV->>Drone: Wi-Fi Direct sideband request
        Drone-->>FV: Offline Capsule
    end
    FV->>FV: Verify cert chain to ATOMx Root
    FV->>FV: Verify capsule signature + validity window
    FV->>FV: Verify revocation snapshot freshness
    FV->>FV: Compare broadcast telemetry vs approved operation
    FV->>SE: Request protected field decrypt (purpose, role, geography)
    SE-->>FV: Permitted fields released
    FV-->>FV: Display authorized operational state
    FV->>FV: Generate signed disclosure receipt
  

6.1 Field Device Setup

Field device enrollment, the three required factors (person-bound credential, managed-device credential, purpose code), and the contents of a fully-provisioned device are documented in Onboarding Authorities §3. The remainder of this section assumes a verifier with a fully-provisioned device, in the field, with capsules pre-synced for the jurisdiction. Verification outside the credential’s geographic and time scope requires break-glass (§6.5).

6.2 Receiving and Validating a Broadcast

Validation is layered. A broadcast that fails any layer falls back to a coarser state — never silently passes.

6.3 Local Conformance Evaluation

The capsule contains the approved operation geometry. The field device runs the same conformance logic as ATOMx, locally:

• Is broadcast position within the approved polygon / corridor?
• Is altitude within the approved band?
• Is the time window still valid?
• Is the aircraft’s vector consistent with the approved operation pattern?

The result drives the public trust state shown to the field user (Within / Not Within / Not Publicly Verifiable) and feeds the authorized operational view.

6.4 Protected Disclosure Offline

When the verifier needs more than the public state, they tap a purpose code. The device’s secure enclave releases the protected fields permitted for that combination of person, device, geography, and purpose. Field-level filtering applies the same as in the connected case: the device may release pilot identity but not control-station location, depending on policy.

Every disclosure produces a signed disclosure receipt stored on the device for later upload.

6.5 Break-Glass Procedure

For exigent circumstances outside normal scope (active threat, life safety), break-glass releases an extended set of fields after:

• Explicit confirmation from the verifier
• Stated free-text justification
• Marker on the disclosure receipt

Break-glass disclosures are flagged in reconciliation and trigger after-action review.

7. Reconciliation

When connectivity returns — at an authority field device, the aircraft, or the operator’s ground system — pending records are uploaded and reconciled into the ATOMx audit ledger.

    sequenceDiagram
    autonumber
    participant Drone as Aircraft
    participant FV as Authority Field Device
    participant Op as Operator Ground System
    participant ATOMx
    Drone->>Op: Signed flight log + capsule receipts (USB / Wi-Fi / cellular)
    Op->>ATOMx: Forward flight log
    FV->>ATOMx: Disclosure receipts (when reconnected)
    ATOMx->>ATOMx: Verify signatures + check duplicates / replay
    ATOMx->>ATOMx: Match disclosure events to authorization
    ATOMx->>ATOMx: Compare reported telemetry vs corroborating sources
    ATOMx->>ATOMx: Cross-check time anchors for tampering
    ATOMx->>ATOMx: Flag anomalies (replay, geo-mismatch, time-tampering, broken seal, break-glass)
    ATOMx-->>Op: Reconciled receipt + any flags
    ATOMx-->>FV: Reconciled receipt + any flags
  

ATOMx specifically looks for:

• Replay: a capsule used outside its validity window or after its expected single-flight scope
• Duplicate token: the same Public Token observed by two authority devices with non-overlapping geometries
• Broken seal: signatures that fail to validate post-hoc due to revoked certs or tampered logs
• Geo-mismatch: aircraft telemetry from the flight log diverging from corroborating sensor data
• Time tampering: aircraft- or device-reported times inconsistent with monotonic counters, GNSS history, or corroborating sources (see §5.4)
• Break-glass clusters: spikes in break-glass disclosures suggesting credential abuse

Anomalies feed the Security Alert dimension defined in Trust Model §4. Anomalies do not automatically degrade Identity Trust for the aircraft; a cooperative aircraft whose flight log surfaced a field-side anomaly is not retroactively untrusted.

8. Open Engineering Questions

9. Summary

Disconnected operation in ATOMx is enabled by four layered investments:

1. An organization-typed identity model rooted in ATOMx IAM, so that every actor — manufacturer, operator, pilot, authority — has a clear regulatory and operational role and a corresponding certificate chain.
2. A trust hierarchy under a single offline-resolvable Root, so any aircraft, capsule, or credential can be validated end to end with no network access beyond what is embedded in the verifier’s device.
3. Hardware-bound aircraft identity issued by manufacturers at the factory, so every airframe in flight can prove what it is without contacting ATOMx.
4. The Offline Capsule as the unit of pre-cleared authorization, issued online but designed for offline use, distributed to the aircraft before flight and to authority devices in advance, with sideband retrieval as a fallback. Time tampering is treated as a first-class threat with monotonic counters in hardware on both ends.

The result: an authority field user in an austere environment can see a drone overhead, point a managed device at it, and within seconds know whether the operation is approved, who is responsible, where the control station is, and whether anything anomalous is happening — all without either the drone or the device having an internet connection. The audit record catches up later, with the same accountability properties as a fully connected flight.

Implementation Readiness — Open Questions

Each entry below identifies a decision not yet locked. Items marked (ADR) should be formalized as an Architecture Decision Record before implementation begins. Items marked (blocking) must be resolved before the relevant feature can be built.

Broadcast/RF/messaging-layer questions (Auth Type code registration, cadence, channel selection, sideband protocol, multi-aircraft RF, mesh peer-share, deferred-verification UI, mid-flight amendment ACK) moved with the §5 content to Local Broadcast and Messaging §10. The entries below cover the trust / capsule / verification side that stays on this page.