Reports & deadlines

From 11 Sep 2026, CRA Article 14 requires manufacturers to report actively exploited vulnerabilities and severe incidents via ENISA’s Single Reporting Platform (SRP). Resilic tracks the deadlines, drafts the content, and enforces that a human signs — it never files anything for you.

Declaring a reportable event — you own the clock

A reportable event is declared by a person, never auto-created. An exploited match from correlation surfaces a candidate; you promote it (pre-filled with the CVE and affected versions) and confirm or adjust the awareness time — the legally load-bearing timestamp that anchors the cascade. Severe incidents are declared manually.

Deadlines — precise semantics

• 24h early warning — due 24 hours from awareness.
• 72h notification — due 72 hours from awareness.
• Final report — the anchor depends on the kind:
  • Exploited vulnerability: due 14 days after a corrective or mitigating measure is available (Art. 14(2)(c)) — not 14 days from awareness. You record the measure date; until you do, this stage has no running clock and can never be overdue.
  • Severe incident: due one calendar month after the 72h notification is submitted (Art. 14(4)(c)) — not one month from awareness.

Stage deadlines are independent: missing the 24h window does not remove the 72h obligation, and a later stage can be submitted while an earlier one is overdue. Resilic emails deadline reminders as each due date approaches.

The report editor

Each stage has its own draft with the Article 14 content categories for that stage:

• Early warning: summary, plus the Member States where the product is affected (where applicable).
• Notification: summary, affected products, cross-border impact, and the mitigating measures — both those taken and those available to users.
• Final report: additionally severity and impact, then per kind — security-update details and (where available) malicious-actor information for a vulnerability; root cause and ongoing mitigation for an incident.

Generate with AI pre-fills a draft grounded in what Resilic already knows — the CVE, affected products and deployments, KEV/CVSS data. Generated content is flagged “AI-drafted, needs review”; any edit keeps the draft in Draft.

Approval, export, audit trail

• Approve requires an explicit confirmation (“I have reviewed and take responsibility…”), records who signed and when, and completes that stage of the cascade inside Resilic. Nothing is transmitted to an authority — you file on the SRP yourself.

• Only an approved report can be exported. The export is a self-describing artifact (format aegis.article14.v0). You download it and submit it on the SRP yourself.

  That is the intended route from day one, not a workaround. ENISA explicitly provides no programming interface at launch — its SRP FAQ states that “no Application Programming Interfaces will be provided at this stage”. Reporting goes through the SRP portal using an EU Login account, which you can create in advance. So on 11 September 2026 there is no automated submission from any third-party system, for anyone.

• Every step — declared, generated, edited, approved — lands in an append-only audit trail (action, actor, timestamp): the evidence that you met the obligation, and of who signed what.

You can also record how impacted users were informed (Art. 14(8)) — via a published CSAF advisory or a described channel. There is no statutory deadline for this record, and Resilic never invents one; an open event without it shows an outstanding action, never “overdue”.

Draft language

AI report drafts default to regulator-appropriate English — the ENISA Single Reporting Platform and national CSIRTs expect it. You can generate a draft in German instead via the language switch next to the generate action; the export carries whatever language the signed content is in. Security advisories work the same way: the advisory’s language is set when it is created (default English) and is carried into the CSAF document’s lang field.