> Markdown version of https://docs.laavat.io/cra-compliance/article-14-reporting/ from the LAAVAT PKI and Signing Platform documentation. All pages: https://docs.laavat.io/llms.txt

# Article 14: The September 2026 Reporting Deadline

> **Note: Your compliance responsibility**
> This is 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, and reporting is
> your obligation as the manufacturer — confirm the current requirements with your compliance function or
> 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](https://docs.laavat.io/cra-compliance/annex-i-mapping/) 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](https://docs.laavat.io/cra-compliance/secure-boot-cra/), 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.

## Related

- [Annex I mapping](https://docs.laavat.io/cra-compliance/annex-i-mapping/) — the update and integrity requirements the remediation relies on
- [Secure boot and CRA](https://docs.laavat.io/cra-compliance/secure-boot-cra/) — how devices verify that a delivered update is genuine
- [Scope, classification & penalties](https://docs.laavat.io/cra-compliance/scope-and-classification/) — Article 14 sits in the highest penalty tier