CRA Reporting Obligation from 11 September 2026: What Manufacturers Must Prepare Now

11 September 2026 is the first hard deadline of the Cyber Resilience Act (CRA) that directly affects manufacturers of digital products — and it is approaching faster than many compliance roadmaps account for. While the full product requirements only apply from 11 December 2027, the reporting and notification obligations under Art. 14 of Regulation (EU) 2024/2847 become mandatory more than a year earlier. Manufacturers who cannot demonstrate functioning processes on that date face regulatory consequences — 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 from 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 security incidents ("severe incidents"): Incidents that have an impact on the security of the product and are to be classified as severe also trigger the reporting chain.

The decisive moment is when the manufacturer becomes aware — not when the attack actually occurred or was discovered by third parties. This distinction has practical implications for internal monitoring and triage processes.

The Three Reporting Deadlines in Detail

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

A common error in early 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 the corrective measure; for severe incidents, the deadline is one month from the 72-hour notification. This distinction must be reflected in internal process documents and runbooks.

The Reporting Channel: ENISA Single Reporting Platform

All notifications are submitted via the CRA Single Reporting Platform (SRP), operated by the EU Agency for Cybersecurity ENISA. The principle: manufacturers report once — the platform automatically forwards the information to:

• the CSIRT of the member state where the manufacturer has its principal place of business,
• and — except in justified exceptional cases — simultaneously to ENISA.

The receiving CSIRT then shares relevant notification information with other affected CSIRTs within the EU. Manufacturers therefore do not need to submit multiple reports to different authorities — a single notification via the SRP is sufficient.

Important current note (as of July 2026): The ENISA Single Reporting Platform was not yet fully operational at the time of writing. ENISA has announced that the platform will be available in time before 11 September 2026. Manufacturers should monitor official ENISA communication channels and plan internal test runs well in advance — onboarding to the platform a few days before the deadline 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, building a PSIRT is typically the most demanding operational element 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.

It is advisable to establish a dedicated security@ address or equivalent vulnerability disclosure channel — the CRA implicitly anticipates this, and well-prepared manufacturers make this channel publicly accessible.

Triage and Classification in Under 24 Hours

Not every reported vulnerability or security indication triggers a CRA reporting obligation. The decisive question is whether a vulnerability is being actively exploited or whether 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 must include information on corrective and mitigation measures taken. This means: within three days, action must not only have been reported but must already have been taken — or at minimum a documented immediate measure must be in place. Prepared notification templates for the most common scenarios reduce response time significantly.

SBOM as the Foundation for Fast Response

A complete Software Bill of Materials (SBOM) is not only a standalone CRA obligation — it is also 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 are subject to reporting obligations from 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 preparation horizon leading up to September 2026:

• Immediately: Assess whether and for which products a reporting obligation exists (scope analysis). Am I affected at all?
• By Q3 2026: Establish a vulnerability disclosure channel, define internal triage processes, assign responsibilities, create notification templates, test SRP onboarding once available.
• 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 deadline arrives a year earlier and because a functioning PSIRT process requires at least six months of operational lead time to be reliable. 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. Christian Gebhardt, Managing Director and co-author of the ACS/BSI guide on penetration testing of LLMs and member of the ACS AI expert working group, brings hands-on implementation experience from PKI, DORA, NIS2, and SBOM/vulnerability management engagements.