Onboarding Manufacturers

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

1. Why Manufacturer Onboarding Exists

Aircraft identity in ATOMx is rooted in the OEM. An aircraft proves who it is by presenting a certificate signed by the manufacturer’s intermediate CA, which itself chains to the ATOMx Root. If any OEM could obtain that intermediate CA without diligence, every aircraft they minted would become a trust anchor for the platform. Onboarding gates the issuance of that intermediate CA.

2. The Five Onboarding Gates

3. Key Ceremony Sequence

    sequenceDiagram
    autonumber
    participant OEM
    participant ATOMx
    participant HSMa as ATOMx Root HSM
    participant HSMo as OEM HSM
    OEM->>ATOMx: Apply for manufacturer credential
    ATOMx->>OEM: Eligibility + conformance review
    OEM->>HSMo: Generate OEM intermediate keypair
    HSMo-->>OEM: CSR
    OEM->>ATOMx: Submit CSR + attestation
    ATOMx->>HSMa: Sign OEM Intermediate CA cert under Root
    HSMa-->>ATOMx: Signed cert
    ATOMx-->>OEM: Issue OEM Intermediate CA cert + SDK
    Note over OEM,ATOMx: OEM may now mint per-aircraft certs at the factory
  

4. The Two Independent Chains

Once onboarded, the OEM operates one of two cert chains for every aircraft it ships. The other (TPM chip provenance) is operated by the TPM chip manufacturer, independently. Both chains must be present and cross-referenced for an aircraft to verify. See Aircraft Hardware Identity §2.

5. Specifications, Compliance, and Commercial Terms

5.1 HSM Requirements

5.2 Compliance Posture

5.3 Commercial and Contractual Terms

ATOMx does not publish standard pricing here — those terms are negotiated per OEM. Onboarding contracts cover:

• Per-OEM onboarding fee plus annual maintenance
• HSM cost borne by the OEM (ATOMx does not host the OEM intermediate)
• SDK license terms and update cadence
• Liability allocation for fraudulent or non-conforming aircraft minted under the OEM CA
• Indemnity limits and incident-response commitments
• Data-handling terms for batch attestation records

6. Ongoing Obligations

After onboarding, the OEM:

• Submits signed batch attestations for each manufacturing run
• Maintains a CRL for its issued aircraft certificates (or migrates to short-lived certs renewed at routine check-in)
• Participates in scheduled Manufacturer CA rotations (target: 5-year rotation with overlapping validity)
• Reports security events affecting its assembly line, firmware, or HSM

7. Incident Response and De-Listing

7.1 OEM Security Incident

If an OEM detects a security incident affecting its signing infrastructure, manufacturing line, or firmware integrity, it must notify ATOMx within a contractually-defined window (typically 24 hours). ATOMx may:

• Pause new aircraft minting under that OEM until investigation completes
• Trigger emergency rotation of the OEM Intermediate CA
• Issue a CRL update covering affected aircraft serials
• Coordinate with operators flying affected airframes

7.2 De-Listing

An OEM may be de-listed for cause — repeated batch-attestation discrepancies, failure to remediate a security event, loss of regulatory standing, NDAA violation, or other contractually-defined trigger. De-listing has cascading effects:

De-listing is rare; the procedural process targets months, not days, to allow operators to migrate.

7.3 Mergers, Acquisitions, and Divestitures

OEM corporate change events do not automatically transfer the Manufacturer Intermediate CA. The acquiring entity must complete a streamlined re-eligibility review and either:

• Continue operating the existing OEM Intermediate CA under the same identity and key material (preferred)
• Replace it with a new Intermediate CA under the new entity’s identity, with a defined cross-signing window for in-field aircraft

Divestitures (one OEM splits into two) require a separate Manufacturer Intermediate CA per resulting entity, with clear ownership of the original aircraft fleet.

8. Cross-References

• The aircraft-side event that produces a per-airframe identity: Onboarding Aircraft
• The cert chain anchored at the Root CA: PKI and Chains of Trust §5
• The full disconnected-ops trust hierarchy this fits into: Disconnected Operations §2.2

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.