Your SECURITY.md fails 17 of 18 Article 14 checks

Five lines in this SECURITY.md fail EU Cyber Resilience Act Article 14 — for maintainers and compliance leads at vendors selling into the EU, this is what the linter prints:

line  6 [warn]  response_window_in_days  "acknowledge your report within 5 business days"
        A response window in days sits beside an obligation in hours.   Art. 14(1)
line 10 [error] wrong_start_date_2027    "reporting obligations start in December 2027"
        Wrong start date. The reporting obligation already applies.     Art. 71(2)
line 11 [error] wrong_recipient          "we will notify the supervisory authority"
        Wrong recipient on the Article 14 path.                         Art. 14(1)
line 13 [error] gdpr_clock_confusion     "the GDPR already gives us 72 hours"
        Two different 72-hour clocks treated as one.        Art. 14 vs GDPR Art. 33
line 17 [error] support_period_lapsed    "supported until 2026-06-30"
        Declared support period already ended, today 2026-09-11.        Art. 13(8)

That file ships with the extension; those five lines are five of its findings. The full run reports 17 findings against 18 checks: a sixth also lands on a line — support_period_under_five_years at line 18, declared end 2027-03-31 against five years from today, 2031-09-11 — and the remaining eleven are things the file never says at all: no ENISA, no CSIRT, no reporting platform, neither trigger, no SBOM, no contact address.

The date is the part people get wrong. The Cyber Resilience Act is widely filed under "December 2027". That is true of most of it, not of the reporting obligation. From 11 September 2026, a manufacturer who becomes aware of an *actively exploited vulnerability*, or of a *severe incident* affecting a product's security, owes three filings on a clock in hours — and it applies to products already on the market:

• 24 hours from awareness: an early warning. (Art. 14(1)(a))
• 72 hours from awareness: a notification with severity, impact and any corrective measure applied. (Art. 14(1)(b))
• 14 days after a corrective measure is available: the final report. For a severe incident, one month after the notification. (Art. 14(2)(c))

They go to ENISA and to the CSIRT designated as coordinator for your main establishment in the Union, through the single reporting platform (Art. 16).

The GDPR confusion is the expensive one. Article 33 also says 72 hours, so it feels 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 once. Send an actively exploited vulnerability to a data protection supervisory authority and you have notified the wrong body, while the ENISA report is already late.

The support line is arithmetic, not interpretation: Article 13(8) expects a declared support period, and supported until 2026-06-30 in a release still installed is a disclosure that the product is unsupported.

I wrote CRA 24/72/14 Reporting Lint, a VS Code extension, to check this one document: 18 rules, entirely offline, on the Markdown file you have open — the clock, the recipients, the triggers, the contact point, the disclosure policy, the SBOM and the support period. Every finding names its article and the fix. The free web version runs the same engine file: https://getreadystack.com/t/cra-24-72-14-reporting-lint/

It is a document linter, not a legal opinion or a conformity assessment; open-source stewards carry a lighter duty under Article 24. Regulation (EU) 2024/2847, Articles 13, 14 and 16; Annex I Part II; Annex II.

Checking the open file is free, all 18 rules, nothing withheld — fixing one document finishes there. The licence widens the scope: every Markdown file in the workspace in one pass, which checks are answered nowhere in the repo, and one dated readiness report. One hour of EU product-compliance consulting runs $150-250; the licence is $49 once.