24-hour vulnerability reporting (CRA Article 14)

• Regulation (EU) 2024/2847 — Cyber Resilience Act, Article 14
• Directive (EU) 2022/2555 — NIS2, for entities also in its scope
• Regulation (EU) 2016/679 — GDPR Article 33, where personal data is affected

Who has to appoint one

Every manufacturer of a product with digital elements placed on the EU market, from 11 September 2026, regardless of size or sector. The duty sits with the manufacturer, not the importer or distributor, but a manufacturer outside the Union will normally discharge it through its authorised representative or a desk acting on its instructions. Open-source stewards have a lighter, separate reporting duty.

Thresholds and exemptions

No size threshold. What triggers the obligation is factual: a vulnerability in your product that is being actively exploited, or a severe incident having an impact on the security of the product. 'Actively exploited' means there is reliable evidence that someone has executed code or affected the product without authorisation. Suspicion is not the trigger, but the standard is awareness of evidence, not confirmation of the full picture.

What must appear on the label

Not a labelling obligation. What must be published is a single point of contact for reporting vulnerabilities, easy to find on your website, together with a coordinated vulnerability disclosure policy setting out how reports are received, triaged and answered.

Marketplace fields

Not applicable as a marketplace field. It surfaces instead in enterprise procurement and security questionnaires, where buyers now ask for the vulnerability contact point, the disclosure policy and evidence of a reporting process before signing.

Documentation you must hold

An internal handling procedure defining who declares awareness, who drafts, who approves and who files, with a named deputy for out-of-hours. A vulnerability register with timestamps for each stage. The coordinated vulnerability disclosure policy. Evidence of the corrective measure and the date it became available. Records of user notifications, since Article 14 also requires informing affected users about the incident and, where necessary, about corrective measures they should apply.

Standards and testing

Not applicable. What is examined after the fact is the timeline: when the manufacturer became aware, when the early warning was filed, and whether the intervals were met.

Language requirements

Reports are submitted through the single reporting platform, which accepts English. Communications with a national CSIRT may be conducted in the language of that member state, and user notifications should be in the language of the users concerned.

When it applies

Three deadlines, all running from awareness rather than from confirmation. An early warning within 24 hours, saying that an actively exploited vulnerability or severe incident exists, whether other member states are affected, and — even without full detail — enough for the CSIRT to act. A vulnerability or incident notification within 72 hours, with general information about the product, the nature of the exploit and any corrective measures taken or advised. A final report within 14 days of a corrective measure becoming available, or within one month of the 72-hour notification for a severe incident, describing the vulnerability, its severity, the exploitation and the fix.

How long records are kept

The vulnerability register, the notifications filed and their timestamps, for the duration of the support period at minimum. This is the evidence that decides an enforcement case, because the question will be when you knew.

What happens if you do not comply

Up to €15 million or 2.5% of total worldwide annual turnover for breach of the manufacturer's obligations, which include Article 14. The exposure is unusual in that it does not depend on the vulnerability itself being your fault: a dependency you did not write, exploited in the wild, still starts the 24-hour clock. Authorities can also order the product withdrawn while the issue is unresolved.

Who enforces it

The CSIRT designated as coordinator in the member state of your main establishment, or where you have none in the Union, the one designated for your authorised representative. ENISA receives the notifications in parallel through the single reporting platform. Market surveillance authorities enforce.

Where the boundary lies

This obligation bites more than a year before the rest of the CRA, and that gap is what most manufacturers miss. It sits alongside NIS2 reporting, which has similar deadlines but a different trigger — an incident affecting your service as an entity, rather than a vulnerability in a product you sell — and alongside GDPR Article 33 breach notification where personal data is involved. One event can require all three, to three different authorities, on three different legal bases.

Questions we are asked

Who decides whether a vulnerability is actively exploited?

You do, on the evidence you have. The safe course is to file the early warning and refine it in the 72-hour notification. Filing late because you were still confirming is the failure mode authorities have signalled they will not accept.

What if we learn about it from a researcher on a Saturday?

The clock runs from awareness, not from the next business day. That is why the procedure needs a named deputy and an out-of-hours route: the 24 hours are calendar hours.

Does reporting expose us to liability?

The reports go to CSIRTs and ENISA, not to the public, and the Regulation restricts their use. What creates exposure is not reporting: an unreported exploited vulnerability that later becomes public is both an infringement and evidence of it.

We use a third-party component with the flaw — is it still our report?

Yes, if the product you placed on the market is affected. You may also need to notify the component's maintainer, but that does not discharge your own duty.