EU CRA AI Incident Reporting: The 24-Hour Evidence Workflow

Article 14 of the Cyber Resilience Act has been live since 11 September 2026. A manufacturer that becomes aware of an actively exploited vulnerability or a severe incident affecting the security of its product with digital elements enters a staged reporting process. For a product that sends user or agent requests to an LLM, the first useful question is precise: which product behaviour and affected users can the incident team establish before the first deadline expires?

TL;DR

• The manufacturer files an early warning within 24 hours and a fuller notification within 72 hours.
• Vulnerabilities get a final report within 14 days after a corrective measure is available; severe incidents get one within a month of the 72-hour notice.
• Scope follows the product with digital elements, including qualifying remote data processing, rather than every cloud or model service it contacts.
• Identity-bound HTTP records turn the first response shift into a reconstruction instead of an interview exercise.

The reportable events have two different tests

The official text of Regulation (EU) 2024/2847 separates actively exploited vulnerabilities from severe incidents. An actively exploited vulnerability is one for which there is reliable evidence that a malicious actor has exploited it in a system without the system owner's permission. A severe incident reaches Article 14 when it negatively affects, or can negatively affect, the product's protection of sensitive or important data or functions. The test also catches an incident that led, or could lead, to malicious code entering the product or a user's network and information systems.

That distinction matters for an AI-enabled product. A prompt injection attempt alone says little about Article 14. An exploit that bypasses an authorization rule and exposes protected context can support the severe-incident analysis. A vulnerability in the product's routing component that attackers are using in deployed systems belongs in the actively exploited track. The product security team should record which statutory test it applied and who approved that classification.

The scope analysis comes before event classification. Article 2 covers products with digital elements made available on the market when their intended purpose or reasonably foreseeable use includes a direct or indirect connection to a device or network. Article 3 includes remote data processing only when it was designed and developed by the manufacturer, or under its responsibility, and the product would lose a function without it. Recital 12 expressly distinguishes cloud services developed outside that responsibility. A standalone model API therefore falls outside an application manufacturer's CRA scope merely because the application calls it. Counsel should document the product-specific conclusion.

The 24-hour early warning needs a small reliable packet

Article 14 requires the early warning without undue delay and within 24 hours after awareness. For an actively exploited vulnerability, it identifies affected Member States where known. For a severe incident, it also states at least whether unlawful or malicious acts are suspected. The Commission's CRA reporting page confirms that manufacturers submit through the Single Reporting Platform.

I would keep the first packet deliberately narrow. A hurried narrative filled with assumptions creates repair work at 72 hours. The packet should identify the product and affected version, state the awareness time, name the reportable-event track, list Member States known at that point, and preserve links to the evidence supporting each statement. The manufacturer's main establishment determines the coordinating CSIRT endpoint under Article 14(7), with ordered alternatives for a manufacturer lacking a main establishment in the Union.

Picture the on-call lead at 02:10, a cold mug beside the keyboard, comparing a gateway decision ID with a release manifest. That concrete join is more useful than a broad claim that "AI traffic may have been affected." It establishes the product version and request window. It also fixes the point at which the manufacturer became aware.

The 72-hour notification adds mechanism and mitigation

The vulnerability notification due within 72 hours provides available information about the product and the general nature of the exploit and vulnerability. It also covers measures already taken, actions available to users, and the sensitivity assigned to the information where applicable. The incident notification uses the same deadline but asks for the nature of the incident, an initial assessment, current measures, and user actions. Both can mark information as sensitive where appropriate.

An AI request timeline should answer five questions before that filing:

• Which authenticated users or agents sent affected requests?
• Which product version and policy revision handled them?
• What LLM destination and region received each request?
• Which content classification and enforcement decision applied?
• Which user accounts or data classes show impact, and which product functions are affected?

The required facts span application and release evidence plus identity-bound HTTP records. AI incident response playbook explains the operational sequence for preserving that material. The CRA filing remains the manufacturer's legal act. Security tooling supplies evidence and enforcement records; it never makes the reporting decision or submits the notice.

Article 14(8) adds a user communication duty after awareness. The manufacturer informs impacted users, and where appropriate all users, about the vulnerability or incident and necessary mitigation or corrective measures. A structured, machine-readable format may be appropriate. Incident response therefore needs one owner for the regulator packet and another for user communication, both working from the same verified timeline.

Final reports document the event and correction

The two final-report clocks diverge. An actively exploited vulnerability gets a final report no later than 14 days after a corrective or mitigating measure becomes available. The report covers severity and impact, available information about a malicious actor, and details of the security update or other correction. A severe incident gets its final report within one month after the 72-hour notification. That report describes severity and impact in detail, states the likely threat type or root cause, and records applied and ongoing mitigation.

The evidence repository should preserve the record as it evolved. Keep the original event, analyst annotations, affected-version query, impact method, correction release and user notice, plus each submitted packet under stable identifiers. This supports an intermediate report if the coordinating CSIRT requests one under Article 14(6). It also avoids quietly replacing an early assumption with a later conclusion.

My blunt view is that a reporting programme without a rehearsed 24-hour query is still a policy document. Run the query against a named product version and a two-hour window before an incident. The exercise should expose missing identity fields and direct routes that bypass recording. It should also surface unversioned policies and model destinations absent from the component inventory. AI audit log immutability covers why custody of those records matters during an investigation.

The handoff from detection to legal reporting

A workable runbook assigns four decisions. Product security determines awareness and technical scope. The manufacturer or its designated legal owner classifies the Article 14 event and approves the filing. Engineering owns mitigation and affected-version analysis. Communications owns the Article 14(8) user notice. Each decision gets a timestamp and named approver, with its evidence reference and revision history attached.

The ENISA Single Reporting Platform page provides the operational entry point and current user material. Register the people who will submit before the next incident. Test account access, preserve the selected coordinating CSIRT basis, and store the filing receipt with the case. A 24-hour clock is a poor moment to discover that the only registered administrator left six months ago.

Direct model-provider traffic deserves explicit treatment. Requests that bypass the product's controlled route leave a visibility gap. Stolen credentials and endpoint compromise also sit outside an HTTP gateway's enforcement boundary. The same applies to local model execution and STDIO agent activity. The incident team still investigates those paths through the relevant IAM and infrastructure evidence. Keeping that boundary in the runbook prevents a clean HTTP timeline from being mistaken for a complete incident record.

DeepInspect

DeepInspect operates on authenticated HTTP traffic deliberately routed between users or agents and LLM endpoints. It binds supplied identity context to each request, evaluates content classification and destination policy, records the model route and policy revision, and produces a signed per-decision record before the response returns. Those records can support the manufacturer's 24-hour scope query and the 72-hour impact assessment.

The enforcement boundary stays exact throughout the investigation. DeepInspect neither decides that Article 14 applies nor files with ENISA. It cannot observe direct bypass traffic, stolen credentials used elsewhere, endpoint compromise, or provider training. Model weights, local execution, and STDIO activity also require other evidence sources. Those facts belong to the product's wider incident process. Book a technical deep dive at deepinspect.ai.