CRA Reporting Copilot / Guides

The CRA Article 14 vulnerability report: what to file, and when the clocks really start

July 2026 · 6 min read

Of the two reporting paths the Cyber Resilience Act opens on 11 September 2026, the vulnerability path is the one whose final deadline is most often calendared wrong. This is a walkthrough of the actively-exploited-vulnerability route under Article 14 of Regulation (EU) 2024/2847: what triggers it, what each stage contains, and the one start point that behaves differently from everything else in the regulation.

What triggers the duty

Art. 14(1) obliges a manufacturer to notify an actively exploited vulnerability contained in a product with digital elements placed on the EU market. "Actively exploited" is a defined term (Art. 3): the essence is that there is reliable evidence of exploitation against a system by a malicious actor — a live-fire situation, not a theoretical CVSS score. A critical vulnerability with no observed exploitation does not, by itself, trip Art. 14(1); the moment exploitation is observed, the staged timeline opens.

Two scope notes that surprise teams. First, the duty reaches legacy products: by way of derogation, the Article 14 reporting obligation applies to products already on the market before the regulation's full application on 11 December 2027 (Art. 69(3)) — the "substantial modification" condition belongs to the substantive requirements (Art. 69(2)), a different paragraph that is constantly conflated with it. Second, exploitation of a vulnerability in an integrated third-party component, open source included, brings its own duty: Art. 13(6) requires reporting the vulnerability to the person or entity that makes or maintains the component.

The three stages on the vulnerability path

The pending clock: the part tooling gets wrong

The final report on this path is anchored to an event that may not have happened yet when you file the 72-hour notification: the availability of a corrective or mitigating measure. Until a fix or mitigation exists, the 14-day clock has not started. Modeled correctly, your deadline tracker should show this stage as awaiting its start point — not as a date. Two common failure modes follow from modeling it wrong:

• Counting from awareness. "Final report due 14 days after we found out" is simply not what Art. 14(2)(c) says, and it manufactures either a fake emergency (fix ships late) or a missed real deadline (fix ships fast and nobody restarts the count).
• Forgetting to arm the clock. The fix ships, engineering celebrates, and nobody records that a regulatory countdown just began. The trigger event — measure availability — must be captured with the same discipline as the awareness time.

Note the contrast with the severe-incident path, where the final report is due one month after the 72-hour notification is submitted (Art. 14(4)(c)). Two paths, two different anchoring events, neither of them "awareness."

The two notices that ride along

Alongside the authority reports, Art. 14(8) requires informing impacted users of the vulnerability — and where relevant, of risk-mitigating or corrective measures they can apply. The provision has teeth: where the manufacturer fails to inform users, the coordinating CSIRT may do so directly if it considers that proportionate and necessary. A plain-language user advisory should therefore be drafted alongside the 72-hour notification, not after the dust settles. The upstream notice under Art. 13(6) completes the set when a third-party component is involved.

Preparing before September

1. Write the two final-report start points into your runbook as two separate lines.
2. Decide who confirms the awareness time. Its interpretation in edge cases depends on official guidance — record the basis for your call.
3. Instrument your tickets to capture the trigger events: exploitation evidence, measure-availability date.
4. Draft skeletons for all five documents now, so the 24-hour window is a fill-in exercise.
5. Run one tabletop rehearsal of the whole flow.