Compliance4 min read

Cyber Resilience Act: what software makers must do now that reporting applies

Cyber Resilience Act: since 11 Sep 2026, manufacturers must report exploited vulnerabilities within 24 hours. Who is affected and what to prepare now.

What applies since 11 September 2026

The Cyber Resilience Act (Regulation (EU) 2024/2847) has been in force since December 2024. Since 11 September 2026, the first part that directly affects manufacturers applies: the reporting obligations of Article 14. Manufacturers must report actively exploited vulnerabilities and severe incidents affecting their products.

Important: the reporting obligation also covers products placed on the market before that date. The remaining obligations, such as security by design, security updates for the whole support period, conformity assessment and CE marking, follow on 11 December 2027.

  1. In force
  2. Reporting
  3. All obligations
The Cyber Resilience Act timeline. Reporting applies since September 2026, all other obligations from December 2027.

Who is affected

The CRA applies to products with digital elements offered in the EU: software and hardware that can connect to a device or network. That includes desktop and mobile apps, installable business software, firmware and connected devices.

  • Manufacturers carry the main obligations, even if they are based outside the EU.
  • Importers and distributors must check that the manufacturer meets its obligations.
  • Pure SaaS services do not fall under the CRA. Whether NIS2 applies to you depends on your sector and company size. The CRA does apply when the cloud is part of how a product works, for example the back end of an app or a device.
  • Open source without commercial activity is excluded. Organisations that steward open-source projects over time face a lighter regime.

If in doubt, a short legal assessment is worth it. If you sell installable software, apps or connected devices, you are almost certainly affected.

The reporting chain: 24 hours, 72 hours, 14 days

  1. 24 hEarly warning
  2. 72 hNotification
  3. 14 daysFinal report
Reporting chain for an actively exploited vulnerability under Article 14 CRA. For severe incidents, the final report is due after one month.

As soon as you become aware of an actively exploited vulnerability, the clock starts:

  1. Early warning within 24 hours: that the vulnerability exists and in which member states your product is available.
  2. Notification within 72 hours: details on the product, the nature of the exploitation and the measures taken or recommended.
  3. Final report no later than 14 days after a fix or mitigation is available: severity, impact, root cause and remediation.

Severe incidents follow the same 24 and 72 hours; the final report is due one month after the notification. Reports go through ENISA’s single reporting platform, simultaneously to ENISA and to the coordinating CSIRT of the member state of your main establishment: in Germany the BSI, in France CERT-FR at ANSSI. Where appropriate, you must also inform affected users.

Why this is a code topic

24 hours is short. To meet it, you have to answer three questions quickly:

  • Which components, in which version, are in your product? Without an up-to-date bill of materials (SBOM), you will not know whether the next Log4j-style flaw affects you.
  • Where in the code is the problem? Teams that know their code can assess severity and impact instead of guessing.
  • How fast can you ship? A fix only helps once it reaches your users.

Often it is not an exotic zero-day but a known flaw in a dependency that could have been updated long ago. More and more of these dependencies enter projects through AI assistants, see Vibe coding: how secure is AI-generated code?

Checklist for the next 30 days

  1. Clarify scope: which products fall under the CRA, and what is your role?
  2. Assign responsibility: who reports, who covers, who is reachable at weekends?
  3. Automate the SBOM: generate a bill of materials in CycloneDX or SPDX format with every release.
  4. Scan dependencies continuously: against CVE and OSV databases, with alerts on new matches.
  5. Open a reporting channel: a security.txt file and a coordinated vulnerability disclosure policy.
  6. Rehearse: prepare a template for the 24-hour early warning and run through it once.
  7. Take stock: where do you stand today? A code audit reveals known flaws, outdated packages and secrets before they are exploited and become reportable.

What non-compliance costs

For breaches of the essential requirements and the obligations in Articles 13 and 14, the CRA provides for fines of up to €15 million or 2.5% of worldwide annual turnover, whichever is higher. Products can also be withdrawn from the market. Micro and small enterprises are exempt from fines for a late 24-hour early warning, but they still have to report.

This article is an overview, not legal advice.

How a code audit helps

Our code audit checks your dependencies against known vulnerabilities, searches code and history for secrets, and reviews the code along the OWASP Top 10:2025. Every finding comes with a CVSS score and an action plan. The report documents your current state for customers and authorities. Fixed price €890 net, delivered in 2 business days.

The report does not replace a conformity assessment or CE marking. It does show you where to start. How we work is explained in our methodology.


This article was created with the help of automated research and AI. David Kreutzer reviewed it and approved it on 1 November 2026.

About the author

Managing Director, Viewconic GmbH

Leads the security and code audits at Viewconic and reviews every article on this blog before it is published.

Profile and all articles →

Related to this topic

How secure is your code?

The security check shows, usually within 2 hours on working days, what attackers see. Free and without access.