Legislation · 13 Dec 2024 · Rob Nidschelm

The Cyber Resilience Act Is Here: Security Becomes a Product Requirement

The Cyber Resilience Act entered into force on 10 December 2024. For organisations that design, develop, manufacture or sell connected hardware and software in Europe, cybersecurity is moving from a best-practice discussion to a product-market requirement.

For years, product security has depended too heavily on the priorities of individual manufacturers. Some products receive strong security engineering and years of updates. Others reach the market with default passwords, unnecessary services, unclear ownership of third-party components and no credible plan for handling vulnerabilities after sale.

The European Union’s Cyber Resilience Act, or CRA, is intended to change that baseline. It introduces horizontal cybersecurity requirements for products with digital elements made available on the EU market. In practical terms, the regulation connects cybersecurity to the same product disciplines that already govern safety, quality, documentation and market access.

The most important message is not that another compliance programme has arrived. It is that product security now has to become a managed lifecycle.

The change behind the headline

The CRA is the first EU legislation to place broad mandatory cybersecurity requirements on products that include digital elements. Its reach is deliberately wide. It covers hardware and software products whose intended or reasonably foreseeable use includes a direct or indirect connection to a device or network.

That can include connected consumer devices, industrial equipment, network products, business applications, operating systems, identity software and components that are marketed separately. Remote data-processing functions may also form part of the product when the product depends on them to perform one of its functions.

There are exclusions and interactions with sector-specific legislation, so scope must be assessed carefully. However, organisations should not assume that the CRA is only an Internet of Things law. Software is clearly part of the regulatory model.

The regulation is also not limited to organisations headquartered in the EU. If a product with digital elements is placed on the Union market, the relevant manufacturer, importer and distributor obligations need to be understood across the supply chain.

Security becomes part of product quality

The CRA changes the question a manufacturer must be able to answer.

The old question was often: Did we find and fix the important vulnerabilities before release?

The new question is broader: Can we demonstrate that cybersecurity risk was managed throughout planning, design, development, production, delivery and maintenance, and that it will continue to be managed for the promised support period?

This brings several disciplines together.

Secure design and secure defaults

Products will need to be designed, developed and produced in accordance with essential cybersecurity requirements. Security should be proportionate to the risks associated with the product, but proportionate does not mean optional.

Manufacturers should expect to justify architectural decisions, exposed functionality, access controls, protection of data and the way products reduce their attack surface. Secure configuration should be the normal starting point rather than an advanced setting that users must discover for themselves.

A documented cybersecurity risk assessment

The risk assessment is not intended to be a document created after engineering has finished. It should inform the product throughout its lifecycle.

A useful assessment connects threats to real product behaviour. What data and functions matter? How is the product connected? Which users or systems trust it? What would happen if an update mechanism, cloud dependency, identity component or third-party library were compromised? Which controls reduce those risks, and what evidence shows that the controls work?

If the assessment cannot influence the product backlog, architecture, test strategy and release decision, it is unlikely to provide much protection.

Vulnerability handling after release

Placing a product on the market will not end the manufacturer’s security responsibility. The CRA expects vulnerabilities to be identified, documented, remediated and communicated during the support period.

That requires more than publishing a security email address. Manufacturers need an intake process, triage criteria, ownership, access to engineering expertise, a method for coordinating fixes and a reliable way to distribute security updates.

They also need to understand the components inside their products. A vulnerability in an upstream library can become a product vulnerability even when the manufacturer’s own code has not changed.

A support period customers can understand

Manufacturers will need to determine a support period during which vulnerabilities are handled effectively. The end date of that period must be communicated clearly to users.

This turns an informal product assumption into a product promise. Commercial, engineering, security and support teams will need to agree how long a product can be maintained, which dependencies must remain supportable and what happens when the product reaches end of support.

An unrealistic support promise creates operational risk. An unreasonably short promise can create customer and market risk. The decision belongs in product governance, not only in legal text.

Evidence, conformity and CE marking

Before relevant products are placed on the market, manufacturers will need technical documentation, an appropriate conformity assessment and an EU declaration of conformity. Compliant products will carry the CE marking.

Most products may be able to use an internal-control route, while important and critical product categories can face more demanding conformity-assessment requirements. The precise route depends on the product and its classification.

For engineering teams, this means that evidence must be produced as part of normal delivery. Risk assessments, test results, vulnerability decisions, component information, update processes and design records cannot be reconstructed reliably at the end of the project.

The deadlines are staged

The CRA entered into force on 10 December 2024, but its requirements do not all start on the same day.

Reporting obligations for actively exploited vulnerabilities and severe security incidents will apply from 11 September 2026.
The main obligations will apply from 11 December 2027.

Those dates can create a false sense of distance. Product lifecycles are long. A product being specified now may still be sold or supported after the main obligations apply. Architecture choices, component contracts and update mechanisms are expensive to change late.

The September 2026 reporting date also arrives before full application. Organisations will need the ability to detect, assess and report certain product-security events while their broader CRA programmes are still being completed.

Waiting until 2027 would therefore miss the first operational deadline and leave too little time to change products already in development.

CRA and NIS2 solve different parts of the problem

The CRA complements the NIS2 Directive, but the two should not be confused.

NIS2 focuses primarily on the cybersecurity risk management and incident-reporting duties of organisations in important and essential sectors. The CRA focuses on the cybersecurity of products with digital elements placed on the market.

An organisation can be affected by both. A manufacturer may have CRA duties for its products while also being subject to NIS2 because of the services it provides or the sector in which it operates. A customer subject to NIS2 may also place stronger security requirements on suppliers whose products support important services.

The practical answer is not to create isolated control environments for each law. Product inventories, asset knowledge, secure development, vulnerability management, supplier assurance, incident response and evidence management can support several obligations when they are designed coherently.

Third-party components are part of the product story

Modern products are assembled from internal code, commercial modules, open-source packages, firmware, cloud services and build infrastructure. The CRA does not make that complexity disappear. It makes it harder to ignore.

Manufacturers integrating third-party components will need to exercise due diligence so that those components do not compromise the cybersecurity of the product. That creates practical questions:

Do we know which components and versions are present in each supported release?
Can we identify affected products quickly when a new vulnerability is disclosed?
Do supplier contracts support vulnerability notification and timely remediation?
Can we replace or isolate a component if its maintainer stops providing support?
Who decides whether an upstream issue creates a reportable product vulnerability?

A software bill of materials can help, but an inventory alone is not a vulnerability-management process. Component data must be connected to product ownership, exposure, exploitability, customer impact and the ability to issue a fix.

Six moves to start now

The implementation detail will continue to develop, including standards and supporting guidance. That is not a reason to wait. Organisations can start with work that will remain valuable under almost any final implementation approach.

Build a product inventory. Identify the hardware, software, components and remote processing solutions made available on the EU market. Record versions, owners, sales channels and expected support periods.
Clarify economic-operator roles. Determine where the organisation acts as manufacturer, importer, distributor, authorised representative or supplier. Contract language does not automatically settle the regulatory role.
Connect security to product governance. Make cybersecurity risk part of product approval, architecture, release and end-of-life decisions.
Strengthen vulnerability operations. Establish intake, triage, coordinated disclosure, patch development, customer communication and escalation processes. Make sure they work for third-party components as well as internal code.
Create evidence during delivery. Record risk decisions, tests, exceptions, approvals and remediation in systems that teams actually use. Evidence should be a by-product of good engineering.
Test the lifecycle. Run a realistic scenario in which an actively exploited vulnerability affects a supported product. Measure how quickly the organisation can identify affected versions, decide on action, create an update and communicate with users.

Do not turn the CRA into a documentation project

The fastest way to create a weak CRA programme is to assign the regulation to a compliance team and ask engineering for evidence at the end.

Compliance matters, but the regulation is aimed at the product. If the update mechanism is unreliable, the component inventory is incomplete or nobody can reach the product owner during a serious incident, better policy language will not solve the operational problem.

The stronger approach is to use the CRA as a product-quality framework. Secure design reduces emergency remediation. A clear support period improves customer expectations. Reliable component data accelerates vulnerability response. Tested update mechanisms reduce the impact of incidents. Traceable decisions make both oversight and engineering better.

The deadlines are important, but they are not the real destination. The real change is that cybersecurity becomes part of what it means to place a trustworthy digital product on the European market.

Sources and further reading

This article provides general technical and operational context, not legal advice.

Continue the series: European National Cyber & Digital Law Series index

The Cyber Resilience Act Is Here: Security Becomes a Product Requirement

The change behind the headline