The Cyber Resilience Act and Secure OTA Updates for Embedded Linux

In short: The EU Cyber Resilience Act turns “ship it and forget it” into a liability. For a connected embedded Linux device it means one thing above all else — you must be able to deliver signed, verifiable security updates for years, which makes a fail-safe OTA path, a secure boot chain, and a build-generated SBOM the technical backbone of compliance rather than optional extras.

Connected industrial devices have long been shipped and then largely left alone. The Cyber Resilience Act (CRA) ends that model: it treats the ability to receive and apply security updates as a property of the product itself. This article looks at what the regulation asks of a device with digital elements and how those duties translate into concrete engineering decisions on an embedded Linux platform — with over-the-air (OTA) updates at the centre. It describes technical measures, not legal obligations: assessing how the CRA applies to a specific product is a question for qualified legal counsel.

What the Cyber Resilience Act asks of connected products

The CRA is an EU regulation covering “products with digital elements” — essentially any hardware or software whose intended use involves a data connection to a device or network, which sweeps in the overwhelming majority of connected industrial and embedded products. Rather than prescribing a particular technology, it sets essential cybersecurity requirements: products must be secure by default, be made available without known exploitable vulnerabilities, protect the integrity and confidentiality of code and data, and — crucially for long-lived hardware — receive security updates over a defined support period. Manufacturers also take on process duties: a coordinated vulnerability-handling process and reporting of actively exploited vulnerabilities within tight deadlines.

The regulation does not take effect all at once. It entered into force in late 2024, and its obligations phase in in stages over the following years — reporting duties for actively exploited vulnerabilities arrive first, and the central product-related obligations apply later, around 2027. Treat any specific figure here as general orientation and confirm the exact dates, and how they map to your product, with legal counsel. Technically, these timelines leave less runway than they suggest, because the decisions that determine whether a device can be updated securely — partition layout, boot chain, key management — are made at the very start of a platform’s life, not bolted on before a deadline. Note again: this is a technical overview, not legal advice.

From regulatory duty to technical measure

Most of the CRA’s essential requirements have a direct engineering counterpart on an embedded Linux stack. The mapping below is not exhaustive, and meeting these measures does not by itself establish conformity — but it shows where the regulation lands in the build.

CRA-driven need	Concrete technical measure on embedded Linux
Security updates across the support period	Fail-safe A/B OTA with automatic rollback; signed update bundles; delta updates
Integrity and protection against tampering	Secure boot chain of trust; signed images; read-only, dm-verity rootfs
Software bill of materials	SBOM generated from the build (SPDX via Yocto)
Handling and remediating vulnerabilities	CVE monitoring against NVD data; LTS-branch backports; reproducible rebuild and reissue
Secure by default, minimal attack surface	Minimal custom image; no unused services; hardened defaults
Traceability of shipped versions	Reproducible, pinned builds; signed, versioned release artifacts

None of these is exotic; each is an established practice in long-lived embedded Linux. The CRA’s contribution is to make them non-negotiable and to tie them to a support period measured in years.

The update path becomes the load-bearing element

If a device must receive security fixes for its entire support period, the update mechanism stops being a convenience feature and becomes the component the rest of the design serves. A single-image, “reflash it in the field” approach does not scale to a fleet and fails badly the first time an update is interrupted by a power cut. The requirement is therefore not just “can we push a new image” but “can we push one to thousands of remote devices, over unreliable networks, without ever bricking one.” This is core to how we approach the Embedded Linux platform: the update strategy is designed in from the first BSP, not retrofitted.

Fail-safe OTA: A/B partitioning, signed images, delta updates

The established answer is redundant A/B partitioning: two copies of the root filesystem, only one active at a time. An update is written to the inactive slot while the device keeps running from the active one; on reboot the bootloader tries the new slot, and a watchdog or health check confirms it booted. If it doesn’t, the bootloader automatically rolls back to the known-good slot. A failed or interrupted update costs a reboot, not a truck roll.

Three mature frameworks implement this pattern on embedded Linux: RAUC, SWUpdate, and Mender. All support A/B slots, atomic installation, and — essential under the CRA — cryptographic signatures on the update artifact, so a device only installs an image signed by the manufacturer’s release key. RAUC, for example, describes an update as a signed bundle with a manifest:

# manifest.raucm — contents of a signed A/B update bundle
[update]
compatible=example-board-imx8
version=1.4.0

[bundle]
format=verity          # dm-verity-protected, integrity-checked bundle

[image.rootfs]
filename=rootfs.img

The bundle is signed when it is built, and the device verifies that signature against a baked-in certificate before it touches the inactive slot:

# create and cryptographically sign the update bundle
rauc bundle \
  --cert=release.cert.pem \
  --key=release.key.pem \
  input-dir/ update-1.4.0.raucb

For fleets on metered or slow links, delta updates transmit only the changed blocks between the installed and the new image instead of the full rootfs, cutting bandwidth and update time substantially — which matters when a security fix has to reach every unit quickly.

Secure boot and an unbroken chain of trust

Signed updates only help if the thing verifying them can itself be trusted. That is what secure boot establishes: an unbroken chain in which each stage cryptographically verifies the next. The SoC’s immutable boot ROM checks the signature of the bootloader (using a key hash fused into one-time-programmable memory), the bootloader verifies the kernel and device tree — typically via a signed U-Boot FIT image — and the kernel mounts a rootfs whose integrity is guaranteed, commonly a read-only, dm-verity-protected filesystem. If any stage fails verification, the device refuses to run tampered code.

A read-only rootfs is worth emphasising on its own: it satisfies the integrity expectation and simplifies the update model, because writable state is confined to a separate data partition. That keeps the A/B slots byte-for-byte what the release build produced — and byte-for-byte what your SBOM describes.

SBOM and vulnerability management across the support period

You cannot patch what you cannot see. The CRA’s vulnerability-handling duties presuppose that a manufacturer knows exactly which components — and which versions — are in a shipped image. The most reliable way to get that is to generate a machine-readable Software Bill of Materials (SBOM) directly from the build rather than compiling a list by hand. A Yocto build can emit an SBOM in SPDX format as a by-product of the image build, describing every package that actually shipped. We go into that build-side tooling in depth in our article on the advantages of Yocto in industrial environments, and it is central to our Yocto BSP work.

The SBOM is the input to ongoing vulnerability management: match the component list against public CVE feeds (Yocto’s cve-check does this at build time against NVD data), triage what actually affects the device, backport or update the fix on a maintained LTS branch, rebuild reproducibly, and ship it through the signed OTA path above. That loop — detect, patch, rebuild, deploy — is precisely the “handle vulnerabilities across the support period” duty expressed in engineering terms.

Wiring it into a reproducible CI build with managed signing keys

All of this only holds up if the release build is reproducible and the signing keys are handled properly. A reproducible, pinned build means the image you ship — and re-ship after a patch — is exactly the one you tested and described in the SBOM, with no “works on the build server” ambiguity. On every release, the CI pipeline should produce the signed OTA bundle, the SBOM, and a CVE report as versioned artifacts.

Signing keys deserve particular care: the private key that authorizes updates is, in effect, the master key to the fleet. It belongs in a hardware security module or a managed key service — never in the source tree, a container image, or a developer’s home directory. CI signs by requesting a signature from that service, so the key itself never lands on a build runner. Getting this architecture right early is exactly the kind of question our technical consulting is there for.

Conclusion

The Cyber Resilience Act does not ask embedded manufacturers to invent new technology — it asks them to adopt, and commit to for years, practices that mature embedded Linux teams already know: fail-safe A/B OTA with signed images and automatic rollback, a secure boot chain over a read-only rootfs, a build-generated SBOM, and a disciplined, reproducible CI that keeps signing keys out of harm’s way. No single setup “guarantees compliance,” and the legal assessment belongs with qualified counsel — but a platform built this way has the technical foundations in place instead of facing a scramble before the obligations bite.

If you are planning a new device or bringing an existing one up to this standard, get in touch to talk through your update and security architecture.