CRA reporting since September 2026: triggers, deadlines and the Single Reporting Platform

What it is

Status as of 25 October 2026. Article 14 of Regulation (EU) 2024/2847, the Cyber Resilience Act (CRA), has applied to manufacturers since 11 September 2026. Re-check the regulation, Commission reporting guidance and ENISA platform instructions before using a reporting procedure. This summary explains the published rules; this is not legal advice.

Two triggers require notification: an actively exploited vulnerability in a product with digital elements, and a severe incident affecting that product's security. Article 3(42) requires reliable evidence of malicious exploitation without the system owner's permission. Article 14(5) covers actual or potential harm to the protection of sensitive or important data or functions, or the introduction or execution of malicious code in the product or a user's systems. These are distinct tests. Regulation, Articles 3 and 14.

Why it matters

ENISA announced the Single Reporting Platform (SRP) launch on 11 September 2026. It routes notifications to the designated coordinating Computer Security Incident Response Team (CSIRT) and ENISA. The receiving CSIRT distributes information to relevant national counterparts, subject to the regulation's exceptions for delayed dissemination. ENISA launch notice.

The early deadlines run from awareness, not from management approval or completion of an investigation. Article 69(3) also brings in-scope products placed on the market before 11 December 2027 into Article 14 reporting. The later application of most CRA requirements does not postpone this duty. Regulation, Articles 14, 69 and 71.

How to apply

• Record awareness and classify the event. Preserve the evidence supporting active exploitation or the incident severity criteria. A vulnerability finding alone does not establish malicious exploitation.
• Send the early warning promptly, within 24 hours at the latest. Identify the Member States where the product is known to be available, where applicable. For an incident, also state whether unlawful or malicious activity is suspected.
• Provide the next notification promptly, within 72 hours of awareness at the latest. Unless already supplied, include the available product or incident information, relevant assessment, mitigation already taken and measures users can take. Indicate sensitivity where applicable.
• Use the correct final-report trigger. For a vulnerability, the deadline is 14 days after a corrective or mitigating measure becomes available. Include severity, impact, available malicious-actor information and remedy details. For a severe incident, the deadline is one month after submitting the 72-hour-stage incident notification; include severity, impact, likely threat or cause, and applied or ongoing mitigation. These are the separate rules in Article 14(2) and (4), also summarised by the Commission.
• Select the coordinating CSIRT under Article 14(7). Ordinarily this follows the manufacturer's main EU establishment. Manufacturers without one use the ordered criteria in that paragraph. Retain submission receipts and follow-up requests.
• Inform affected users. Article 14(8) separately requires information about the vulnerability or incident and, where necessary, protective or corrective measures; an authority notification does not replace it.

Pitfalls

Do not count 72 hours from the early-warning submission or 14 days from vulnerability discovery. ENISA's FAQ, updated 15 October 2026, warns that current platform counters can differ from the statutory clock. Keep an independent deadline record; reminders do not replace the manufacturer's responsibility. ENISA SRP FAQ, question 26.