CRA Reporting Obligation since 11 September 2026: What Manufacturers Must Have in Place Now

11 September 2026 was the first hard deadline of the Cyber Resilience Act (CRA) that directly affects manufacturers of digital products. Since then, the reporting and notification obligations under Art. 14 of Regulation (EU) 2024/2847 have been mandatory, while the full product requirements only apply from 11 December 2027. Under Art. 69(3), the reporting obligation also covers products placed on the market before 11 December 2027. Without working reporting processes, the deadlines are hard to meet when it matters, even if the product itself does not yet need to carry CE marking.

This article explains which deadlines apply, what must be reported, how the reporting process via the ENISA Single Reporting Platform works, and which organisational preparations manufacturers should initiate now.

What Must Be Reported since 11 September 2026

The reporting obligation covers two categories of events that must be clearly distinguished:

• Actively exploited vulnerabilities: As soon as a manufacturer becomes aware that a vulnerability in its product with digital elements is being actively exploited by attackers, the reporting obligation is triggered - regardless of whether a patch is already available.
• Severe incidents: Incidents having an impact on the security of the product that are to be classified as severe under Art. 14(5) also trigger the reporting chain.

The deadlines run from the moment the manufacturer becomes aware. When the attack took place or when third parties discovered it has no bearing on when the deadline starts. This distinction has practical implications for internal monitoring and triage processes.

The Three Reporting Stages in Detail

The CRA reporting regime follows a staged notification model that must be implemented with operational precision:

An avoidable error in compliance documents is describing the final report as simply "14 days". The correct differentiation is: for vulnerabilities, the 14-day deadline runs from the availability of a corrective or mitigating measure; for severe incidents, the deadline is one month from the 72-hour notification. This distinction should be reflected in internal process documents and runbooks.

The Reporting Channel: ENISA Single Reporting Platform

All notifications are submitted via the Single Reporting Platform (SRP) that the EU Agency for Cybersecurity ENISA sets up and operates under Art. 16. The report goes through the endpoint of the CSIRT designated as coordinator in the Member State of your main establishment and is simultaneously accessible to ENISA (Art. 14(7)).

The CSIRT forwards the report to the CSIRTs of the Member States where the product has been made available; only in narrowly defined cases may it delay dissemination (Art. 16(2)). This single route covers the CRA report; reporting duties under other laws such as NIS2 are unaffected.

Note on the reporting platform: Manufacturers should monitor official ENISA communication channels, set up access to the platform in advance and test it internally. Onboarding only when a report is due is not a realistic scenario when operating under a 24-hour escalation path.

What Must Be Prepared Operationally: Building a PSIRT

Filing a notification within 24 hours is not an administrative act that can be organised spontaneously. Behind it lies a functioning Product Security Incident Response process (PSIRT) - or at minimum a lean equivalent suited to the organisation. For manufacturers without structured vulnerability management processes, setting up a PSIRT is a central building block of CRA preparation.

Detection Capability: When Does the Clock Start?

The 24-hour deadline begins at the moment the manufacturer becomes aware. This immediately raises the question: through which channels does the manufacturer receive knowledge? Typical sources include internal security monitoring, reports from security researchers (responsible disclosure), customer reports, and threat intelligence feeds. Without defined intake channels and a responsible role that receives and evaluates notifications, the deadline is practically unachievable.

A dedicated security@ address or a comparable reporting channel is advisable. From 11 December 2027 the CRA expressly requires a contact address for vulnerability reports and a single point of contact (Art. 13(17), Annex II point 2).

Triage and Classification in Under 24 Hours

Not every reported vulnerability or security indication triggers a CRA reporting obligation. The obligation is triggered only when a vulnerability is being actively exploited or an incident qualifies as severe. This triage step must function under time pressure with clear role accountability. A useful structure: a simple classification scheme (thresholds, checklist) and an on-call rule that applies outside business hours.

Preparing Notification Content

The 72-hour notification contains, where available, general information, for example on the product, the nature of the exploit or incident (for incidents with an initial assessment), corrective or mitigating measures taken and measures users can take (Art. 14(2)(b), Art. 14(4)(b)). Prepared notification templates for typical scenarios help you assemble this information under time pressure.

SBOM as the Foundation for Fast Response

A complete Software Bill of Materials (SBOM) is a standalone CRA obligation and at the same time the operational prerequisite for knowing quickly, in an emergency, which product versions are affected by a vulnerability and which customers must be informed. Manufacturers who have been subject to reporting obligations since 11 September 2026 but do not maintain a current SBOM face a structural problem with response speed.

Who Is Subject to the Reporting Obligation?

The reporting obligation applies to manufacturers of products with digital elements within the meaning of the Regulation - that is, natural or legal persons who develop or have developed such a product and place it on the EU market under their own name or brand. This applies to free-of-charge products and also where development is outsourced to third parties.

Importers and distributors have different roles under the CRA and primarily carry different obligations; the reporting obligation under Art. 14 addresses the manufacturer role directly. Whether your product falls under the CRA can be established using the interactive scope check. A structured overview of all roles and exceptions is provided in the article Cyber Resilience Act - am I affected?

Deadlines at a Glance: What to Do When

A pragmatic view of the sequence from today, given that the reporting obligation has applied since September 2026:

• Immediately: Assess whether and for which products a reporting obligation exists (scope analysis). Am I affected at all?
• Also immediately, if still open: Establish a vulnerability disclosure channel, define internal triage processes, assign responsibilities, create notification templates, set up and test access to the reporting platform.
• In parallel (by 11.12.2027): Build out SBOM, technical documentation, integrate security-by-design into the development cycle, prepare CE conformity assessment. Details in the overview of CRA requirements and product obligations.

For mid-market manufacturers with limited capacity, the prioritisation logic is clear: reporting processes first, because this obligation already applies and because a PSIRT process needs time in operation before it runs reliably. The detailed implementation plan for SMEs is available at Cyber Resilience Act for SMEs: Prioritised Implementation Plan.

Support with PSIRT Setup and Reporting Process Preparation

Blackfort Technology supports manufacturers of products with digital elements in their operational CRA preparation: from initial scope analysis through the setup of lean PSIRT processes to integration with existing ISMS structures. Blackfort Technology brings hands-on implementation experience from PKI, DORA, NIS2 and SBOM/vulnerability management engagements.