CRA Vulnerability Reporting: Build a 24h/72h Response Workflow
Build a CRA reporting runbook with separate vulnerability and incident triggers, 24h/72h escalation, final reports, evidence logs and a tabletop exercise.
On this page
A critical vulnerability appears in your dependency tree. Security starts investigating. Engineering starts preparing a patch. Under the EU Cyber Resilience Act (CRA), a separate reporting clock may already be running.
Once an applicable Article 14 trigger and the relevant awareness conditions are met, the early-warning deadline is 24 hours and the notification deadline is 72 hours. Neither waits for a complete root-cause analysis. A workable response process needs a timestamp, an accountable person and a verified submission route before the next incident arrives.
This runbook separates two Article 14 paths: an actively exploited vulnerability contained in a product with digital elements, and a severe incident having an impact on that product’s security. Both require staged reporting, but their final-report clocks differ. A scanner finding alone does not establish either trigger.
Operational Note: This runbook provides an engineering workflow for implementing Article 14 triage and operational readiness. Statutory triggers, economic operator roles, and CSIRT reporting endpoints must be reviewed against current ENISA platform guidelines and your organization’s legal counsel.
Establish scope and reporting ownership
Before configuring alerts, document the product boundary and your economic-operator role. Article 2 sets scope and exclusions; Article 3 provides definitions. A product’s remote data processing solution can matter to that boundary. Being a software vendor, hosting a service or using open source does not by itself settle applicability. [1]
Article 14 reporting obligations for manufacturers have been legally binding since 11 September 2026, while general application begins on 11 December 2027. Article 69 includes reporting for relevant products placed on the market before general application. Open-source software stewards have a separate regime under Article 24(3), applicable from 11 December 2027; do not assign them the manufacturer’s September 2026 start date. Neither a volunteer maintainer nor every open-source organisation is automatically a steward. [1–4]
This workflow assumes a manufacturer with an in-scope product. Have legal counsel resolve ambiguous scope, operator-role and awareness questions. Keep a product-specific decision record instead of making the on-call engineer reconstruct that assessment during an emergency.
Assign the following responsibilities, with a named deputy and an out-of-hours contact:
| Responsibility | Operational duty |
|---|---|
| Security response lead | Own intake, trigger assessment, timeline and escalations |
| Product engineering owner | Identify affected releases, validate impact and deliver mitigation |
| Legal/compliance reviewer | Advise on scope, triggers, content and disclosure constraints |
| Authorised submitter | Maintain platform access, submit reports and retain acknowledgements |
| Customer communications owner | Coordinate user notices, actionable mitigations and updates |
These roles are an engineering recommendation, not a CRA staffing prescription. One person can cover several roles in a small team, but an unavailable approver must not become a deadline dependency.
Open a case and assess both triggers
Route external vulnerability reports, exploit intelligence, monitoring alerts, supplier notices and customer incidents into one restricted case record. Record receipt time, the original evidence, affected products and who was paged. Avoid collecting unnecessary personal data or putting exploit material in a broadly visible project board.
Assess the paths independently:
| Path | Legal distinction to assess | Engineering evidence to collect |
|---|---|---|
| Actively exploited vulnerability | Article 3’s definition concerns reliable evidence of malicious exploitation by an actor without the system owner’s permission. Article 14 concerns such a vulnerability contained in the product. | Source and reliability of exploitation evidence, affected component and shipped versions, product impact and unresolved questions |
| Severe incident affecting product security | Apply Article 14’s severe-incident criteria, including relevant effects on protection of functions/data or malicious-code introduction/execution. A CVE is not a prerequisite. | Incident timeline, affected product functions, data/security impact, malicious activity and the reasons the severity criteria do or do not apply |
The precise legal criteria remain controlling; this table is a triage aid, not a substitute for Article 14. [1]
An ordinary CVE match without reliable exploitation evidence does not automatically meet the actively exploited vulnerability trigger. Keep it in vulnerability handling and reassess when evidence changes. Conversely, do not require evidence of exploitation against your own customer fleet before escalating credible evidence that a vulnerability contained in your product is being actively exploited.
A severe product-security incident can arise without an identified vulnerability. If both paths may apply, track both assessments and their reporting requirements. Ask the competent reporting contacts how to link submissions; do not discard one path merely because another case already exists.
Engineering recommendation: Record when relevant evidence reached the organisation, when it was assessed, and the proposed legal awareness timestamp for each path. Preserve the reasoning and contrary evidence. A later management meeting must not silently replace an earlier awareness timestamp. While awareness is uncertain, use the earliest plausible time for conservative internal planning and obtain prompt legal advice.
Run the 24-hour and 72-hour stages in parallel with response
Article 14 calls for reporting without undue delay, with an early warning within 24 hours and the relevant notification within 72 hours of becoming aware. The 72-hour clock runs from awareness, not from the early-warning submission. These limits are not permission to delay a report that can be made sooner. The stages and required contents differ between the two paths. [1]
Use this operational sequence:
- Page the owners immediately. Start deadline reminders from the recorded awareness time. Use elapsed time, UTC timestamps and a deputy; avoid business-day calculations.
- Prepare the early warning alongside technical triage. Record affected products, known facts, uncertainties and the path-specific information required by Article 14. Do not wait for a patch or a complete root-cause analysis.
- Submit through the verified route. Retain the exact payload, submission time, case reference and acknowledgement. Track a prepared report separately from an accepted submission.
- Develop the 72-hour notification while mitigating impact. Reconcile new evidence, correct preliminary information and provide the path-specific details required by the current reporting form and law.
- Schedule the next stage explicitly. Assign final-report ownership and any outstanding requests before closing the initial reporting task.
Internal checkpoints at, for example, four hours for initial assessment and sixteen hours for early-warning readiness can create working margin. They are recommended planning targets, not legal deadlines or a replacement for reporting without undue delay. Escalate earlier if the remaining margin becomes unsafe.
For the vulnerability path, prepare information about the vulnerability and affected product, exploitation and available corrective or mitigating measures. For the incident path, prepare an initial assessment of severity and impact, available indicators of compromise and relevant response information. Use the exact Article 14 requirements and current forms for the submission; these are preparation prompts, not exhaustive reporting templates. [1]
Verify the platform route before an emergency
Article 14 provides for notification to the CSIRT designated as coordinator and ENISA, using the single reporting platform established under Article 16.
Recipient selection follows strict establishment rules:
- For manufacturers established in the EU, reports are directed to the designated CSIRT of the Member State where the manufacturer has its main establishment.
- For manufacturers established outside the EU, notifications route to the CSIRT of the Member State where their authorised representative is located, or through the platform’s default distribution mechanisms where determined by the implementing rules.
Do not assume an arbitrary national CSIRT or an email to ENISA satisfies this route. Confirm the designated coordinator for your organisation and test account access on the Single Reporting Platform before an incident occurs. [1]
The Commission’s reporting and implementation pages and ENISA’s Single Reporting Platform FAQ are the official operational references. [2–4] Review the live platform procedures periodically to verify account delegation, schema updates, and operational endpoints.
Engineering recommendation: Have the authorised submitter verify access, delegation, recipient selection, acknowledgement handling and the documented support channel. Record the guidance version or access date. If the platform is unavailable, retain evidence of attempts and seek official instructions immediately; do not assume that an outage pauses a legal deadline or that a support message constitutes submission.
Manufacturer user-information duties also need their own owner. Article 14(8) addresses informing impacted users and, where appropriate, all users about the vulnerability or incident and relevant measures. Authority reporting and customer communication are separate work items. Coordinate disclosure with response partners without treating that coordination as a blanket extension of reporting time. [1]
Track the final-report clocks separately
Do not implement one generic “final report due” field for every case.
| Path | Article 14 final-report timing | Recommended operational record |
|---|---|---|
| Actively exploited vulnerability | No later than 14 days after a corrective or mitigating measure becomes available | Measure, availability timestamp and evidence, final-report deadline, responsible owner and submission reference |
| Severe incident | Within one month after submission of the incident notification | Actual notification submission time, calendar-month deadline and final-report owner |
| Severe incident still ongoing at that deadline | Progress report at that time, followed by a final report within one month of handling the incident | Progress submission, reason incident remains ongoing, handling milestone and resulting final deadline |
The vulnerability final report includes information about the vulnerability, its severity and impact, available information about the malicious actor and the security update or other corrective measures. The incident final report covers the incident, severity and impact, likely threat type or root cause, and mitigation measures. [1]
“Measure available” must not become “next planned release.” Capture when the relevant corrective or mitigating measure actually becomes available and have legal/compliance assess ambiguous cases. Similarly, do not substitute ticket closure for the legal incident-handling milestone without a reasoned assessment.
For the incident path, calculate calendar months under the applicable time-calculation rules, not a hardcoded 30-day timer. Retain any authority requests and follow-up correspondence with the case.
Retain an evidence log that survives handover
Use an access-controlled, versioned case record. The following is a recommended evidence structure, not a mandated CRA format or retention schedule:
| Record | Minimum useful contents |
|---|---|
| Intake | Case ID, UTC receipt time, source, original evidence and evidence custodian |
| Applicability | Product boundary, operator role, affected releases and scope decision reference |
| Trigger and awareness | Separate path assessments, evidence confidence, awareness timestamps, decision owner and rationale |
| Deadlines | Early warning, notification, final/progress report clocks and the event driving each |
| Technical response | Release/artifact identifiers, component inventory, exploitation/impact analysis, mitigation and fix validation |
| Communications | Submitted payload versions, recipient/platform reference, acknowledgements, user notices and corrections |
| Closure | Remaining requests, final submissions, handover owner and review actions |
Example: internal reporting case record
The following YAML is an illustrative internal tracking format, not an ENISA submission schema or a CRA-prescribed record. The example assumes the awareness time has been assessed for exercise purposes; a real case must document that determination separately for each reporting path.
case_id: CRA-2026-001
product: example-product
operator_role: manufacturer
assessment:
actively_exploited_vulnerability: under_review
severe_incident: under_review
awareness:
candidate_timestamp_utc: "2026-11-02T09:00:00Z"
confirmed: false
reporting:
early_warning:
planning_deadline_utc: "2026-11-03T09:00:00Z"
status: pending
notification:
planning_deadline_utc: "2026-11-05T09:00:00Z"
status: pending
final_report:
deadline_utc: null # Set from the applicable path-specific event
status: not_scheduled
submission:
platform_reference: null
acknowledgement_received: false
evidence:
affected_releases: []
exploitation_sources: []
assessment_decisions: []The 24-hour and 72-hour timestamps above are conservative planning checkpoints, not a conclusion that reporting is legally required. Keep actual submission timestamps and acknowledgements separate from drafts. Calculate final-report deadlines only when the relevant triggering event is established.
Keep uncertain statements visibly uncertain. Correct earlier submissions through the applicable process rather than rewriting the local record as though the initial assessment never happened. Restrict exploit details and personal data; agree access, retention and deletion with security and legal owners.
An SBOM can help connect a component to shipped releases. It does not establish active exploitation, decide legal reportability or prove conformity. (In our upcoming deep dive, “SBOMs and the EU Cyber Resilience Act: Building Audit-Ready Evidence”, we explore how to operationalize machine-readable component inventories and VEX data so your team can identify affected releases within this 24-hour window). A ticketing system can calculate reminders, but cannot establish that the organisation met its legal duties. Connecting software supply-chain visibility, CI/CD evidence capture and incident-response ownership is therefore a practical platform-engineering problem—not just a compliance documentation exercise.
Rehearse with a fictional tabletop
Use simulated submissions in the exercise log; do not send fictional incidents to the live platform. These are proposed acceptance checks, not results from an exercise already performed.
Scenario A — exploited dependency: At 09:00 UTC on a Tuesday, the team receives credible evidence of malicious exploitation of a vulnerability in a component shipped in its product. Assume for the exercise that legal awareness is established then. The outer limits for early warning and notification are Wednesday 09:00 and Friday 09:00, respectively, with action required without undue delay. Ask the team to identify affected releases, page the deputy and prepare a report before a fix exists. Introduce a mitigation later and require a separate 14-day final-report calculation from its availability.
Scenario B — severe incident without a CVE: Introduce a product-security incident for which the severe-incident criteria are assumed met, while the exploit mechanism remains unknown. Require a notification, then make the incident remain ongoing at the one-month reporting point. Check that the team prepares a progress report and tracks the later final-report clock from handling the incident.
Scenario C — ordinary finding: Supply only a scanner match with no reliable evidence of active exploitation and no severe incident. Require documented triage and reassessment conditions. Check that the team neither automatically reports every CVE nor closes the case without product-impact analysis.
Repeat one scenario with the primary submitter absent and a simulated platform outage. The exercise succeeds when the deputy can find the scope decision, explain each clock, produce the appropriate report draft and preserve a complete evidence trail. Record failures as runbook changes, then rehearse those handovers again.
Before using the runbook operationally, obtain product-specific legal/compliance review and verify the current official reporting instructions. The practical starting point is one product, two trigger assessments and a reporting owner who can act outside office hours.
Sources
[1] Regulation (EU) 2024/2847, EUR-Lex , especially Articles 2, 3, 14, 16, 24, 69 and 71.
[2] European Commission: CRA reporting .
