CRA 24-hour vulnerability reporting for non-EU manufacturers

The clock in Article 14

Article 14 of the Cyber Resilience Act (Regulation (EU) 2024/2847) has applied since September 11, 2026. It covers two kinds of events, each with three deadlines. The clock starts when the manufacturer becomes aware, not when the investigation is finished.

The early warning names the member states where you know the product has been made available. The 72-hour notification gives general information about the product, the nature of the exploit or incident, the measures you have taken and the measures users can take. The final report describes severity and impact, any information about the malicious actor, and the fix. The CSIRT that receives your report can also ask for intermediate status updates (Article 14(6)).

Separately, Article 14(8) requires you to inform affected users, and where appropriate all users, about the vulnerability or incident and what they can do about it, where appropriate in a structured, machine-readable format.

What counts as "actively exploited"

Article 3 defines an actively exploited vulnerability as one for which there is reliable evidence that a malicious actor has exploited it in a system without the owner's permission. A bug your team found internally, or a researcher's report with no sign of exploitation, goes through your normal vulnerability handling, not Article 14. That judgment call is the hardest part of the 24 hours, so name the person who makes it before you need them.

For incidents, Article 14(5) treats an incident as severe if it affects, or could affect, the product's ability to protect the availability, authenticity, integrity or confidentiality of sensitive or important data or functions, or if it has led or could lead to malicious code being introduced or executed in the product or in users' systems.

Where a non-EU manufacturer reports

Every report goes through ENISA's single reporting platform, which ENISA launched on September 11, 2026. You report once; the notification goes to the CSIRT designated as coordinator and is available to ENISA at the same time. That CSIRT then shares it with the CSIRTs of the other member states where the product is available.

For an EU company, the coordinator is the CSIRT of the member state of its main establishment. If you have no main establishment in the EU, Article 14(7) gives an order, based on the information you have:

1. the member state where your authorised representative is established (the one acting for the largest number of your products);
2. otherwise, where the importer placing the largest number of your products on the market is established;
3. otherwise, where the distributor making the largest number of your products available is established;
4. otherwise, the member state where the largest number of your users are located.

Under the last option, you can keep sending later reports to the same CSIRT you first reported to. Work this out now, write the answer into the runbook, and set up access to the platform before you need it.

Do you need an authorised representative?

No. Article 18(1) says a manufacturer may appoint one by written mandate. It is a choice, not an obligation. If you do appoint one, it decides your coordinator CSIRT under point 1 above, and it can hold your declaration of conformity and technical documentation for market surveillance authorities. It cannot take over your design obligations or your vulnerability handling, which Article 18(2) keeps with you.

Products you already sold count too

For most CRA requirements, products placed on the market before December 11, 2027 are only caught if they are substantially modified afterward (Article 69(2)). Reporting is the exception: Article 69(3) applies Article 14 to all in-scope products placed on the market before that date. An old firmware version still running in the field is covered today.

A 24-hour runbook that survives time zones

For a team in California, Texas, London or Seoul, the practical problem is rarely the platform. It is that the signal arrives at 3 a.m. local time, on a Saturday, to someone who is not allowed to decide. A runbook fixes that by deciding in advance.

1. H+0: intake and timestamp. Any sign of exploitation, from a customer, a researcher, a security advisory or your own monitoring, opens a ticket with a timestamp. That is your defensible start time.
2. H+2: affected versions. With an archived SBOM per release, finding which products and versions ship the vulnerable component takes minutes, not a day of digging through old builds.
3. H+6: qualification. The named decision maker decides whether the evidence shows active exploitation. The decision and the reasons are recorded, including when the answer is no.
4. H+12: draft the early warning. From a pre-filled template: product, versions, nature of the issue, member states where the product is available.
5. Before H+24: submit through the platform to your coordinator CSIRT. Then start on the 72-hour notification and the user advisory.

Two things make the difference in practice: an on-call rotation that includes someone with authority to file, and a timed dry run at least once a year.

The tooling behind it

The two common SBOM formats are CycloneDX, standardized as ECMA-424, and SPDX, standardized as ISO/IEC 5962. Either meets the "commonly used and machine-readable format" wording that Annex I uses for the SBOM that becomes mandatory on December 11, 2027. You don't have to wait until then: the SBOM is what makes the 24-hour deadline realistic now.

# Generate an SBOM for a release image (Syft)
syft ghcr.io/acme/product:2.4.1 -o cyclonedx-json=sbom-2.4.1.cdx.json

# Check it against known vulnerabilities (Grype or Trivy)
grype sbom:./sbom-2.4.1.cdx.json --fail-on high
trivy sbom ./sbom-2.4.1.cdx.json

• Archive per release. Publish the SBOM as a release artifact and keep it as long as the version is in use.
• Monitor continuously. A tool such as OWASP Dependency-Track re-analyzes archived SBOMs whenever new vulnerabilities are published, old versions included.
• Watch exploitation signals. CISA's Known Exploited Vulnerabilities catalog and ENISA's EU Vulnerability Database help spot vulnerabilities reported as exploited. They are signals, not the legal qualification, which stays yours.

What happens if you miss it

Article 64 sets maximum fines that member states apply. Failing the Annex I essential requirements or the obligations of Articles 13 and 14, reporting included, can cost up to EUR 15 million or 2.5% of total worldwide annual turnover for the preceding financial year, whichever is higher. Micro and small enterprises cannot be fined for missing the 24-hour early warning deadline alone (Article 64(10), as corrected in 2025), but they still have to report.

Not sure whether your product is in scope at all? Start with our CRA scope checklist.

Reprisa builds processes, tooling and evidence. It is not a law firm, a notified body or an authorised representative, and this guide is not legal advice.

Frequently asked questions

Sources

Related