Less than four months separate today from the moment when Article 14 of the EU Cyber Resilience Act becomes binding. On September 11, 2026, manufacturers of products with digital elements placed on the Union market move from voluntary disclosure practice to a formal, time-bound reporting regime, administered by ENISA through a new piece of cross-Member-State infrastructure called the Single Reporting Platform.
This article walks through what the deadline actually requires, what the architecture behind it looks like, what the scope captures, and what the available readiness data suggests about how many manufacturers will be ready when the clock starts.
What Article 14 Actually Requires
The substance of Article 14 is, when read carefully, simpler than the trade press has sometimes suggested. The Article applies two distinct reporting tracks.
The first track covers actively exploited vulnerabilities. A manufacturer that becomes aware of a vulnerability affecting a product they have placed on the EU market, and that is being actively exploited in the wild, must submit:
- An early warning notification within 24 hours of becoming aware
- A full notification within 72 hours
- A final report within 14 days from the moment a corrective measure (patch, mitigation, or workaround) becomes available
The second track covers severe incidents impacting the security of the product. The cadence is similar, but the final-report deadline extends to one month rather than 14 days, reflecting the broader investigative scope of an incident relative to a single vulnerability.
Each clock runs independently. Each starts at the moment of awareness, not at the moment of confirmation, not at the moment of legal sign-off, not at the moment when communications has agreed on the language. The Regulation is explicit that the clock starts when the manufacturer becomes aware. The internal organizational processes that follow are the manufacturer’s problem, not the Regulator’s.
Sources: European Commission, Cyber Resilience Act — Reporting obligations, https://digital-strategy.ec.europa.eu/en/policies/cra-reporting ; ENISA, Single Reporting Platform (SRP), https://www.enisa.europa.eu/topics/product-security-and-certification/single-reporting-platform-srp .
The Single Reporting Platform
The Single Reporting Platform (SRP) is the technical infrastructure that ENISA is building to receive these notifications. It is operated centrally and connected, through routing logic, to the national Computer Security Incident Response Teams (CSIRTs) of each Member State.
A manufacturer reports once, to the SRP. The notification is automatically directed to the CSIRT of the Member State where the manufacturer has its main EU establishment, and, except in exceptional circumstances, the notification is made available simultaneously to ENISA. The result is that one report reaches the national-level authority and the EU-level authority at the same moment, with the same timestamp, in the same format.
The architectural choice matters. Previous EU cybersecurity reporting regimes (notably under NIS1 and to some extent NIS2) allowed for divergence between national interpretations, format requirements, and routing paths. The SRP closes that gap by design. A manufacturer that operates across several Member States cannot, in this regime, file different notifications to different national authorities with different content. The report is one report. The architecture enforces this.
The SRP itself is scheduled to be operational by September 11, 2026, with a testing period preceding that date. Manufacturers who have not engaged with the SRP testing process before the deadline will be filing their first real notification through an interface they have never used.
The Scope: Legacy Products Included
The obligation applies, importantly, to all products with digital elements available on the Union market, including those that were placed on the market before December 11, 2027. There is no grandfather clause for incident reporting. A product sold in 2019, still in the field in 2026, still subject to the reporting obligation.
This is the dimension most product-team conversations have underestimated. The September 11, 2026 deadline is, for many manufacturers, not about new products being launched after that date. It is about the long tail of legacy products that are still receiving security updates (or that should be), and that are still subject to vulnerabilities found and exploited by adversaries who do not care when the product first shipped.
For a manufacturer with a portfolio of long-lived products, the SBOM, the security update pipeline, the customer notification workflow, the legal review process, and the regulatory filing capacity must all extend backward to cover the installed base, not just forward to cover new launches. The companies that have an active end-of-life management discipline are advantaged. The companies that have not maintained a clean view of which legacy products are still on the market are about to discover what they did not know they did not know.
The SBOM Obligation: A Separate Clock
The Software Bill of Materials (SBOM) obligation enters force on a separate, later timeline: December 11, 2027. From that date, manufacturers must generate a machine-readable SBOM covering at least top-level dependencies, keep it up to date, and supply it to market-surveillance authorities on request.
The CRA does not specify a fixed format (SPDX, CycloneDX, or others), but does require the format to be “commonly used and machine-readable”. The Linux Foundation and OpenSSF have published convergence work on SBOM standards under the CRA framework, suggesting that the de-facto formats will stabilize before the 2027 deadline. Manufacturers building SBOM capability now, in parallel with the September 2026 reporting workstream, are the ones who will be ready for both clocks.
The two obligations interact in operational practice. A robust SBOM is, in many cases, the technical substrate that allows the manufacturer to determine quickly whether a newly disclosed third-party vulnerability affects their product, and thus whether the Article 14 reporting clock has started. Without a current SBOM, the time from public disclosure of an upstream vulnerability to confirmation of in-product impact is measured in weeks. With a current SBOM, it can be measured in hours. The 24-hour clock makes that difference operationally decisive.
Sources: OPSWAT, EU Cyber Resilience Act (CRA): A Roadmap to Software Supply Chain and SBOM Compliance, https://www.opswat.com/blog/eu-cyber-resilience-act-cra-a-roadmap-to-software-supply-chain-and-sbom-compliance ; OpenSSF, Global Alignment on SBOM Standards: How the EU Cyber Resilience Act and OpenSSF Are Unifying Software Supply Chain Security, October 2025 ; SafeDep, SBOM and the EU Cyber Resilience Act .
Readiness: The Gap Between Awareness and Execution
The Linux Foundation, in its 2025 CRA readiness research, documented a wide spectrum of preparedness across open-source communities and commercial manufacturers. The findings are sobering. Persistent knowledge gaps about what the CRA actually requires. Persistent uncertainty about which deadline applies to which obligation. And, crucially, limited SBOM production among manufacturers who will be required to produce one by December 11, 2027.
The reporting obligation (September 2026) is closer in time but, paradoxically, less prepared for in the manufacturer base. The reasoning typically goes: vulnerability disclosure is a process manufacturers already have, so the CRA reporting obligation will simply graft onto the existing process. This reasoning ignores the time pressure (24 hours is shorter than most internal escalation paths), the format requirements (the SRP intake format is structured and machine-readable, not freeform), and the cross-jurisdictional routing logic of the SRP (the manufacturer cannot select the receiving authority, the architecture does).
A separate dimension of the readiness gap is enforcement. The Regulation establishes a clear obligation but the practical enforcement architecture is still being built out by Member State market surveillance authorities. Manufacturers who interpret the early enforcement environment as lenient are extrapolating from a transitional period that will end faster than they expect. The first significant enforcement action under Article 14 will, by the architectural logic of the SRP, be visible at the EU level the moment it happens at the national level.
What Manufacturers Should Be Doing Now
For a manufacturer of products with digital elements placed on the EU market, four months from a binding regulatory deadline is no longer a planning horizon. It is an execution horizon.
The minimum operational capability that needs to be in place by September 11, 2026 includes:
- A defined process for identifying when an actively exploited vulnerability or severe incident triggers the Article 14 reporting clock, with clear criteria, escalation paths, and decision authorities
- A 24-hour response capability that includes the legal, technical, and communications functions, with pre-approved notification templates and decision authorities established before the first incident
- An identified point of contact with the national CSIRT of the Member State of main establishment, and an established channel for engagement before the first real report
- An understanding of which products in the portfolio fall within the scope of the obligation, including legacy products still in the field
- A draft SBOM capability, even if the SBOM obligation itself activates later, because the SBOM is the technical substrate that makes the 24-hour clock survivable
The manufacturers who treat these as engineering and governance milestones, not as compliance checkboxes, will be the ones who do not call their first 24-hour clock at 23 hours and 47 minutes after awareness.
The Broader Architecture
The Cyber Resilience Act is, in its broader design, the EU response to a decade in which product security obligations fell unevenly across sectors. Finance got DORA. Critical infrastructure got NIS2. Products generally got nothing, except for sector-specific medical device, automotive, and machinery regulations. The CRA closes that gap by extending product security obligations across the entire EU market, regardless of sector, for any product with digital elements.
This horizontal extension is, in practice, the most significant cybersecurity regulatory development of the EU since the GDPR. The GDPR moved the legal architecture of data protection from a national, sector-specific patchwork to a horizontal, EU-level frame. The CRA does the equivalent for product cybersecurity. The September 11, 2026 deadline is the first binding moment of that architectural shift.
September 11, 2026 is, on a calendar that contains many regulatory milestones, the one that the product security community should be planning around between now and the summer. The 24-hour reporting cadence is short, the scope is broad, the architecture is centralized, and the readiness gap is documented.
The manufacturers who treat the deadline as an internal product-security milestone, not as a compliance checkbox, will be ready. The others will discover, in their first post-deadline incident, that the 24-hour clock starts when ENISA decides it does, not when their internal review is complete.
Four months is enough time to be ready. It is not enough time to start.
All my books on cybersecurity and governance are here 👉 https://www.amazon.it/stores/author/B0FB47T6Q4/allbooks