EU Cyber Resilience Act: what applies now and how to prepare for 2027

Check the product and your role first

The CRA covers hardware and software made available on the EU market whose intended or reasonably foreseeable use involves a direct or indirect data connection to a device or network. It can cover separately supplied components and remote processing needed for a product function. A software developer can be a manufacturer: check who develops the product, or has it developed, and markets it under their name or trademark.

Check exclusions before assigning duties. Free and open-source software supplied outside a commercial activity is excluded, and some sector-regulated products, including medical devices, have specific exclusions. Importers, distributors and open-source software stewards have distinct roles. This checklist focuses on manufacturers.

Reporting duties already apply

Assess two triggers separately: an actively exploited vulnerability in your product, and a severe incident affecting its security. Finding a flaw does not by itself establish active exploitation; reliable evidence of malicious exploitation is needed. An incident can independently trigger reporting. Use the severity criteria in Article 14(5).

Report through ENISA’s Single Reporting Platform to the designated coordinating CSIRT and ENISA. Set up the appropriate representatives and reporting route before an incident. The platform provides registration guidance and a user manual.

Act without undue delay. The reporting sequence has different deadlines:

• Within 24 hours of awareness: submit the early warning. Do not wait for a complete investigation.
• Within 72 hours of awareness: provide the vulnerability or incident notification with the available details and corrective or mitigating measures, unless that information was already supplied.
• Final report: for an actively exploited vulnerability, no later than 14 days after a corrective or mitigating measure becomes available; for a severe incident, within one month after the incident notification. These are different clocks.

Include existing products in your reporting review

Article 69(3) extends the reporting duties to covered products placed on the market before 11 December 2027. Include older releases in your assessment. Manufacturers must also inform impacted users, and where appropriate all users, about the vulnerability or incident and necessary protective measures.

This does not bring every 2027 requirement forward. Earlier products generally become subject to the broader requirements if substantially modified from 11 December 2027. New units placed on the market from that date need their own assessment even if the model was launched earlier. Open-source software stewards’ Article 24(3) reporting duties also start on 11 December 2027.

Prepare your products for December 2027

For covered releases, turn the CRA requirements into a product-level work plan. Start with one representative product and assign an owner to each gap.

1. Review security risks and design. Map the product, its components and supporting remote processing. Assess cybersecurity risks and check the applicable Annex I requirements, including secure defaults, access controls and secure updates.
2. Prepare vulnerability handling. Document components and vulnerabilities, including a machine-readable software bill of materials covering at least top-level dependencies. Establish a disclosure contact, remediation process and secure update delivery.
3. Set a defensible support period. Consider expected use and reasonable user expectations. Five years is the usual minimum, not an automatic limit; a shorter period is allowed where expected use is shorter. Record your reasoning and communicate the support end date.
4. Confirm the conformity route. Check whether the product is in a default, important or critical category, including the technical descriptions in Implementing Regulation (EU) 2025/2392. Many products allow self-assessment; others require a notified body, subject to the applicable conditions and exceptions.
5. Assemble the release evidence. Bring together the risk assessment, technical documentation, verification results, user instructions and support information. Complete the applicable conformity assessment before drawing up the EU declaration of conformity and affixing the CE marking.

Give the first review a concrete outcome

Pick one product and record its scope decision, reporting owner, support assumptions and conformity route. Rehearse how a credible vulnerability report reaches the responsible team and how the reporting deadlines are tracked. Keep the evidence and unresolved questions together so the next release review has a clear starting point.

Plan your CRA review with Regunow

Use Regunow to investigate CRA scope, reporting and product requirements, examine the source provisions, and analyze your documentation. Bring the findings into a report for your team’s review.