Asymmetric Key Management
Asymmetric key management is what most people picture when they hear public-key infrastructure: a certificate authority, device certificates, and a chain of trust. That full arrangement is powerful and well documented, but it is also a standing organizational commitment. This page outlines what a full PKI involves and where to read the detail, then describes a minimal version that a smaller manufacturer or integrator can run without a dedicated certificate team.
What a Full PKI Involves
A full public-key infrastructure separates a rarely-used root from the keys that do the daily work, so that a compromise of a working key does not compromise the root. The structure is layered, and each layer has a clear job.
Offline Root
A root key kept offline and used only at infrequent ceremonies to sign the production keys below it. Its private half lives in a hardware security module, backed up under wrapping. A root compromise enables counterfeit signing, so it is protected accordingly; root loss does not brick deployed devices, since a new root can serve future production.
Production Signing Keys
Warmer keys, also in a hardware security module, that sign at volume: one to sign each firmware release, one to sign per-device identity certificates. The root signs the public halves of these once, then returns to the safe. All high-volume signing uses these production keys.
Per-Device Identity
Each device receives an asymmetric identity key, generated on-chip so the private half never leaves, or injected from the production module. A certificate signed by the identity signing key binds the device public key to its serial and product line.
Public Registry
A low-sensitivity record of public material: the root public key, the production certificates, and per-device serial, line, firmware version, and identity certificate. It never holds private keys, so it does not need the protection that the signing keys do.
The mechanics here are industry-standard and documented. NIST SP 800-57 covers the key-management lifecycle of establishment, rotation, and destruction. FIPS 140-2 and ISO/IEC 19790 set the requirements for the hardware security modules that hold private keys. IEEE 802.1AR describes one well-known form of device identity certificate, and the Software Updates for Internet of Things (SUIT) specifications, RFC 9019 and RFC 9124, describe a firmware-manifest architecture often paired with signed updates. Certificates can be encoded as X.509 or in more compact forms suited to constrained devices. The point for a newcomer is that this is a real, ongoing operation: ceremonies, module custody, registry maintenance, and revocation handling all become standing responsibilities. NIST SP 800-57 FIPS 140-2 ISO/IEC 19790 IEEE 802.1AR SUIT
A Minimal PKI a Small Manufacturer or Integrator Can Run
Most of the benefit of public-key trust is available without standing up a full certificate authority. Two roles tend to ask whether they can run a smaller version: a small manufacturer, often fewer than ten people with no dedicated IT infrastructure, that still has to sign its own firmware, and a small integrator that owns a closed deployment. Both can, and the shape is the same in each case: one carefully kept root, a short record of what it signed, and revocation by signed statement rather than by re-keying devices.
The Small Manufacturer Case
A manufacturer of fewer than ten people does not need a certificate-authority team and should not pretend to run one. The work reduces to protecting one private key well and keeping a list. Generate a single root key pair, where Ed25519 is a sound default, on an air-gapped machine or a hardware token, and keep it offline. Use it to sign the firmware signing key that the build process uses from day to day, and, where devices carry asymmetric identity at all, the key that signs device certificates. The public half of that root becomes the anchor placed in every device at manufacture.
Everything else is bookkeeping rather than infrastructure. The record of which firmware version and which anchor went to which serial can live in an ordinary database, because it holds only public material. The discipline that matters is custody of the one offline root: who holds the token, where the backup lives, and what happens if the person who set it up leaves. At this scale per-device asymmetric identity is often not worth it. Many small manufacturers stay with per-device symmetric keys for identity and use the minimal root only to sign firmware, which keeps the device side to AES-128-GCM and the office side to one key and a list.
The Small Integrator Case
A small integrator that owns a closed deployment runs the same idea from the other end. The arrangement keeps a single asymmetric root, held by the integrator, that governs the per-device operational keys rather than issuing a certificate for every device. The device holds only the integrator public anchor, and the per-device operational key is generated by the device and never leaves it, so the integrator database holds public material and references, never secrets.
Authority is granted and revoked by signing short records against the root. To withdraw a credential, the integrator signs a new record that marks the old one revoked, and tools and devices that hold the anchor refuse it from then on. This delivers the properties that make asymmetric trust attractive, a leak-tolerant database and revocation without re-keying every device, while the day-to-day cost stays close to that of a symmetric system.
The trade is honest, and it is the same for both roles. A minimal PKI gives up the deep, certificate-per-device identity that anti-counterfeiting and very large multi-party programs rely on. For a small manufacturer signing its own firmware, or a single integrator running a closed deployment, in our experience it is usually the right amount of infrastructure. Where this asymmetric governance layer sits on top of symmetric per-device keys, the result is a hybrid covered on the Symmetric Key Management page. If even the minimal root feels like more than you need, staying fully symmetric remains the lowest-burden option, a firmware update key plus a provisioning key, as described under Fieldbus Device.
Frequently Asked Questions
What does a full public-key infrastructure for devices involve?
An offline root key used only at infrequent signing ceremonies, warmer production keys that sign firmware and per-device identity certificates at volume, a per-device identity key issued at manufacture, and a public registry that records which key and certificate went to which unit. Private key material lives in hardware security modules. Guidance for the lifecycle comes from NIST SP 800-57, and module security from FIPS 140-2 or ISO/IEC 19790.
Can a small manufacturer or integrator run a minimal PKI?
Yes, and it applies to both: a small manufacturer signing its own firmware, and a small integrator running a closed deployment. The minimal arrangement keeps one carefully protected root, offline on a token or air-gapped machine, that signs firmware and, where used, device anchors. The device holds only public material, the registry of what went where can be an ordinary database, and authority is revoked by signing a short record rather than re-keying devices. A team of fewer than ten people can run this; the discipline it demands is key custody, not IT scale.