Cyber Resilience Act: reporting an exploited vulnerability within 24 hours

Since 11 September 2026, the Cyber Resilience Act has required actively exploited vulnerabilities and severe incidents to be reported within 24 hours, through an ENISA platform. Software vendor, agency or IT services company: you may be delivering a “product with digital elements” without knowing it. This guide helps you assess your situation, prepare your SBOM and build a reliable reporting process.

What has applied since 11 September 2026

Regulation (EU) 2024/2847, known as the Cyber Resilience Act (CRA), published on 20 November 2024 [1], sets cybersecurity requirements for “products with digital elements”: connected devices, but also software that is sold, distributed or monetised.

The CRA timeline in one table

In France, ANSSI is the notifying authority, CERT-FR centralises reports and market surveillance falls to the Agence nationale des fréquences (ANFR) [7].

Products already on the market are also covered

A product placed on the market before 11 December 2027 is in principle subject to the CRA only if it undergoes a “substantial modification”. But Article 69(3) makes an exception: Article 14 applies to all products within the scope of the regulation, including those already on sale [1]. An application published in 2022 and still distributed is therefore covered.

Vulnerability reporting: the Cyber Resilience Act deadlines

Actively exploited vulnerability, severe incident: the definitions

Two notions trigger the obligation, not every CVE in your dependencies:

• Actively exploited vulnerability: “a vulnerability for which there is reliable evidence that a malicious actor has exploited it in a system without permission of the system owner” (Art. 3) [1]. A critical CVE that is not exploited does not qualify; an in-house flaw exploited at a customer’s site does.
• Severe incident (Art. 14(5)): an incident that negatively affects, or is capable of negatively affecting, the product’s ability to protect the availability, authenticity, integrity or confidentiality of sensitive or important data or functions, or that has led, or is capable of leading, to the introduction or execution of malicious code in a user’s system. The compromise of your build chain or your update server is the typical example.

24 hours, 72 hours, 14 days, one month: the deadlines table

The clock starts at awareness, not at the end of your analysis. The CSIRT may also request an intermediate report (Art. 14(6)).

Where notifications go: the ENISA platform and CERT-FR

All notifications go through the ENISA Single Reporting Platform, operational since 11 September 2026 [2][3]. You submit a single notification, addressed to the coordinating CSIRT of the Member State of your main establishment (where product cybersecurity decisions are taken) and made available to ENISA at the same time (Art. 14(7)). For France, ENISA lists CERT-FR [5].

According to ENISA [4], access requires an EU Login account with multi-factor authentication, and it is advisable to register as a manufacturer only when a notification becomes necessary.

Inform your users too

Article 14(8) requires you to inform the affected users and tell them about mitigation measures, “where appropriate in a structured, machine-readable format”. Prepare a security advisory template and a distribution channel.

Are you a “manufacturer” under the CRA?

The definition that matters

A manufacturer is a person who “develops or manufactures products with digital elements or has products with digital elements designed, developed or manufactured, and markets them under its name or trademark, whether for payment, monetisation or free of charge” (Art. 3) [1]. Being free of charge therefore does not exclude the CRA if the product is monetised in another way (recital 15), and anyone who has software developed and then markets it under their own brand is a manufacturer.

SaaS vendor: NIS 2 first, CRA if your cloud makes a product work

According to recital 12, SaaS, PaaS and IaaS fall under the NIS 2 Directive, not the CRA. But a “remote data processing” solution designed by the manufacturer and without which the product could not perform one of its functions is part of the product [1]: the API that drives a mobile application or a connected device that you distribute, for example. The European Commission guidelines of 27 July 2026 (C(2026) 5252) detail this test [6].

Agency or IT services company delivering software: who bears the obligation?

Here is the reading grid we apply, to be confirmed case by case with your legal adviser:

If in doubt, a targeted audit and consulting engagement can inventory the products concerned.

Open source: commercial activity, stewards and components

The CRA covers free and open-source software only when it is supplied in the course of a commercial activity: supplying non-monetised open-source software is not one, and contributing to or funding a project is not enough to make it one (recital 18) [1]. Open-source software stewards have a lighter regime (Art. 24); the Commission indicates that their reporting obligations apply from 11 December 2027 [2], and they are not liable to fines (Art. 64(10)).

If you integrate open source, two obligations matter: due diligence on third-party components (Art. 13(5)) and reporting to the maintainer any vulnerability you discover, sharing the fix if you wrote it (Art. 13(6)).

SBOM and vulnerability management: what Annex I requires

Although due on 11 December 2027, these requirements already determine your ability to report on time.

The eight requirements of Part II

Annex I, Part II, asks manufacturers [1] for:

• a software bill of materials (SBOM) “in a commonly used and machine-readable format covering at the very least the top-level dependencies”;
• fixes without delay, with security updates separate from functional changes where possible;
• regular security testing;
• publication, with each fix, of the description and severity of the flaws fixed;
• a coordinated vulnerability disclosure policy;
• a contact address for reporting a vulnerability;
• secure distribution of updates;
• distribution of fixes without delay and, unless otherwise agreed for a bespoke product, free of charge.

Points 3 and 7 are handled in the test chain: this is the role of a quality assurance and testing approach built into the pipeline, rather than an isolated annual penetration test.

Producing an SBOM and scanning on every build

The CRA does not mandate a format; CycloneDX and SPDX are the most widespread. Example commands to plug into a GitLab or GitHub CI:

# Dépendances PHP (Symfony, Laravel, PrestaShop…) : vulnérabilités connues
composer audit --locked

# Dépendances Node.js : audit + SBOM CycloneDX
npm audit --omit=dev
npm sbom --sbom-format cyclonedx > sbom-npm.cdx.json

# Image Docker complète (OS + runtime + application)
syft registry.example.com/app:1.4.2 -o cyclonedx-json > sbom-image.cdx.json
grype sbom:./sbom-image.cdx.json --fail-on high

Archive the SBOM with every version delivered: on the day of an exploitation, the question is “what is running at each customer?”.

A support period of at least five years

Article 13(8) requires a support period of at least five years, unless the expected use time is shorter [1]; its end date will have to be stated at the point of purchase (Art. 13(19)).

The “24-hour” runbook: organise reporting before the first incident

Only the deadlines of 24 hours, 72 hours, 14 days and one month are regulatory; the 4-hour milestone is a recommendation.

Preparation checklist:

• [ ] List of the products concerned, versions distributed and countries where they are made available
• [ ] SBOM archived for every version delivered
• [ ] Two designated representatives, EU Login accounts with MFA tested
• [ ] On-call cover for weekends and public holidays (24 calendar hours)
• [ ] Public reporting address (security.txt file) and disclosure policy
• [ ] Pre-filled templates: early warning, notification, user advisories
• [ ] Dry-run exercise at least once a year

What the CRA changes for TMA and DevOps

TMA contracts: the clauses to review

Detection often takes place at the service provider. A CRA-compatible application maintenance (TMA) contract should specify:

• the internal deadline, in hours, for escalating a suspected exploitation;
• who keeps the SBOM for each version;
• delivery of security fixes separate from feature changes;
• the provider’s contribution to the 72-hour and final reports;
• log retention and confidentiality of exchanges, as we describe on our Your data security page.

For the general framework of such a contract (scope, service levels, reversibility), see our guide Outsourcing application maintenance: criteria, risks and steps.

DevOps pipeline: from monitoring to the separate fix

In practice: an SBOM attached to every artefact, automated monitoring (CVEs, CERT-FR advisories) cross-checked against the SBOMs, maintenance branches to ship a fix without the next feature, signed artefacts, access logging. This infrastructure, DevOps and web security work plugs into an existing pipeline (GitLab CI, GitHub Actions, Jenkins).

Penalties: what Article 64 provides for

Under Article 64(10) [1][8], micro and small enterprises are not penalised for the sole fact of missing the 24-hour deadline, and open-source software stewards are exempt from fines. The obligation to report remains.

Frequently asked questions

Prepare your CRA process before the first incident

Since 11 September 2026, the Cyber Resilience Act above all requires you to know how to react quickly. Three workstreams are a priority: determining your manufacturer status product by product, keeping an SBOM for each version delivered, and formalising a runbook with people authorised on the ENISA platform.

At iones, we support agencies, IT services companies and software vendors on these three areas, on a white-label basis if needed: inventory and assessment with our audit and consulting offer, SBOM and monitoring built into the pipeline, fixes delivered as part of TMA. Want to review your exposure? Contact us: reply within 48 to 72 hours, no-commitment discussion, under NDA.