Skip to content

Article 14: The September 2026 Reporting Deadline

Draft — needs compliance review before external use

A technical explainer of the reporting timeline, not legal advice. The precise notification triggers, formats, and single-reporting-platform mechanics are set by the CRA and its implementing acts — confirm the current requirements with counsel before building your process around this page.

Most of the CRA's essential requirements apply from 11 December 2027. Article 14's reporting obligations come earlier — 11 September 2026 — and they apply to products already on the EU market, not just new launches. If you ship connected devices today, this is the CRA deadline that reaches you first.

What Article 14 requires

Article 14 obliges manufacturers to notify — through the single reporting platform coordinated by ENISA — about two kinds of events affecting their products:

  • Actively exploited vulnerabilities in the product.
  • Severe incidents having an impact on the security of the product.

The notifications are staged, and the timelines are short:

Stage Deadline (from awareness) Content
Early warning 24 hours That an actively exploited vulnerability or severe incident exists; initial known facts
Vulnerability/incident notification 72 hours The details as understood — nature, and any corrective or mitigating measures taken or available
Final report 14 days (vulnerability) / 1 month (incident) Full description, root cause, remediation, and measures applied

"Awareness" starts the clock. A 24-hour early-warning window means you need a process that can recognize an actively exploited vulnerability and file quickly — not a quarterly review cadence.

The remediation half of the obligation

The reporting obligation doesn't stand alone. The 72-hour notification asks what corrective or mitigating measures are available, and the final report asks how it was remediated. That presumes you can remediate — that a fix can be produced and delivered to affected devices in the field.

For an embedded product, "delivered to affected devices" means a firmware or software update the device will accept and install. And a device should only accept an update it can verify is genuinely from you — otherwise the update channel is itself the vulnerability. This is where the reporting obligation and the Annex I update requirements meet: the report describes a remediation that the signed update path is what actually delivers.

A manufacturer who can file the report but has no trustworthy way to ship the fix has satisfied the paperwork and not the point. A manufacturer with an HSM-backed signed update path can point, in the final report, to a concrete remediation that reached devices securely.

What to have in place before September 2026

At a process level:

  • A defined awareness-to-notification workflow that can hit the 24-hour early-warning window — who decides, who files, on which platform.
  • A coordinated vulnerability disclosure channel so you learn about issues in the first place (also an Annex I Part II requirement).
  • The ability to produce and ship a verified fix — the remediation your reports will reference.

That last point is the one LAAVAT underpins. If your update artifacts are signed with keys you control in an HSM, and your devices verify those signatures via secure boot, then when an actively-exploited vulnerability forces a 24-hour clock, the remediation path already exists and is trustworthy. You're reporting a fix you can actually deliver.