"We still have time until end of 2027." I hear this in almost every conversation I have with manufacturers about the EU Cyber Resilience Act. It is understandable, December 2027 really is a central date. But it is dangerous, because it completely overlooks another deadline that hits in two months.
What happens on 11 September 2026?
The 11 September 2026 is the first real application deadline of the Cyber Resilience Act. On that day, the reporting duties for vulnerabilities and security incidents enter into force, set out in Article 14 CRA.
Concretely this means: manufacturers of products with digital elements must from that date report actively exploited vulnerabilities to ENISA (the EU Agency for Cybersecurity) within 24 hours of becoming aware of them. For severe security incidents an early warning applies within 72 hours, followed by a full closing report within one month.
These duties apply not only to products newly placed on the market from September 2026. They apply to all products with digital elements that are available on the EU market at that time. The PLC that has been running in a production plant for years. The smart home device the end customer bought back in 2023. The industrial gateway no one has touched since the last firmware update. All are affected.
What "December 2027" does not mean
December 2027 is the deadline for full CRA conformity. From that date, new products with digital elements that are placed on the market for the first time (so first made actually available on the EU market) must meet all CRA requirements. CE marking, full technical documentation, conformity assessment procedure, security by design.
That is an important and demanding process that has to be prepared today. But it primarily concerns new products and the development process.
September 2026 is different. This deadline affects ongoing operations, all products already on the market today. It is about operational processes, not product development. Anyone who today has no vulnerability management cannot build that process in two weeks.
For both deadlines and the full CRA roadmap, see the article on the CRA compliance roadmap 2026/2027.
What concretely must be in place by September
To meet the reporting duties on 11 September 2026, you need four building blocks that work together.
Building block 1: An SBOM for all your products. An SBOM (Software Bill of Materials) is a complete inventory of all software components contained in a product, including all open source libraries, third-party components, and dependencies. Without an SBOM you do not know what is in your product. And without that knowledge you cannot monitor vulnerabilities. The SBOM is the foundation for everything else. For more, see the SBOM guide for IoT manufacturers.
Building block 2: Ongoing CVE monitoring. CVEs (Common Vulnerabilities and Exposures) are publicly known security flaws in software components. New CVEs are published daily. To be able to react within 24 hours, you must continuously monitor whether a newly known vulnerability affects components used in your products. That is not a one-time scan, but a permanent process. A structured starting point is the vulnerability management guide under the CRA.
Building block 3: A clear internal escalation path. 24 hours is a short window. It is not enough if responsibility, reporting decision, and how to file the report technically only get clarified at that moment. This process must be defined, documented, and tested before the first incident. Who reports internally? Who signs off? Who contacts the authority?
Building block 4: An established ENISA reporting channel. ENISA operates a single entry point platform for reports. You must know this channel, have your company registered there, and understand the procedures for timely submission before you need it for the first time. In parallel the BSI as the national authority is relevant. These contact paths should also be prepared.
Myth vs. fact
Myth: The CRA only becomes relevant by end of 2027. We still have enough time to start.
Fact: On 11 September 2026 the reporting duties for actively exploited vulnerabilities and severe security incidents enter into force. They apply to all products with digital elements on the EU market, regardless of when they were produced or placed on the market. Anyone who today has no functioning vulnerability management is not compliant in two months.
Three steps to start now
1. Take stock of your SBOMs. Check for every product line whether a current SBOM exists. If not, creation should be a priority now. An SBOM is not only a CRA requirement, it is the precondition for any further compliance work. Start with your best-selling or most widely deployed products and work outward from there.
2. Fix responsibilities in writing. Define internally who is responsible for the reporting duties. That covers: Who monitors incoming CVE advisories? Who decides whether a vulnerability is actively exploited and therefore reportable? Who writes the report and submits it within the deadline? These roles must be clearly named and known to those involved.
3. Document the process and rehearse it once. A process that only exists in someone's head does not help under time pressure. Document the flow, from detecting a vulnerability to submitting the report. Then simulate an incident internally once. How long does it take until the report would be ready? Where are the bottlenecks? Two months is little, but enough for an initial functioning structure.
What does this mean for your CRA roadmap?
The CRA has two central deadlines that trigger different requirements.
On 11 September 2026 the reporting duties enter into force. They apply to all manufacturers whose products with digital elements are available on the EU market.
On 11 December 2027 full CRA applicability enters into force. From that date all newly placed products with digital elements must meet the full CRA requirements, including CE marking and conformity assessment.
The most common planning mistake: companies treat the CRA as one big project with target date 2027. In reality it is two separate strands of requirements with different deadlines and different operational consequences. Anyone looking only at 2027 today misses that they are already subject to reporting duties in two months.
For more on the financial consequences of non-compliance, see the article on CRA fines and sanctions.
Frequently asked questions
Do the reporting duties also apply to products developed before the CRA? Yes. The CRA reporting duties do not attach to the development or production date, but to whether the product is available on the EU market at the deadline. There is no grandfathering by production date.
What exactly is an "actively exploited vulnerability" under the CRA? A vulnerability is considered actively exploited when there are indications that attackers are actually using it to compromise systems. Relevant sources include the CISA Known Exploited Vulnerabilities Catalog or corresponding CERT advisories. The CRA leaves interpretive room here, but EU guidance is clear: in doubt, report.
What happens if I do not report a vulnerability in time? Untimely reports can be treated as CRA breaches and trigger fines. The exact sanction practice is set by the national market surveillance authorities. The amount of fines can be significant.
Do I have to report to ENISA or to the BSI? The CRA envisages ENISA as the central reporting recipient. At the same time, national authorities such as the BSI in Germany are involved. The exact reporting structure via the ENISA Single Entry Point is currently being detailed. It is advisable to prepare both channels.
Do I really need an SBOM, or is an informal component list enough? An informal list is not enough for the reporting duties. First, because you cannot run reliable monitoring without structured CVE monitoring. Second, because Article 13 CRA explicitly requires an SBOM as part of the technical documentation. An SBOM in a standardised format (such as SPDX or CycloneDX) is the right path.
Conclusion
The 11 September 2026 is no longer an abstract future. It is two months away. And it means: anyone who at that point has no SBOM, runs no CVE monitoring, and has no defined escalation path is not compliant, regardless of what is still planned for 2027.
The good news: two months is tight, but enough to build an initial functioning structure. The condition is that you start now.
An automated compliance platform like Kunnus helps systematically map SBOM creation, CVE monitoring, and reporting processes, before the deadline tips from theory into practice. A starting point is our free CRA compliance check.
Every Friday I debunk a CRA myth here.