Note, 5 October 2026

Cyber Resilience Act: what your devices should be able to tell you

Since 11 September 2026, a manufacturer that learns one of its connected products is being attacked through a flaw has at most 24 hours to send an early warning. That warning is short. The notification due two days later is not, and most of it can only be answered if the device and the system behind it can tell you.

What changed on 11 September

Article 14 of the EU's Cyber Resilience Act, the manufacturer's reporting duty, applies from that date. Most of the rest of the regulation follows on 11 December 2027 (Article 71). The Commission's summary gives the clock for a vulnerability that is being actively exploited:

24 hours

An early warning, counted from the moment the manufacturer becomes aware.

72 hours

A fuller notification.

14 days

A final report, counted from the day a fix or a mitigation is available.

A severe incident runs on the same first two steps, with its final report due a month after the notification. Everything is filed once, through ENISA's Single Reporting Platform.

Article 69(3) says the duty covers products placed on the market before December 2027. If a product is in scope, that includes units shipped three years ago.

Whether a product is in scope, and who is its manufacturer, is a question for a lawyer. This note is about the engineering.

What the reports ask for

Article 14 reads like a list of questions. The early warning names the Member States where the product is known to be available. The notification gives general information about the product, the nature of the exploit and of the vulnerability, what has been done about it, and what users can do. The final report describes the vulnerability with its severity and impact, who exploited it where that is known, and the update that fixes it. Paragraph 8 adds one more job: tell the users who are affected.

None of this is hard to write down. All of it is hard to know in three days, unless the product was built to tell you.

Four things the device should be able to answer

1. Which units run the affected code

Give every build an identity: a version and the commit it was built from, compiled into the image and readable over the wire. Have every unit report the build it runs and its hardware revision. Keep, for each build, the list of what is in it and how it was configured: bootloader, RTOS, TLS library, radio stack, each with its version and its build options.

The regulation asks for that list as a software bill of materials from December 2027 (Annex I, Part II). It is needed sooner: it is what turns "there is a flaw in this library" into a list of serial numbers.

A test from last week: CVE-2026-71973, published on 29 September, is an integer overflow in the SquashFS reader of the U-Boot bootloader, in versions before 2026.10-rc4. Its record describes an out-of-bounds heap write from a crafted image and no known attacks, so on that record it is not "actively exploited" as the regulation defines it. It is still a good question to practise on. SquashFS support is a build option in U-Boot. How long would it take to say which of your units carry a U-Boot built with it?

2. Where they went

The early warning names countries. A device does not know its country. The shipping record does. When a unit leaves for a customer, record who it went to and which country, against its serial number. If it is sold through distributors, record the distributor and its market.

3. Whether a fix can reach them

The update path has to exist before the problem does: signed images, a version floor so that a fixed unit cannot be put back on the old build, a second slot to fall back to, a rollout that can be staged and stopped. Check what the path covers: on many boards it updates the application and never the bootloader. Know which units have not checked in, and for how long. Send a harmless update through it on a schedule, so its first real use is not its first use.

4. What users can do until then

The notification asks for measures users can take. Decide now what they are: a service that can be switched off remotely, a port closed by configuration, an instruction that fits in two lines. Keep a way to reach users that does not depend on the broken feature.

How you would find out

The clock starts when the manufacturer becomes aware. The Commission's guidance reads that as the point where, after a first assessment, the manufacturer is reasonably certain that a flaw in its product is being exploited. The first sign arrives in three ways. Someone tells you: publish a security contact, usually a security.txt file. Your telemetry shows it: have devices report resets, failed updates and rejected signatures. Or a component you ship gets an advisory that reports attacks: watch the advisories for every entry on the list from point 1.

Not every flaw starts the clock. The regulation's word is "actively exploited": there is reliable evidence that an attacker has used the flaw against a system without its owner's permission (Article 3).

A drill for this week

Pick one component in your current firmware. Assume a flaw in it is being used against your product, and start a timer. Which units. Which countries. Can a fix reach them. What do users do meanwhile. Whatever cannot be answered within the hour is the work list.

All notes