Security requirements for connected products: the disruption brought by the Cyber Resilience Act
What falls under the scope – and what doesn’t
The Cyber Resilience Act applies to all products with digital elements. This includes both hardware and software, as long as they can be connected directly or indirectly to a network. This definition encompasses IoT devices, industrial control systems, operating systems, firmware, and communication software. Even Software-as-a-Service functionalities, if based on remote data processing, may fall under the regulation.
Certain sectors already governed by specific safety standards are exempt, such as medical devices, vehicles, aviation, or certain defense-related components. Open-source software is excluded, provided it is not commercially used. However, if support or consulting services are offered, the CRA also applies. This particularly affects providers who reuse open source in commercial products.
Who is affected by the CRA ? Manufacturers, suppliers, distributors
The party responsible for complying with CRA requirements is the one placing a product on the EU market for the first time. This may be the manufacturer, an importer or a distributor. What matters is not the company’s location, but its access to the market.
Suppliers and software providers must also engage with the CRA, even if they do not operate directly on the market. Manufacturers are required to document and secure their entire supply chain. Anyone providing components, libraries or embedded software becomes part of the regulatory system. The CRA imposes a new standard of transparency here.
Obligations and requirements: the CRA reshapes product development
Key requirements include :
– risk assessments before market entry,
– documentation of architecture, security features, and risk analyses,
– security-by-design throughout the development process,
– vulnerability management across the product lifecycle,
– mandatory security updates during product use (at least five years or the expected product lifespan),
– reporting security incidents and vulnerabilities to national authorities and ENISA within 24 hours.
This isn’t just about technical measures. Organisational processes and incident response capabilities must also be documented. Products must be delivered with a secure default configuration. Logging functions, user management, interface control, and a Software Bill of Materials (SBOM) are all required elements.
Impact on existing products
Products already on the market may also fall under the CRA if they are produced or modified after the regulation comes into force. This raises the question of whether such products can be updated and brought in line with current security requirements. This is particularly challenging for products with static architecture. For companies that rely on long product lifecycles, this poses a strategic risk.
Technical documentation and risk communication
A central element is technical documentation. It must clearly and comprehensibly outline the product’s security features, risks and protective measures for both market authorities and customers. For existing products, it is advisable to revise documentation and add a structured risk assessment.
For new products, risk analysis must be part of the development process. This involves not only evaluating how the product mitigates risks, but also how it fits into real-world use scenarios. Understanding the actual conditions under which customers use the product is essential. Those who can identify and explain such risks may, in some cases, forgo certain technical safeguards if they are compensated for by organisational or operational measures.
Supply chain, suppliers and third-party software components
Manufacturers must maintain oversight: which components are used, which libraries are included, and what dependencies exist? Third-party libraries and open-source components pose particular risks. The possibility that they may no longer be maintained must be considered in advance.
The CRA deliberately leaves open how these risks should be addressed on a case-by-case basis. However, it is clear that manufacturers are responsible for keeping their products secure even if suppliers withdraw. Interchangeability of components, internal patching capabilities, and careful management of the software list are essential.
Classification, compliance, certification
The CRA categorizes products into different risk classes. For especially critical product groups, external conformity assessment by a notified body is mandatory. In less critical cases, a self-declaration is sufficient.
However, even this declaration must be based on structured analysis and proper documentation. Inaccurate statements, implementation gaps or inadequate control may lead to serious consequences, including the loss of CE marking and a ban from the European market.
What to do now
Companies should analyse their product portfolios to identify which ones are affected by the CRA. Both new and existing products must be assessed. Where adaptation is not feasible, alternative or phase-out strategies should be considered.
It is also advisable to involve cybersecurity experts early in the development process. This is especially relevant for SMEs, where security has often been an afterthought. The CRA changes that. It also requires companies to establish clear organisational processes, define responsibilities, and build a resilient security culture.
Looking ahead: the CRA as an opportunity
As demanding as the transition may be, the CRA also presents opportunities. Companies that can demonstrate secure, well-documented and lifecycle-managed products will gain a competitive edge. Cybersecurity thus becomes not just a duty, but a marketable quality standard.
And it becomes a prerequisite for access to the European market. That alone should be incentive enough to act now.