Cyber Resilience Act: what changes, and how to prepare.

What is the Cyber Resilience Act?

The Cyber Resilience Act, or CRA, is Regulation (EU) 2024/2847. It sets EU rules for the security of hardware and software products with digital elements. A product should be designed securely, supported with security fixes and supplied with information that helps people use it safely.

Who needs to look at it?

Start with products supplied commercially in the EU whose intended or reasonably foreseeable use involves a direct or indirect data connection to a device or network. A software publisher or a business selling a device under its own brand may be the manufacturer. Importers and distributors have their own duties.

Scope needs a product-specific check. Non-commercial free and open-source software and products covered by certain sector rules, such as medical device legislation, have exclusions. Cloud services are not automatically all covered or all excluded: some remote processing is part of a covered product.

What does the wider regulation cover?

• Product risk assessment and security built into design, development and delivery.
• A process for receiving, investigating and fixing vulnerabilities during the product’s support period.
• Component records, including a software bill of materials (SBOM), and secure delivery of updates.
• Technical documentation, user instructions and information about the support period.
• The applicable conformity assessment, EU declaration of conformity and CE marking. The assessment route depends on the product.
• Reporting, supply-chain responsibilities and supervision by market surveillance authorities.

Overview: CRA legal text, Articles 2, 13–24, 27–34 and Annex I.

Why prepare before 2027?

These tasks affect product releases, supplier information and the way support works. They take time to establish and test. Start by identifying the products, the people responsible for them and the records you already have. Then agree the missing work and who will carry it out.

Two dates to plan around

1. 11 September 2026

   Manufacturer reporting starts

   Article 14 reporting obligations apply. Covered products already on the EU market can also be affected.

2. 11 December 2027

   Main CRA requirements apply

   Product security, documentation and conformity obligations become applicable. Earlier products have transitional rules; substantial modifications can change their position.

Article 71 sets the dates and Article 69 the transition. Open-source software stewards have distinct Article 24 reporting duties applying from 11 December 2027. Read the regulation.

Article 14: what must be reported?

Manufacturers must report actively exploited vulnerabilities and severe incidents affecting the security of their covered products. An actively exploited vulnerability has reliable evidence of malicious exploitation without permission. A scanner finding alone does not establish that condition.

Article 14 also defines the severe-incident threshold, including actual or potential harm to the product’s protection of sensitive or important data or functions, or the introduction or execution of malicious code in the product or a user’s systems.

Manufacturers must also inform affected users about the vulnerability or incident and appropriate measures without undue delay, as required by Article 14(8).

See Article 14 and the Commission’s reporting explanation. This is a practical summary, not a determination that a particular event meets the reporting threshold.

Where does the notification go?

The ENISA Single Reporting Platform (SRP), established under Article 16, is the submission route. It routes notifications to the relevant national computer security incident response team (CSIRT) and ENISA. The platform has its own registration and access roles.

ENISA platform access, registration guidance and user manual ↗

What WFH can help you prepare

We agree the product scope and the type of help you need: readiness work, reporting preparation or support with a specific event. A proposal can include:

• A product and responsibility map: who owns each product, collects technical facts, approves a notification and submits it.
• A technical gap list covering product security, component records, vulnerability handling and release evidence.
• A reporting procedure and draft information templates for the early warning, notification and follow-up stages.
• A practice scenario to check whether your team can gather information and reach the right people in time.
• Help preparing the technical information for SRP and recording what was submitted and what needs updating.
• Implementation or coordination of agreed fixes, with evidence of the checks performed.

SBOM and VEX explained

An SBOM is a list of software components in a product. It helps answer “Do we use the affected library, and in which versions?” CRA Annex I includes an SBOM requirement as part of vulnerability handling.

VEX records whether a known vulnerability affects a particular product, with the reasoning behind that conclusion. It can help organise technical evidence. It is not itself a CRA certificate or a replacement for reporting.

Keep component records linked to the product version they describe. When a vulnerability is reported, check whether the component is present, whether the affected function can be reached and which configurations are exposed. Assign someone to review the conclusion when the product changes.

Before you get in touch