Flight Lifecycle: Onboarding to Reconciliation

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

1. Phase 0 — Drone Onboarding

Before a drone can be used in the platform, it must be onboarded. Onboarding establishes the drone’s hardware identity and security posture in the platform’s registry. This is a one-time event per airframe.

For background on the two independent certificate chains (TPM chip provenance and Drone OEM provenance), TPM NV storage, and PCR attestation, see Aircraft Hardware Identity.

Step 1 — TPM attestation challenge

The platform sends a nonce challenge to the drone. The drone’s TPM responds with:

The platform verifies the EK chain against the TPM manufacturer’s public root CA, then issues an AK Certificate confirming the signing key is hardware-bound.

Step 2 — Drone Assembly Certificate verification

The drone presents its Drone Assembly Certificate from TPM NV storage. The platform verifies it chains to the Drone OEM Root CA and that the EK public key inside it matches the EK presented in Step 1. This is the cross-reference that binds drone body to TPM chip — see Aircraft Hardware Identity §2.

Step 3 — Platform registration

The platform records the drone’s security posture:

{
  "drone_serial":     "DRN-00492",
  "assembly_cert":    "<fingerprint>",
  "tpm_manufacturer": "Infineon",
  "tpm_model":        "SLB9670",
  "ek_verified":      true,
  "pcr_baseline":     { "PCR[0]": "a3f9...", "PCR[4]": "7c1d...", "PCR[7]": "..." },
  "secure_boot":      true,
  "attested_at":      "2025-01-15T09:00Z",
  "key_storage":      "hardware-tpm"
}

This record is the ground truth against which all future authorization requests for this drone are evaluated. It is cryptographically established at onboarding — not self-reported by the pilot.

    sequenceDiagram
    autonumber
    participant Drone
    participant Platform
    Drone->>Platform: Onboarding request
    Platform-->>Drone: Nonce challenge
    Drone->>Drone: TPM produces EK cert + AK request + PCR Quote
    Drone-->>Platform: EK cert · AK request · PCR Quote
    Platform->>Platform: Verify EK chain to TPM manufacturer Root
    Platform-->>Drone: AK Certificate
    Drone-->>Platform: Drone Assembly Certificate (from NV storage)
    Platform->>Platform: Verify chain to OEM Root + EK match
    Platform->>Platform: Record posture (drone_serial, PCR baseline, ...)
    Platform-->>Drone: Onboarded
  

2. Pre-Flight Authorization

The pilot submits flight intent: identity, drone, location, time window, and purpose. The platform validates the drone serial number exists in the registry with a current valid attestation.

Multi-authority endorsement

The platform calculates which authorities must endorse the flight — based on airspace jurisdiction, operational competence, or both — and dispatches the authorization request to all of them simultaneously. First to respond is the first endorser. The flight may not commence until all required endorsements are collected.

The endorsement model and signature structure are documented in Authorization Package §3.

Pilot identity at authorization time

FTN alone is insufficient. It is verified server-side against the FAA IACRA API but does not cryptographically prove the person holding the certificate is present. It must be paired with login.gov identity proofing. Scanning a paper certificate is not acceptable.

For the full pilot identity model, see Pilot Identity.

Issuance

The platform assembles the base token and all endorsements into a composite Authorization Token, seals it with its own signature, and emits the structured Authorization Object onto the event stream. See Authorization Package §4.

3. In-Flight Telemetry Binding

Channel. Phase 2 telemetry is sent over a private mTLS channel from the drone (or its operator app) to ATOMx — not broadcast. The public-facing surface is the Remote ID Authentication Message described in Disconnected Operations §5.3, which carries the rotating Public Aircraft Token, not the internal package_id. Broadcasting package_id would defeat the unlinkability the Public Aircraft Token exists to provide.

The drone signs each telemetry packet with its hardware-bound private key:

Telemetry Packet {
  package_id:    "auth-943da899"          ← internal authorization identifier (mTLS-only, never broadcast)
  seq:           1042                     ← strictly incrementing
  timestamp:     2026-06-01T14:23:17.412Z
  position:      { lat, lon, alt, vel }
  signature:     <drone hardware key over all of the above>
}

What if the telemetry stream stalls?

A gap in telemetry does not drop the trust level — the Authorization Package and credentials remain valid. ATOMx tracks a per-package telemetry-confidence score (see system-design §1.7) that degrades after a configurable grace window. After the window, the authorized operational state shows “telemetry stale” and the conformance engine pauses evaluation rather than emitting false-positive deviations. Operator policy decides whether stalled telemetry triggers an automatic abort, return-to-launch, or only an alert.

4. Attack Vectors and Mitigations

Assuming firmware integrity and hardware key extraction are mitigated by TPM attestation and secure boot:

GPS spoofing is the residual risk that cryptography alone cannot solve. A drone with a hardware-bound key and attested firmware will honestly sign whatever its GPS sensor reports. Full mitigation requires independent position corroboration — cellular triangulation, ground radar, or ADS-B — which is an infrastructure problem, not a cryptography problem.

For the full threat model spanning identity, replay, disclosure, and operational threats, see Threat Model.

5. Relationship to Remote ID

Remote ID and the telemetry stream are separate channels serving different purposes:

They are complementary. The drone serial number in the Remote ID broadcast must match the drone identity in the authorization token. When ATOMx Authentication-Message attestations are emitted (see Disconnected Operations §5.1), the Public Aircraft Token in the broadcast resolves through the capsule to the same drone serial recorded in the registry.

6. Mid-Flight Events

In-flight authorization is not static. Several event classes can change the operational picture during a flight; each has a defined handling path.

6.1 Mid-Flight Amendment

Pop-up TFRs, sub-zone activations, dynamic restrictions, and authority instructions can amend a live authorization. The flow:

1. ATOMx (or the issuing authority) creates an amendment: same package_id, new package_version (see Authorization Package §8.3).
2. ATOMx sends a machine-readable compliance instruction to the operator/control system: exit, hold, land, reroute, or refile.
3. Where possible, ATOMx provides a pre-deconflicted route out of the affected area.
4. Operator/control system accepts, modifies, or executes the response.
5. Aircraft receives the new package_version either through its operator app or directly if it has its own connectivity.
6. The Conformance Engine begins evaluating against the new approved operation immediately on the operator side; it begins evaluating against it on the aircraft side once the new version has propagated.
7. Cooperative compliance does not downgrade identity trust. Non-compliance becomes an authorized-user investigation cue.

For flights underway in disconnected mode, amendment delivery is best-effort over whatever sideband channel is available; if the aircraft cannot be reached, ATOMx records the amendment as issued-but-not-acknowledged and the conformance engine flags any divergence post-flight.

6.2 Pilot Handoff

For long-duration flights or shift changes, one pilot may hand off RPIC responsibility to another. ATOMx supports this as a signed event:

• Both pilots are affiliated with the operator; both have valid Pilot Certificates
• Outgoing pilot signs a handoff record naming the incoming pilot
• Incoming pilot countersigns
• ATOMx amends the package to reflect the new pilot_identity_ref; package_version increments
• Audit ledger records the handoff event with timestamp, position, and aircraft state

Handoff is denied if the incoming pilot is not affiliated with the operator, lacks current credentials, or holds an active suspension.

6.3 Multi-Aircraft and Swarm Operations

Swarm operations are modeled as a single Authorization Package referencing multiple aircraft, with one designated RPIC and one approved operating volume that contains the swarm geometry. Each aircraft signs its own telemetry and broadcasts its own Public Aircraft Token. The conformance engine evaluates the swarm against the aggregate approved operation, not each aircraft individually.

For a true Part 108 BVLOS swarm, the architecture admits operator-system identity as a peer of pilot identity (see Onboarding Operators and Pilots §5.2). The cryptographic substrate is in place; the regulatory path is forthcoming.

7. Revocation and Avatar Destruction

For connected operations, ATOMx uses an elegant revocation primitive: device-pair certificates issued per aircraft connection. To revoke, delete the server-side cert from inventory; the avatar pod dies; the client cert becomes useless. No CRL distribution, no rotation list. Combined with short-lived MTLS sessions issued via CSR, this collapses the revocation problem for connected operations. See Origins and Decisions §3.12.

Disconnected operations carry CRL snapshots inside each Offline Capsule — see Disconnected Operations §4.3.

8. Reconciliation

When connectivity returns at the aircraft, the operator’s ground system, or an authority field device, pending records are uploaded and reconciled into the ATOMx audit ledger. ATOMx specifically looks for replay, duplicate token use, broken seal, geo-mismatch, time tampering, and break-glass clusters. The full reconciliation flow is documented in Disconnected Operations §7.

9. Cross-References

• The objects and signatures involved: Authorization Package
• Where the hardware identity comes from: Aircraft Hardware Identity
• Where the pilot identity comes from: Pilot Identity
• The disconnected variant of this flow: Local Broadcast & Messaging

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.