Handover Across the Supply Chain
A device is rarely used by the company that built it. A manufacturer hands it to an integrator, who builds it into a system and later passes that system to an operator. Each transfer is a point where trust has to be established, keys have to move, and authority has to be scoped. This page describes the security steps and the realistic options at each handover, at a level that helps you plan the process rather than implement a specific product.
Manufacturer to Integrator
The first handover turns a generic, factory-fresh unit into a device that belongs to a specific integrator and carries that integrator's operational keys. The steps below are sequential, and the early ones can be skipped on minimal devices that do not carry an identity.
1. Verify Genuineness
Before trusting a unit, the integrator confirms it is a genuine device of the expected type and serial. Where the device carries a manufacturer-issued identity, the integrator tool validates it against the manufacturer's public anchor. On minimal devices without an identity, this step is replaced by physical provenance and supply-chain controls.
2. Claim Ownership
The integrator installs its own trust material and locks the device to itself. The device gates this by a method chosen at production: trust on first use, a provisioning token printed for the unit, or a manufacturer-signed voucher. Each trades friction against assurance. The claim holds until the device is decommissioned.
3. Update Firmware
The integrator brings the unit to the current manufacturer release. The device verifies the manufacturer signature or authentication tag and applies anti-rollback. Because the firmware protects itself, no integrator key is required for this step; it relies only on the manufacturer's verification anchor or Update Key.
4. Provision Operational Keys
The heavy step: the integrator establishes the per-device operational keys the system will use. These can be delivered over an authenticated channel set up with the device's identity, or injected locally on a trusted bench. After this, routine traffic is symmetric and lightweight.
Two further steps close out the handover. The integrator configures the device into the system, assigning its address and pushing any configuration, optionally signed so the device can verify its authority. Finally the integrator records the unit in its own database: which node sits where, its serial and firmware version, and the key material or derivation parameters appropriate to the chosen approach. That record is what makes later refresh, revocation, and audit possible.
Two Ways to Root the Trust
Behind these steps sits a single architectural choice: who installs the roots of trust, and when. The two ends of the spectrum are worth understanding before you pick a product or a process.
Manufacturer-Rooted
The device is born locked and already carrying identity and anchors installed at production. The integrator claims an already-trustworthy device and layers its keys on top. There is no window where the device is open and unprovisioned. This fits broad markets, multiple integrators, and anti-counterfeiting needs.
Integrator-Rooted
The device is born open, and the integrator installs all roots at first commissioning, then locks it. The manufacturer keeps only firmware-update authority. This is simpler for the manufacturer but creates a window, from factory to integrator lock, that must be closed by physical and supply-chain security. It fits a single integrator owning a closed deployment.
Integrator to Operator
The second handover is usually a delivery model rather than a transfer of ownership. The integrator keeps the roots and installs a scoped operator credential on the device. The credential is deliberately limited: it may let the operator trigger manufacturer-signed firmware updates and write permitted configuration, while it may not change keys, transfer ownership, alter anchors, or install operator-authored firmware or configuration. The device enforces this scope per action, so an operator can keep the system running without ever gaining the authority to re-key or re-own it. Firmware authenticity remains rooted in the manufacturer throughout; the operator only delivers signed images, it does not sign them.
The mechanics of provisioning, scoping, and later revoking these credentials are covered on the two management pages. For symmetric deployments, see Symmetric Key Management; where an asymmetric governance layer is used to grant and revoke operator authority without re-keying devices, see Asymmetric Key Management.
Frequently Asked Questions
What does it mean to claim ownership of a device at handover?
Claiming ownership is the step where an integrator installs its own trust material onto a device and locks the device to that owner until it is decommissioned. The device gates this step by a method chosen at production: trust on first use, a provisioning token printed for the unit, or a manufacturer-signed voucher. After a successful claim the device accepts operational keys only from its new owner.
How is authority limited when a system is handed to an operator?
The integrator installs a scoped operator credential. It may permit the operator to trigger manufacturer-signed firmware updates and to write permitted configuration, while denying key changes, ownership transfer, anchor changes, and operator-authored firmware. The device enforces the scope per action, so the operator can run the system without gaining the authority to re-key or re-own it.