What a Fieldbus Device Must Protect Over Its Life
Security on a fieldbus device is not a single feature but a set of obligations that shift as the device ages. At manufacture it must protect its firmware and its first credentials; at handover it must prove its identity and accept a new owner; in operation it must guard both software updates and configuration; at end of life it must destroy its keys. This page organizes those obligations by lifecycle stage and shows which key answers each one, so the design follows the device rather than a single moment in it.
Manufacture: Protect Firmware and First Credentials
A device is born with keys, not blank. At build the manufacturer loads a firmware update key, used to encrypt and authenticate every firmware image, so that firmware confidentiality and integrity hold from the very first power-up. Alongside it goes a one-time provisioning key, the credential that lets the first owner claim the device, often printed as a label on the unit. Where the design calls for asymmetric identity, the device also generates an Ed25519 key pair on-chip, keeping the private half forever and exporting only the public half for certification.
The division of control set here lasts for the life of the product. The manufacturer holds the firmware signing or update key and therefore stays in control of the firmware file, and nothing else. The device leaves the factory locked, carrying only public anchors and its own secrets. Everything operational is installed later, by the owner, which is what keeps the manufacturer out of the day-to-day key business.
Handover: Prove Identity and Accept an Owner
The first transfer turns a generic unit into one that belongs to a specific integrator. The device proves it is genuine, and the integrator claims it using the one-time provisioning key. That first activation is decisive: whoever performs it takes possession, must immediately assign new per-device symmetric keys, and from then on holds full responsibility for the device. The newly assigned key, not the factory provisioning key, secures device identity, integrator authorization, and the update session from that point forward. The mechanics of claiming, the choice between trust on first use, a token, or a voucher, and the later transfer of a whole system to an operator are covered on the Handover page.
Operation: Secure the Software Update
Through its working life the device accepts firmware updates, and four things have to hold for each one to be safe. Each maps to a key.
Device Identity
The updater must know it is really talking to that device, not a substitute or an emulator. The device proves itself with a challenge-response using a key only it and the authorized party share: the assigned per-device key, or an Ed25519 identity key.
File Authenticity and Anti-Rollback
The image must be genuine, untampered, intended for this device or class, and not an older version rolled back to reintroduce a fixed flaw. AES-128-GCM under the firmware update key gives integrity and authenticity, and confidentiality where the image is encrypted; a monotonic version check blocks rollback.
Integrator Authorization
Authenticity of the file is not the same as permission to install it. The bootloader accepts an update only from a party that proves it is allowed to update this particular device, using the assigned per-device key. A genuine image presented by an unauthorized party is still refused.
Update Session
Transfer and activation must be replay-protected and fail-safe. The session is bound so captured traffic cannot be replayed to force a re-flash, the device re-verifies the complete image before committing, and a failure partway through leaves the device recoverable rather than bricked.
The bootloader that enforces this on the device is covered in depth under Secure Bootloader.
Operation: Protect Configuration
Configuration deserves the same care as firmware, because a malicious configuration change can be as damaging as malicious code. A remapped object, a widened limit, or a disabled check can defeat a perfectly secure firmware image. There are three clean ways to protect it, and a real system often uses more than one.
Load the Whole Configuration as a File
Treat the entire configuration as a single signed and authenticated object and load it exactly like a firmware image. It inherits the same guarantees as a software update, including authenticity, integrity, and anti-rollback, and it is protected under the same firmware or update key.
Manual Configuration, Then Lock
Where settings are entered by hand on the bench, commit them and then lock the configuration cryptographically, so it cannot be altered without the proper key. The device moves from an open, writable state to a sealed one, and the seal is what an audit can later check.
Authenticated Per-Object Writes
Where individual settings must change in the field, each write is authenticated and gated by the operational key, so only an authorized party can change a permitted object. This is the model behind Secure Object Fieldbus Access.
Whichever method is used, two properties matter across the lifecycle. The device should verify its configuration at boot, so a tampered configuration is detected before it takes effect, and it should refuse an older configuration that would reopen a closed gap, the configuration equivalent of firmware anti-rollback. A configuration that the device cannot verify is a configuration an attacker can quietly rewrite.
End of Life: Destroy the Keys
The lifecycle closes where it is most often forgotten. When a device is reset, decommissioned, resold, or returned, its secret key material must be zeroized, that is, purged so it cannot be recovered from released storage. IEC 62443-4-2 CR 4.2 requires exactly this. The practical reason is ownership: a device that returns to an unowned state must not carry the previous owner's keys, or a later re-claim would inherit stale trust and a returned unit would leak the secrets of the fleet it came from. Designing the erase path at the start is far easier than retrofitting it when an audit asks where the old keys went. CR 4.2
The Symmetric Baseline in Practice
Put end to end, the common practice keeps the device side small. The device needs only authenticated encryption with AES-128-GCM, and it holds at least two keys for most of its life: the firmware update key loaded at manufacture, and the operational key assigned at handover that secures identity, authorization, sessions, and locked configuration. That is enough to meet the obligations at every stage above without an on-device certificate authority.
The reason this baseline is symmetric is cost, not security. An Ed25519 signature or verification runs on the order of 1 million cycles and needs SHA-512 in addition to the SHA-256 a device already carries, while AES-128-GCM runs in a few thousand cycles in software and tens of cycles with the hardware AES common on CAN-class controllers. The asymmetric route costs roughly 100 to 1000 times the cycles for the same job, which is why most CAN and CAN FD devices stay symmetric. We recommend reserving public-key methods for where your system genuinely needs open distribution or delegation. The Symmetric vs Asymmetric page weighs that choice, and Symmetric Key Management covers how the operational keys are diversified, rotated, and revoked.
Frequently Asked Questions
What keys does a device receive at manufacture, and what does it keep for life?
At build the device receives a firmware update key, loaded by the manufacturer to encrypt and authenticate firmware images, and a one-time provisioning key used for handover. After the first owner claims the device, they assign new per-device keys that secure identity, authorization, and sessions from then on. The manufacturer keeps control only of the firmware update file; everything operational belongs to the owner.
How is configuration protected across the lifecycle?
Three ways, which can be combined. Load the whole configuration as a single signed and authenticated object, like a firmware image; enter it manually on the bench and then lock it cryptographically; or accept authenticated per-object writes gated by the operational key. In every case the device should verify its configuration on boot and refuse an older configuration that would reopen a closed gap, the configuration equivalent of firmware anti-rollback.
What has to happen to a device's keys at end of life?
They must be zeroized. IEC 62443-4-2 CR 4.2 requires that key material be purged so it cannot be recovered when a device is reset, decommissioned, resold, or returned. A device that goes back to an unowned state must not carry the previous owner's keys, which is what makes a later re-claim safe.