Onboarding Aircraft

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

1. Factory Provisioning (at the OEM line)

Every aircraft ships with a hardware secure element — a dedicated tamper-resistant chip that holds cryptographic keys and performs signing on-chip. At the manufacturing line, the secure element:

• Generates its own keypair on first boot; the private key never leaves the chip
• Receives the ATOMx Root public key as an immutable trust anchor
• Receives its identity certificate signed by the manufacturer’s intermediate CA
• Has its TPM NV storage locked (EK Cert under WRITE_ONCE, Drone Assembly Cert under WRITE_LOCKED)

    sequenceDiagram
    autonumber
    participant SE as Aircraft Secure Element
    participant Line as OEM Manufacturing Line
    participant HSMo as OEM HSM
    participant ATOMx
    Line->>SE: Power on, initiate provisioning
    SE->>SE: Generate keypair on-chip
    SE->>Line: CSR (public key + airframe serial + hardware attestation)
    Line->>HSMo: Forward CSR
    HSMo->>HSMo: Sign with Manufacturer Intermediate CA
    HSMo-->>Line: Aircraft Identity Certificate
    Line->>SE: Install certificate + ATOMx Root public key + lock NV storage
    Line->>ATOMx: Signed batch attestation (serials, firmware, attestation hashes)
    ATOMx-->>Line: Registry entry: "manufactured, unassigned"
  

After provisioning, the aircraft’s lifecycle state in ATOMx is Manufactured, unassigned. It cannot fly yet — it has not been bound to an operator, and the platform has not performed its own attestation challenge.

2. Platform Onboarding (first connection)

The first time the aircraft connects to the platform — typically through the operator’s mobile app via the OEM controller (see Disconnected Operations §3.1) — the platform runs the TPM attestation challenge. This is documented in full in Flight Lifecycle §1. In summary:

1. Platform sends a nonce challenge.
2. Drone TPM responds with EK Certificate, AK Certificate request, and PCR Quote.
3. Platform verifies EK chain to TPM manufacturer Root, issues AK Certificate.
4. Drone presents Drone Assembly Certificate; platform verifies chain to OEM Root and the EK cross-reference.
5. Platform records the security posture as the ground-truth registration record.

The result is the JSON registration record in Flight Lifecycle §1.3. This record is the ground truth against which all future authorization requests for this aircraft are evaluated. It is cryptographically established at onboarding, not self-reported by the pilot.

3. Aircraft Lifecycle States

    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
  

4. Registration to an Operator

When an operator acquires the aircraft, they submit proof of ownership (or an OEM-signed transfer record) to ATOMx. ATOMx records a signed binding from the airframe serial to the operator’s org cert. State advances to Registered. This is also when the platform-side attestation challenge typically runs, if it has not already.

5. Pilot Assignment

A pilot under the operator’s org may be granted operating rights to specific airframes. The binding is recorded server-side; the aircraft itself does not need to know which pilot will fly it next, only that an Authorization Package presented at flight time is signed for an enrolled pilot under its bound operator.

6. Re-Attestation and Lifecycle Events

6.1 Re-Attestation Cadence

The TPM attestation challenge in §2 is not a one-shot event. ATOMx requires re-attestation:

An aircraft that has not completed a routine check-in within the configured window cannot enter Connected-Ready state and therefore cannot receive new Authorization Packages.

6.2 Re-Onboarding Triggers

Full re-onboarding (Phase 0 from scratch) is required when:

• TPM hardware is replaced (rare; see Aircraft Hardware Identity §9.4)
• Mainboard is replaced (most RMA cases)
• Whole airframe is replaced
• Cryptographic chain validation fails irrecoverably (tamper response triggered, secure-element fault)
• Aircraft is transferred between operator orgs across a registry boundary that requires fresh attestation

6.3 Loss, Theft, Decommissioning

6.4 Fleet Onboarding (Bulk Path)

For operators bringing tens or hundreds of aircraft online at once, ATOMx supports a bulk onboarding API that accepts a signed batch manifest from the operator referencing pre-validated aircraft serials and their corresponding OEM batch-attestation records. Each aircraft still completes its own TPM attestation challenge on first connection, but operator-side workflow (operator binding, pilot pre-assignment, default policy) is applied in one pass.

Bulk onboarding does not skip the per-aircraft cryptographic ceremony; it streamlines the operator-side ledger entries that surround it.

6.5 Transfer Between Operators

A transfer between operators is not a simple ownership rebinding — it produces an audit-significant event:

1. Selling operator submits transfer record signed by an authorized operator user
2. Buying operator countersigns
3. ATOMx records the transfer; aircraft state moves to Manufactured, unassigned if a fresh attestation is required, or directly to Registered under the new operator if the current attestation is fresh and the buying operator’s risk policy accepts a warm transfer
4. Pilot assignments under the previous operator are revoked
5. Outstanding authorizations are revoked or completed

Leasing is a special case of transfer with a defined return event; the lessor remains the regulatory owner of record.

7. The Fallback for BYOD or Non-TPM Aircraft

When an OEM lacks a TPM or the customer is bringing legacy hardware, ATOMx supports an encrypted-vault fallback: a non-root encrypted vault inside a read-only Docker container. The trust tier degrades from L5 (hardware-anchored) to L4 (software-anchored). Liability for key protection shifts to the customer. See Origins and Decisions §3.13.

8. Cross-References

• The OEM event that issues the aircraft certificate: Onboarding Manufacturers
• The hardware substrate that makes attestation possible: Aircraft Hardware Identity
• The runtime cryptographic mechanics of Phase 0: Flight Lifecycle §1
• The full lifecycle as seen from the disconnected-ops view: Disconnected Operations §3

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.