CRA Incident Reporting Is Live: What SMEs Need to Do

From 11 September 2026, manufacturers of products with digital elements must use the ENISA single reporting platform. For many SMEs, this is the first CRA compliance deadline they must handle in real time.

If your business develops or sells software, connected devices, or other products with digital elements in the EU, determine roles and access before an incident occurs. Waiting until discovery is too late.

What changed on 11 September 2026?

The Cyber Resilience Act, or CRA ( Regulation EU 2024/2847 ), introduces cybersecurity requirements for products with digital elements made available on the Union market. Most of its technical requirements and CE marking rules apply from 11 December 2027 , but the reporting obligations under Article 14 apply from 11 September 2026 .

The Single Reporting Platform (SRP) managed by ENISA is now the required channel for these notifications. It enables manufacturers to submit details once and have them routed to the relevant national Computer Security Incident Response Team (CSIRT) and, where applicable, ENISA.

This phased timeline forces companies to establish incident handling mechanisms well before the remainder of the CRA's product conformity duties take effect.

Which companies could be affected?

The CRA primarily targets manufacturers that make available on the EU market a product with digital elements . Depending on the setup, this can include:

• Commercial software applications and platforms (see our guide on CRA for software developers ).
• Connected devices and Internet of Things (IoT) hardware.
• Hardware that integrates digital components or firmware.
• Certain medical or industrial products containing software, subject to specific CRA scoping rules and exclusions.
• Non-EU businesses selling covered products into the European single market.

Classification is not always obvious. A company might describe itself as a SaaS vendor, software developer, equipment manufacturer, importer or distributor, whereas the CRA evaluates roles based on actual product characteristics and distribution terms.

Open-source software also requires nuanced assessment. The CRA contains specific provisions for free and open-source software and open-source stewards, meaning not all open-source projects are treated as commercial manufacturers.

Which events must be reported?

Article 14 distinguishes two main reportable scenarios:

Not every vulnerability, bug or operational anomaly meets these legal thresholds. Organisations must be capable of triaging the event, recording available evidence at decision time, and demonstrating why reporting was or was not required.

This triage should not rely on a generic severity metric. The CRA's specific legal definitions and criteria must be evaluated directly.

What are the CRA reporting deadlines?

The CRA establishes a staged sequence of notifications:

• Early warning (24h): without undue delay and in any event within 24 hours of becoming aware of an actively exploited vulnerability or severe incident.
• Detailed notification (72h): within 72 hours , including available details on vulnerability severity, mitigations or initial incident impact assessment and indicators of compromise.
• Final report: within 14 days after a corrective measure is available for an exploited vulnerability; within 1 month after the initial notification for a severe incident.

The CRA's staged reporting clock: 24 hours, then 72 hours, then a final report.

The 24-hour deadline is the primary operational challenge. It leaves minimal time to assign responsibilities, gather facts, verify contact details, and secure internal sign-off.

What information should an SME prepare?

A functional reporting log should record:

• Affected product, model, version and release identifiers.
• Identity of the manufacturer and relevant economic operators.
• Exact date and time the organisation first became aware of the event.
• Nature of the vulnerability or incident.
• Known or suspected exploitation in the wild.
• Severity and probable impact on user systems.
• Affected users, systems, Member States or markets, where known.
• Remediation or mitigation measures taken or planned.
• Indicators of compromise (IoCs), if applicable.
• Internal triage decisions, approvals and open uncertainties.
• Copies or references of subsequent follow-ups and notifications.

The file should clearly distinguish confirmed facts , provisional findings , and unverified items . Guessing to complete a submission form creates a less defensible record than flagging an item as pending verification.

Who should own CRA reporting?

Even a small organisation should assign distinct responsibilities. The procedure should define:

• Who receives internal and external security alerts.
• Who determines whether a CRA threshold is met.
• Who drafts the technical notification.
• Who checks factual claims.
• Who authorizes submission to the ENISA SRP.
• Who acts as backup if the primary owner is unavailable (24/7 coverage).
• Who manages communication with customers, suppliers, regulators and affected stakeholders.

Non-EU manufacturers must also verify whether an EU authorized representative is required and what role they play in the notification workflow.

How does CRA reporting fit with existing workflows?

CRA reporting should not operate as a disconnected silo. It should integrate with existing incident response, data privacy and business continuity processes.

A single security event may trigger multiple regimes: the CRA, NIS2 , GDPR personal data breach notifications , customer contractual notices, or financial sectoral rules ( DORA ). These regulations do not use identical thresholds, recipient authorities or timelines.

A structured workflow should answer three questions separately:

1. What happened technically?
2. Which legal or contractual regimes require notification?
3. What information can be consistently reused across filings?

This avoids duplicate effort without mistakenly assuming that a single notification satisfies every legal duty. To map how these regulations overlap, consult our EU Compliance Stack matrix .

Practical SME Readiness Checklist

What a software tool should, and should not, do

Compliance software can support readiness by guiding scoping analysis, tracking legal deadlines, structuring triage data, highlighting missing fields and maintaining an immutable audit log.

It should not obscure uncertainties or present automated classifications as unchallengeable legal conclusions. A defensible compliance record presents source data, applicable rules, items requiring human review, and the identity of the person signing off. Automation does not eliminate accountability: it gives teams an organized, timestamped foundation to meet the 24-hour deadline.

Majda Skrijelj

Senior Compliance Officer in an international financial institution with 20+ years of experience across institutional governance, AML/CFT, and European regulatory risk (GDPR, AI Act, DORA).