EU Cyber Resilience Act: security obligations that ship with the product

The Cyber Resilience Act regulates the security of products with digital elements placed on the EU market - shifting responsibility onto manufacturers rather than the organisations that buy and deploy them. Where NIS2 and DORA regulate how organisations operate, the CRA regulates what you are allowed to sell.

What it covers

"Products with digital elements" is deliberately broad: software and hardware products with a data connection, and their remote data processing solutions. That reaches far beyond obvious security products:

• Commercial software, including operating systems and applications.
• Connected hardware - industrial equipment, consumer IoT, network devices.
• Components and libraries placed on the market.
• Remote processing elements integral to a product's function.

Certain categories carry heavier conformity requirements based on criticality. Some products regulated elsewhere - for example certain medical devices and vehicles - are handled under their own regimes.

The core manufacturer obligations

1. Security by design and by default. Products delivered with a secure default configuration, without known exploitable vulnerabilities.
2. Risk assessment for the product, documented and maintained through its lifecycle.
3. Vulnerability handling - a process to identify, remediate and disclose vulnerabilities, with security updates provided.
4. A support period during which security updates are provided, communicated clearly to buyers.
5. Software bill of materials (SBOM) covering at minimum the top-level dependencies.
6. Coordinated vulnerability disclosure policy, published so researchers know how to report.
7. Reporting obligations for actively exploited vulnerabilities and severe incidents, on defined timelines.
8. Conformity assessment and CE marking, with technical documentation retained.

The support period is the obligation with the largest commercial consequence. Committing publicly to a security update window changes product economics, end-of-life planning and how you price long-lived products.

Who bears the obligations

• Manufacturers carry the primary burden - including anyone placing a product on the market under their own name or trademark.
• Importers and distributors have verification duties before placing products on the market.
• Open-source is treated distinctly, with lighter treatment for non-commercial development but obligations arising in commercial contexts.

The white-label trap applies here as it does under the AI Act: rebranding someone else's product under your name can make you the manufacturer, with the full obligation set.

What to do now

1. Determine whether your products are in scope and whether you are manufacturer, importer or distributor for each.
2. Produce SBOMs and keep them current - this is achievable now and underpins vulnerability handling.
3. Establish coordinated vulnerability disclosure with a published policy and a monitored contact route.
4. Define support periods per product and communicate them, then plan the engineering capacity to honour them.
5. Formalise secure development - threat modelling, dependency scanning, secure defaults, release security review.
6. Build the reporting muscle for actively exploited vulnerabilities, with a named decision-maker and prepared templates.
7. Assemble technical documentation as you develop rather than reconstructing it for conformity assessment.

Obligations phase in over time. Confirm current timelines and the applicable conformity route for your product category with qualified advisors - this is orientation, not legal advice.

Key takeaways

• The CRA regulates products; NIS2 and DORA regulate organisations.
• "Products with digital elements" reaches far beyond security products.
• Support periods have real commercial consequences - plan capacity for them.
• SBOMs and coordinated disclosure are achievable now and underpin the rest.