Five lines in the average SECURITY.md now fail EU Cyber Resilience Act Article 14 — and for any maintainer shipping software into the Union, 11 September 2026 was the day that stopped being theoretical.
That date is the one people get wrong. The Cyber Resilience Act is usually filed under "December 2027", and that is true of most of it. It is not true of the reporting obligation. From 11 September 2026, a manufacturer who becomes aware of an actively exploited vulnerability in their product, or of a severe incident affecting its security, owes three filings on a clock measured in hours — and it applies to products that were already on the market.
- 24 hours from awareness: an early warning.
- 72 hours from awareness: a notification, with severity, impact and any corrective measure already applied.
- 14 days after a corrective measure is available: the final report. (For a severe incident, one month after the notification.)
They go to ENISA and to the CSIRT designated as coordinator for your main establishment in the Union, filed through the single reporting platform.
Now open your own SECURITY.md. Most of them were written years before this existed, and they fail in the same five places:
line 10 [error] wrong_start_date_2027
Wrong start date. The reporting obligation already applies;
December 2027 is when the remaining obligations follow.
fix: Correct the date to 11 September 2026 for reporting. (CRA Art. 71(2))
line 11 [error] wrong_recipient
Wrong recipient on the Article 14 path. This report does not go there.
fix: Route the report to the coordinating CSIRT and ENISA. (CRA Art. 14(1))
line 13 [error] gdpr_clock_confusion
Two different 72-hour clocks are being treated as one.
fix: Split the runbook into two paths. (CRA Art. 14 vs GDPR Art. 33)
The GDPR confusion is the expensive one. Article 33 of the GDPR also says 72 hours, which makes it feel like the same obligation with the same runbook. It is not. Different trigger, different recipient, different content — and one incident can start both clocks at the same moment. A runbook that routes an actively exploited vulnerability to a data protection supervisory authority has notified the wrong body and still owes ENISA a report that is now late.
The fourth failure is quieter: a response window measured in days sitting next to an obligation measured in hours. "We acknowledge reports within 5 business days" is a perfectly good disclosure promise, but a reader — including the on-call engineer at 3am — will take the slower number as the operative one. Keep the promise, state the 24/72/14 clock separately, and say which governs.
The fifth is arithmetic. Article 13(8) expects a declared support period, and plenty of repositories still carry supported until 2026-06-30 in a release that is very much still installed. A date that has already passed is not a support period; it is a disclosure that the product is unsupported.
I wrote CRA 24/72/14 Reporting Lint, a VS Code extension, to check exactly this. Eighteen rules, run entirely offline, reading the Markdown file you have open: the three clock steps, the recipients, the two triggers, the single point of contact, the coordinated disclosure policy, the SBOM reference, the support period end date and whether it has lapsed or falls short of five years. Every finding names the article it comes from and the line to write instead.
There is a free web version of the same engine — literally the same file, inlined into the page — so you can paste a policy and see the findings without installing anything: https://getreadystack.com/t/cra-24-72-14-reporting-lint/
The limits are worth stating plainly. This is a linter for a document, not a legal opinion and not a conformity assessment. It will tell you that your runbook never names a CSIRT. It cannot tell you whether your product is in scope, which class it falls into, or whether a given vulnerability is being actively exploited. Open-source stewards carry a lighter duty under Article 24, and the rules here flag the manufacturer path.
But the mechanical errors — the wrong date, the wrong recipient, the borrowed GDPR runbook, the lapsed support period — are the ones a reviewer finds in the first five minutes, and they are the ones you can fix this afternoon.
Regulation (EU) 2024/2847, Articles 13, 14 and 16; Annex I Part II; Annex II.
Free in your browser (the same rules): https://getreadystack.com/tools/cra-24-72-14-reporting-lint
Licence ($29, once, 7-day refund): https://buy.polar.sh/polar_cl_zmN08yKAf6Qz5WMiSQO9V9MxIRQN87VQEfurn03M3KT
Top comments (0)