This page reflects our reading of Cyber Resilience Act, Article 14 and related ENISA guidance as of . It is not legal advice. Review process.
If you're reading this under deadline pressure, start with File an initial Article 14 report instead. This page is for understanding the shape of the obligation, not filing one right now.
The obligation, in three deadlines
From 11 September 2026, if you manufacture a product with digital elements, the CRA requires you to report two kinds of events to your CSIRT and to ENISA, simultaneously, through a single reporting platform (the SRP):
- an actively exploited vulnerability in your product
- a severe incident having an impact on the security of your product
Both follow a staged timeline, but the final stage differs by event type:
| Stage | Vulnerability | Incident |
|---|---|---|
| Early warning | within 24 hours of awareness | within 24 hours of awareness |
| Notification | within 72 hours | within 72 hours |
| Final report | within 14 days of a fix being available | within 1 month |
Sources: Cyber Resilience Act, Article 14, ENISA CRA Single Reporting Platform FAQ — both checked 2026-09-13.
The clock starts at awareness, not at any action you take in Declara. Uploading an SBOM or opening a case doesn't start it, and forgetting to record an early awareness timestamp doesn't stop it.
What Declara automates
- The clock math. Once you record when you became aware, Declara computes each deadline and shows a live countdown per case.
- Matching your inventory to known vulnerabilities. Your SBOM is matched against NVD, OSV, GHSA, KEV, and EPSS feeds continuously.
- Drafting the report packet. The fields each stage requires are assembled from your case and product data into one packet — a page you can read and a PDF you can attach elsewhere.
- A verifiable record. Every action on a case is written to a hash-chained audit log you or an auditor can independently verify.
What stays yours
- Deciding you're obligated at all. Declara's tiering (A/B/C) tells you whether a match looks worth acting on; it is not a legal determination that a vulnerability is "actively exploited" or an incident is "severe." That judgment is the triage step, and it's yours.
- Filing. The SRP has no API today — you copy the generated packet into its own web form yourself. Declara gets you to the form ready; it doesn't submit for you.
- Correcting a mistake. There's no "edit" button for a submitted stage — the mechanism is to carry the correction into the next stage's report, the same way the SRP itself is designed to work. There's no dedicated amendment feature in the product for reopening a submitted stage.
- Everything Declara doesn't know about your product. Dependency depth in your SBOM is a hint about whether a component is one you chose or one you inherited — read from the SBOM's own graph, not proof of reachability.
Why this design, not a fuller-automation one
Declara doesn't submit to the SRP automatically because there isn't an API to submit to today — a platform limitation, not a product choice. Where the product does have a choice — like not silently closing an alert when a VEX statement arrives after you've already opened a case on it — it errs toward a human seeing the change rather than the system deciding quietly. See Why VEX suppresses a match but never an open alert.