Secure boot, secure updates and device identity: the three practices the CRA quietly expects

Ask an embedded team what the EU Cyber Resilience Act (CRA) means for their product and you will usually hear about paperwork: conformity assessments, an SBOM, a vulnerability reporting process. All true. But Annex I of the regulation also describes the product itself, and three of its expectations are basic engineering practices that many devices in the field still don’t have.

Since 11 September 2026 manufacturers must report actively exploited vulnerabilities. From 11 December 2027 the full set of requirements applies to every product with digital elements sold in the EU. The reporting duty is a process. The rest is design.

One: the device only runs what you signed

Products shall “be made available on the market with a secure by default configuration” and “protect the integrity of … programs and configuration against any manipulation or modification not authorised by the user”. In practice that is secure boot: a chain of trust that starts in silicon, verifies the bootloader, the kernel and the trusted applications, and refuses anything else.

Most SoCs and MCUs have supported this for a decade. NXP’s HAB, TI’s K3 boot ROM, Espressif’s Secure Boot V2, Infineon’s Flash Boot, MCUboot on almost every Cortex-M: the mechanism is there. What is usually missing is not the feature but the discipline around it. Where is the signing key? Who can use it? What happens when a developer leaves, or a build server is compromised?

Question for you: Where is your boot signing key stored, and who can use it?

Two: the device keeps accepting fixes, and only fixes

The CRA turns “we can push updates” into an obligation: security updates for the support period, delivered in a way the device can verify. Signed firmware updates are the second half of secure boot. Secure boot decides what may run; signed updates decide what may replace it. A device that verifies its bootloader but installs any update bundle it downloads has protected the wrong door.

Update frameworks like RAUC, SWUpdate, Mender, and the OTA services of the large cloud providers all verify signatures. The design decisions live around them: one key or a hierarchy, how a signing certificate reaches the device, whether the update format can carry a certificate at all, and what an approver actually sees before a release is signed.

Question for you: Do you have a log of every update you signed, and who approved each one?

Three: every device can prove who it is

The third expectation is quieter: Annex I asks for “protection from unauthorised access by appropriate control mechanisms, including but not limited to authentication, identity or access management systems”, and Article 13 requires every product to carry an element “allowing their identification”. For a connected device that means a cryptographic identity, born in the factory and never leaving the hardware, followed by an operational identity issued by whoever runs the device afterwards. IEEE 802.1AR names them IDevID and LDevID. Onboarding, mutual TLS and EST enrollment all hang from that first identity.

This is where PKI stops being an IT topic and becomes a manufacturing one. A certificate authority that issues one certificate per unit, at line speed, under a policy that auditors can read, is a different animal from the corporate CA that signs VPN certificates.

Question for you: Do you know which CA issued your devices’ identities, and who is allowed to issue new ones?

What the three have in common

Look at the three practices together and the same shape appears in each: a private key that must never be exposed, a policy about who may use it, a record of every use, and a way to get the public half onto the device. Secure boot, secure updates and device identity are not three projects. They are one key-management problem seen from three sides, and the CRA is the first regulation that asks for all three at once.

Teams that treat them as one problem tend to end up with fewer keys, clearer approvals and much shorter audit conversations. Teams that solve them one at a time tend to end up with three key stores, three approval processes and a diagram nobody wants to redraw.

A plain-language mapping of the CRA’s Annex I to engineering practice is at docs.laavat.io/cra-compliance.

Further reading: worked examples of all three, docs.laavat.io/solutions.