PQ-TLS Device Provisioning

The first connection a device makes often defines the trust anchors for everything that follows. If enrollment is weak, every later control inherits that weakness. A compromised provisioning channel can inject rogue trust roots that persist across the device's entire operational lifetime.

Provisioning design therefore needs to connect cryptographic identity, release provenance, and tenant assignment from the first trusted interaction. NIST SP 800-207 emphasizes that trust must be established per-session and per-resource; this principle applies with particular force at the initial enrollment boundary, where the device transitions from an unknown entity to a managed fleet member.

The IETF hybrid TLS key exchange drafts (draft-ietf-tls-hybrid-design) define a mechanism for combining classical and post-quantum key establishment in a single TLS handshake. This hybrid approach ensures that the bootstrap channel is resistant to harvest-now-decrypt-later attacks while remaining interoperable with infrastructure that has not yet completed a full post-quantum migration.

A practical PQ-TLS bootstrap model treats the device as an identity-bearing endpoint before it becomes a fully enrolled fleet member. The device presents its identity material during the initial handshake, and the platform validates that identity against a pre-registered claim or an operator approval queue before granting enrollment.

The bootstrap handshake should establish a quantum-resistant channel for all subsequent enrollment traffic, including tenant assignment, policy delivery, and initial image validation. NSA CNSA 2.0 timelines reinforce the urgency: devices provisioned today may still be operational when cryptographically relevant quantum computers arrive.

• Hybrid key exchange combines a classical algorithm (e.g., X25519) with a post-quantum KEM (e.g., ML-KEM-768) so the channel remains secure even if one primitive is broken.
• The bootstrap channel should be distinct from the ongoing management channel to limit the exposure window of enrollment credentials.
• Server and device authentication during bootstrap should both be quantum-resistant to prevent impersonation in either direction.

A device should possess a stable cryptographic identity before its first network contact with the enrollment service. This identity may originate from hardware-backed key storage, a factory-provisioned credential, or an operator-generated identity bundle loaded during imaging.

The critical principle is that the enrollment service should verify a pre-existing identity rather than create one on the fly. When identity is a side effect of the bootstrap handshake, there is no independent anchor against which to validate the device's provenance or detect impersonation attempts.

• Device identity should exist before the fleet dashboard sees the node.
• The identity credential should be bound to the device's hardware or image lineage, not to ephemeral network attributes.
• Identity material should be generated or injected in a controlled environment with auditable key-handling procedures.

Claiming is the act of associating a device identity with a specific tenant and deployment context. This step should be explicit, auditable, and separable from the transport handshake. A device that completes a TLS connection is not automatically enrolled. It has only established a secure channel over which a claiming request can be submitted.

Approval workflows may be real-time (an operator approves a pending claim immediately) or deferred (the device submits a claim and waits for approval on its next connection). Both paths must produce the same enrollment record with the same evidence: who approved, when, which device identity, and which tenant context.

Offline and delayed-approval workflows deserve particular attention. In air-gapped or intermittently connected environments, a device may complete its bootstrap handshake days or weeks before an operator can review and approve the claim. The system must handle this gracefully. The device should operate in a safe, limited state until approval arrives, without requiring a second bootstrap sequence.

• Claiming and approval must be auditable after the fact, with durable records linking the device, the approver, and the tenant.
• Deferred approval should not require the device to repeat the identity-establishment step.
• Pre-approved claiming (where the operator registers expected device identities before the device connects) reduces the approval window and simplifies air-gapped onboarding.

Keep the enrollment API surface small, explicit, and purpose-built. A narrow bootstrap API is easier to audit, easier to secure, and harder to misuse than a general-purpose management API repurposed for enrollment. The bootstrap endpoint should accept identity presentation, issue claiming requests, and return enrollment status, nothing more.

For integrators, the priority is traceability and repeatability, not just handshake success. Every enrollment event should produce evidence that can be correlated with device inventory, tenant records, and release-channel state. If the enrollment path cannot answer who approved this device, when, and into which tenant, the provisioning model has a gap that will surface during audit.

Resist the temptation to make the bootstrap API flexible enough to handle every edge case. Special cases are better handled through separate, well-documented workflows (e.g., re-enrollment after device wipe, identity rotation) rather than overloading the primary bootstrap path with conditional logic.