What "signed update" really means
Part of a series: the three practices the CRA quietly expects and secure boot is not one feature, it's a chain came before this one.
Secure boot answers one question: what is allowed to run on this device. It says nothing about the other question that dominates a connected product's life: how new software gets onto it. For an embedded Linux gateway with a ten-year service life, the two are equally hard.
Why gateways need an update framework at all
The naive update path is familiar. Copy the image over SSH, write it to flash, reboot. It works until power is lost halfway through a write and a device nobody can reach no longer boots. That failure mode, and its relatives, is why update frameworks exist.
Mender, RAUC and SWUpdate differ in shape but solve the same class of problem: updates that are atomic, so a device is always left with one complete, working system; rollback, so a failed update reverts instead of bricking; and fleet state you can reason about, so a thousand devices do not drift into a thousand configurations. Most designs pair this with an A/B partition layout, where the new system is written to the inactive slot and the device falls back if it does not come up.
What a signed update decides, and the framework doesn't
The framework moves bytes and manages slots. It will faithfully install whatever verifies. What the device should accept is a different question, and no choice of framework answers it. It is decided by a signature, and by who controls the key that makes it.
Each framework carries this at its core. Mender verifies a signature over the .mender artifact. RAUC signs the bundle, whose manifest carries the hashes of everything inside. SWUpdate verifies a signature over the image description. Different formats, same shape: one signature, made at release time with the manufacturer's private key, checked on the device before anything is written to flash.
Which means the security of the whole update path reduces to two questions that have nothing to do with the framework: where does that private key live, and who can use it. A framework with signature verification enabled and the signing key sitting in a CI variable is a locked door with the key under the mat.
Two signatures, not one
This is where the previous post connects. The update signature is checked once, at install time, by the update client. The boot chain then verifies the installed system again on every boot, against its own trust anchors. Two different verifications, usually two different keys. A gateway that runs RAUC on an i.MX8M carries both: the certificate its update client uses to verify bundles, and the boot keys fused into the SoC that anchor what runs. The i.MX8M reference design walks the complete pair. Assuming one covers the other is the most common gap in update designs.
An authentic old version is still authentic
One more thing the framework cannot decide for you. A signature proves origin, not currency. Last year's release, the one with the vulnerability you patched in March, still carries a perfectly valid signature. An attacker who can offer it to a device performs a downgrade attack using nothing but your own signed artifacts.
The countermeasure is version anti-rollback: the device keeps a record of the version or security counter it is on and refuses anything older. The building blocks exist across the stack, version constraints in the update frameworks and rollback counters in the boot chain, but none of them is on by default. Somebody has to decide the policy, turn it on, and make sure a legitimate factory reset or service downgrade still has a path. A signed update practice answers two questions before install: who made this, and is it newer than what runs now.
Where the CRA lands on this
Annex I of the Cyber Resilience Act expects products to have a secure update mechanism and to keep receiving security updates for their support period. It names no tool. An update framework with signed bundles, verified before install, with rollback protection, for every release across the product's supported life, is how engineering teams make those words true. The Annex I mapping sets out which requirement each mechanism answers.
The support-period part deserves one sentence of its own: signing is not a launch activity. The setup has to outlive team changes, build migrations and the person who configured it, because the obligation runs as long as the product does.
Three questions for your own product
If you pulled your latest release off the update server today, could you verify who produced it without asking anyone?
Who can produce a signature your fleet accepts, and is there a record of each one?
Is there anything that stops your devices from accepting an older release that still carries a valid signature?
If any answer is unclear, that is worth a look before December 2027 turns it from an engineering question into a compliance one.
Further reading: the Solutions section has complete reference designs for signed updates and secure boot on embedded Linux gateways and MCU targets.
Comments