CRA Reporting Copilot / Guides

CRA incident reporting in Jira: mapping Article 14 to your tickets

July 2026 · 6 min read

From 11 September 2026, manufacturers of products with digital elements placed on the EU market must report actively exploited vulnerabilities and severe incidents under Article 14 of the Cyber Resilience Act (Regulation (EU) 2024/2847). For most software and IoT companies, the raw material of those reports already exists somewhere specific: an incident ticket in Jira or a request in Jira Service Management. This guide maps the regulation's structure onto that reality.

The report is born in your ticketing tool

An Article 14 report is, at its core, a structured retelling of facts your responders already record: what was detected, when, in which product, what the impact looks like, what was done. If your incident process runs through Jira or JSM, the ticket is the earliest and most complete source of those facts. Treating reporting as a separate, later activity — a document someone starts from a blank page — is where time is lost and details drift.

The staged timeline, and the two clocks people mix up

Article 14 imposes a staged timeline on both reportable paths: an early warning within 24 hours of becoming aware, a notification within 72 hours, and a final report. The stages sound symmetrical. The final report is not:

Note what neither clock starts from: awareness. The vulnerability clock waits for a fix to exist; the incident clock starts from your own 72-hour submission. Under pressure, teams routinely calendar "one month after we found out" — which is simply the wrong event. Whatever tooling you use, your deadline tracking needs to model these as two distinct start points, one of which may sit in a pending state until its trigger occurs.

Beyond the authority: two more notices

Article 14 does not stop at reporting to authorities. Manufacturers must also inform affected users about an actively exploited vulnerability and, where relevant, about corrective measures they can take (Art. 14(8)) — and if the manufacturer fails to do so, the coordinating CSIRT may, where it considers it proportionate and necessary, inform users directly. Separately, where the issue sits in an integrated third-party component (open source included), Art. 13(6) requires notifying the component's maker or maintainer. A complete Article 14 workflow therefore produces up to five documents per case, not three.

What to capture in the ticket, before you need it

A practical pre-September exercise: audit whether your Jira/JSM tickets reliably carry the fields the reports will need.

• Awareness time — recorded explicitly and confirmed by a named role, not inferred later from comment timestamps. How "becomes aware" is interpreted in edge cases depends on official guidance; treat it conservatively and record your reasoning.
• Affected product and version — including legacy products: the reporting duty applies to products already on the EU market before full application on 11 December 2027 (Art. 69(3)).
• Exploitation status — observed in the wild or not, and on what evidence.
• Severity indicators mapped to Art. 14(5): impact on confidentiality, integrity, availability of sensitive data or functions, or introduction or execution of malicious code.
• Trigger events for the final-report clocks — the date a corrective/mitigating measure became available, or the timestamp your 72-hour notification was submitted.
• Component provenance — whether a third-party component is implicated, and who maintains it.

Process over heroics

The 24-hour window is deliberately survivable: the early warning is a minimal signal, not an analysis. What makes it survivable in practice is deciding in advance who confirms the clock has started and who may send an incomplete first message — then rehearsing once. Teams that run a single tabletop exercise before 11 September consistently report that the timeline stops being the frightening part.