What the Cyber Resilience Act now requires of manufacturers
Since 11 September 2026, manufacturers have been required to report actively exploited vulnerabilities within 24 hours. That sounds like a mere formality. In practice, however, it requires something that many companies still lack: the ability to even detect attacks on their own products. The story of how this came about begins in a factory workshop several decades ago.
For a long time, the only thing that mattered was that the machine was running
In the late 1990s, somewhere in a medium-sized factory workshop. A new production line is delivered, assembled and commissioned. The manufacturer’s technician checks the speeds, sets up the first jobs and shows the shift supervisor where to read the production figures. By the end of the day, the machine is running. Nobody wanted anything more.
At that moment, nobody asks whether the control system transmits its data in encrypted form. The system is not connected to any network that extends to the outside world. The greatest threat to production is bearing failure, not an attacker. A security concept in the modern sense is not included in any specifications, simply because there is no need for one.
The years pass, and the machine continues to run. At some point, it is connected to the company network so that production data can flow directly into planning. Later, remote maintenance access is added so that the manufacturer no longer has to travel out for every fault. The system is now networked. However, it is still built just as it was back then: logs that anyone on the network can read, software that hasn’t seen an update since it was commissioned.
And who takes care of this? The manufacturer cannot see what is happening to its equipment at the customer’s premises. The customer is often not even allowed access: no administrator rights, no insight, and sometimes even an explicit instruction not to change anything, otherwise the warranty will be void. Responsibility for security lies somewhere in between – in other words, with no one.
Just how costly this gap can be became apparent in 2016. The The Mirai botnet scoured the internet for routers, cameras and other connected devices that were still running on factory or default passwords, and took control of them on a massive scale. Using this borrowed computing power, the attackers launched a DDoS attack that, amongst other things, paralysed the DNS service provider Dyn, and numerous well-known websites were temporarily unavailable. The point of entry was not a sophisticated exploit, but a password that had been set at the factory and never changed.
Today, security is part of the product
Back to the present. Today’s factory floors are fully networked, products with digital elements are found in almost every company, and attackers are specifically targeting precisely those vulnerabilities that nobody has fixed for years. With NIS2, there are now clear guidelines for the security of corporate networks. For a long time, there were virtually no requirements for the security of the products running on these networks.
This is precisely where the Cyber Resilience Act comes in. The European Commission presented it in 2022, and it has been in force since 10 December 2024. Its message is unambiguous: whoever builds a product is also responsible for its security – not just on the day of delivery, but throughout its entire lifecycle.
The CRA redistributes responsibility
The Cyber Resilience Act (Regulation (EU) 2024/2847) applies to products with digital elements, i.e. hardware and software, and is primarily aimed at manufacturers. Importers and distributors also have obligations, albeit to a lesser extent.
In this respect, the CRA differs fundamentally from NIS2. NIS2 obliges organisations to secure their own operations. The CRA intervenes at an earlier stage: with the products that these organisations use. Security becomes a product characteristic that must be demonstrated before the product is placed on the market.
In concrete terms, this means, amongst other things:
Security by design and by default: Products must not have any known exploitable vulnerabilities and must be supplied with a secure default configuration.
Vulnerability management: Manufacturers must provide security updates throughout the entire support period. This is generally at least five years.
SBOM: Manufacturers must draw up a Software Bill of Materials, i.e. a list of the software components used. They are not required to publish it.
If attacks are not detected, they cannot be reported
The first specific obligation comes into force on 11 September 2026. Manufacturers must report actively exploited vulnerabilities and serious security incidents, in accordance with the following fixed stages:
an early warning within 24 hours,
after 72 hours further information,
no later than 14 days after a security update or workaround, a final report for vulnerabilities; for security incidents, one month after the initial report.
Reports are submitted via the ENISA’s Single Reporting Platform. They are sent to ENISA and to the relevant coordinating CSIRT; in Germany, this is the CERT-Bund at the BSI.
The clock starts ticking from the moment the manufacturer becomes aware of the vulnerability. This is precisely where the problem lies. Many manufacturers, particularly small and medium-sized enterprises, do not yet have mechanisms in place to detect attacks on their products. And as a rule, it is not the manufacturer itself that discovers the vulnerability, but a penetration tester, a security researcher or, in the worst-case scenario, an attacker.
Anyone who lacks a functioning process for receiving, assessing and passing on such reports faces a structural problem with the 24-hour deadline.
Sweeping things under the carpet is no longer a strategy
Until now, it was quite common to patch vulnerabilities quietly and not make a big fuss about them. The CRA turns this logic on its head. Transparency becomes mandatory.
This raises an uncomfortable question: Is a manufacturer that never reports anything particularly secure, or does it simply fail to detect anything?
This is no excuse. Testing, code reviews and secure development processes remain the responsibility of the manufacturers. But those who identify vulnerabilities quickly, report them transparently and fix them promptly demonstrate maturity, not weakness.
An Excel spreadsheet is no substitute for an SBOM
Even the SBOM sounds straightforward on paper. In practice, modern products contain numerous libraries and modules in different versions, which can change with every release. Anyone attempting to document this manually will quickly lose track in agile development cycles.
Realistically, this only works if it is automated and directly integrated into the build and release processes. However, this automation must first be set up, tested and integrated. For existing products, this means a considerable amount of rework.
The timeline is tight
The CRA will come into full effect on 11 December 2027. From then on, only compliant products may be placed on the market in the EU, and penalties will also come into effect: up to 15 million euros or 2.5 per cent of global annual turnover.
That sounds like plenty of time, but it isn’t. Product life cycles span years. Products coming onto the market in 2027 were often designed at a time when cybersecurity barely featured in the specifications.
NIS2 illustrates just how protracted the implementation of regulation can be. According to the BSI, around 20,000 organisations had registered by the end of September 2026. The figure expected was around 29,500. Many organisations simply do not realise that they are affected, or they are adopting a wait-and-see approach.
The real impact will become apparent in a few years’ time
The CRA will not make all products secure overnight. Its initial impact is different: it is changing expectations. Even now, customers are asking more specific questions in tenders about how software works and whether insecure protocols are in use.
For manufacturers, CRA compliance is therefore becoming a prerequisite for market access, much as ISO 27001 already is in many tenders. Those who start early have a head start. Those who wait and see will later find themselves working under time pressure.