A router that stops receiving security updates after two years. A networked machine control system where no one can say for sure which open-source libraries are inside. Such cases were long an annoyance, but not a legal violation. That is now changing: With the Cyber Resilience Act (CRA), the EU has established binding cybersecurity requirements for connected products for the first time. For manufacturers, the first major operational compliance date was September 11, 2026.
What is the Cyber Resilience Act?
The Cyber Resilience Act (CRA) is an EU regulation that introduces uniform cybersecurity requirements for so-called “products with digital elements”. This refers to hardware and software that are directly or indirectly connected to other devices or networks. The regulation was published in the Official Journal of the EU on November 20, 2024, and entered into force on December 10, 2024.
The underlying concept: Cybersecurity should no longer be something that is retrofitted after an incident, but a feature that is considered across the entire product lifecycle – from concept through development and production to the usage phase. As an EU regulation, the CRA applies directly in all member states; no national implementation is required.
Thus, the CRA aligns with a logic familiar from product safety law: Anyone placing a product on the European market must be able to prove that it meets certain requirements. What is new is that cybersecurity is now explicitly included.
Who is affected by the CRA?
Manufacturers, importers, and distributors of products with digital elements placed on the EU market are affected. The scope of application is intentionally broad, ranging from consumer devices like smartwatches and baby monitors to industrial components, IoT sensors, firewalls, and routers. Pure software products also fall under its scope.
The CRA differentiates based on risk: In addition to the default category, there are “important” and “critical” products with digital elements, for which stricter conformity assessment requirements apply. For manufacturers, this means first of all: It is worth assessing your own portfolio early on to determine which products fall under the scope of application at all and which category they belong to.
Another point that is easily overlooked is also important: The reporting obligations from September 2026 apply not only to products newly placed on the market after this date. They also cover products that have already been in the field for years. For many companies, this means having to deal with an installed base whose software versions are not consistently documented.
The supply chain adds another layer of complexity. Today, hardly any connected product consists solely of proprietary code – open-source libraries, purchased modules, and firmware from suppliers are the rule. Responsibility toward the market remains with the manufacturer, regardless of where a vulnerability originates.
Timeline and Deadlines
The CRA becomes effective in stages. Here are the dates you should have on your calendar:
The reporting deadlines are the part that experience shows puts organizations under pressure first. 24 hours is not a time frame in which a reporting chain can still be improvised – the processes, responsibilities, and contact channels must be established beforehand.
The Key Obligations for Manufacturers
In terms of content, the requirements of the CRA can be boiled down to a few key points:
Risk assessment over the lifecycle. Manufacturers must assess, document, and implement appropriate cybersecurity risk protection measures – not just once, but continuously across design, development, production, and usage.
Software Bill of Materials (SBOM). A machine-readable bill of materials of the contained software components must be maintained for every affected product, at least down to the level of direct dependencies. Common formats are SPDX and CycloneDX. The SBOM does not need to be published, but it belongs in the technical documentation and must be presented to market surveillance authorities upon request. And it must stay up to date: Every update potentially changes the software version.
Vulnerability and patch management. Security updates must be provided over an appropriate support period. This requires manufacturers to know which software version and configuration were delivered with a particular product and which versions are currently installed in the field.
Technical documentation and CE marking. From December 2027, CE marking is a prerequisite for market access. It is based on documentation that makes conformity verifiable.
The sanctions are substantial: Non-compliance can be penalized with fines of up to 15 million euros or 2.5 percent of total worldwide annual turnover.
What Companies Should Do Now
Companies that have not yet completed their reporting readiness should treat this as an immediate operational priority. Four steps are a sensible starting point:
- Clarify applicability. Which products fall within the scope of application and which risk class applies?
- Set up reporting processes. The 24-hour deadline starting in September 2026 is the immediate hurdle. Who reports, to whom, via which channel – and who decides whether a vulnerability is “actively exploited”?
- Build SBOM capabilities. This should not be understood as a one-off project, but as part of the development and release process.
- Clarify responsibilities. The CRA affects security, product development, quality assurance, and compliance simultaneously. Without clear assignment, the task gets lost between departments.
Rather than running these activities as a separate compliance project alongside product development, companies should embed them into existing development and release processes. Requirements that live only in a separate proof folder quickly become outdated – those anchored in the release process remain up to date.
Where a Consistent Product Database Helps
Most CRA requirements ultimately lead back to the same question: Can you state – even five years after delivery – which components a particular product contains, which requirements applied to it, and which software version and configuration were delivered?
This is precisely where a PLM platform comes in. CONTACT Elements maps the product lifecycle end-to-end and links requirements, components, documents, and revision statuses with one another. This traceability is not CRA compliance in itself – but it is the foundation on which SBOM maintenance, technical documentation, and proof management for authorities can be organized in a practical manner, rather than scrambling to gather them from scattered sources in an emergency.
If you are considering how to integrate CRA requirements into your existing development processes, please feel free to contact us.
Conclusion
The Cyber Resilience Act shifts cybersecurity from a voluntary quality issue to a prerequisite for market access. The deadlines in September 2026 and December 2027 may seem comfortable at first glance, but they affect processes that cannot be built overnight – in particular, reporting chains and a reliable documentation of your own software inventory. The best time to start is well before the deadline.