The update mechanism is a CRA requirement, not a feature
Annex I requires that vulnerabilities can be addressed through security updates, including automatic updates where appropriate with a clear opt-out, and that updates be distributed without delay and free of charge. If your device cannot be updated in the field, it cannot comply — full stop.
Anatomy of a compliant updater
- Signed images. Verify the signature before writing, and again before booting. Verify on the device, never trust a server-side check.
- Integrity and version metadata in a signed manifest: image hash, version, minimum version (anti-rollback), hardware compatibility, and a build identifier that maps to your SBOM.
- Atomic application. A/B slots, or a golden recovery image. A power cut mid-update must never brick the unit.
- Rollback protection. A monotonic version counter, ideally backed by OTP or secure element, so an attacker cannot install a validly signed older image with a known vulnerability.
- Automatic rollback on failure. A watchdog-guarded first boot: if the new image fails to check in, revert to the previous slot.
- Transport security. TLS with certificate pinning or a private trust store; but the image signature is what actually protects you, so never rely on transport alone.
Flash budgeting
A/B slots double firmware footprint. That decision belongs at silicon selection, not at feature freeze. When dual-slot really does not fit:
- Use a minimal, immutable recovery bootloader that can re-download a full image.
- Support delta or compressed updates to reduce transfer size, but keep the verification of the final assembled image intact.
- Never accept an in-place overwrite of the running application without a recovery path.
Devices that are rarely connected
Battery-powered, LPWAN, or air-gapped products still need an update route. Acceptable patterns: update over the local gateway, technician-delivered updates over BLE or USB with the same signature checks, or scheduled maintenance windows. Whatever you choose, document it in the user information as the mechanism by which security updates are supplied.
Separating security updates from feature updates
Users may opt out of automatic updates, and functional changes may need customer acceptance testing in industrial settings. Ship security fixes on a separate channel so a customer who has frozen feature releases still receives security patches. This is also how you avoid a security patch accidentally becoming a substantial modification.
Operational obligations
Once you issue a security update, it must remain available for at least ten years after release, or for the remainder of the support period if that is longer. That is an infrastructure commitment: keep the artefact store, the signing chain, and the download endpoints alive, and include them in your business continuity planning.