This article is intended as a general overview for product and security teams and does not constitute legal advice. Manufacturers should confirm their specific obligations with qualified counsel and monitor the European Commission and ENISA's official CRA pages for updates.
The Deadline Everyone Is Missing
The CRA (Regulation (EU) 2024/2847) entered into force on December 10, 2024, and its full set of obligations - CE marking, conformity assessment, technical documentation - apply from December 11, 2027. Most compliance planning has been built around that date.
But Article 14 of the CRA carves out a separate, much earlier obligation: mandatory vulnerability and incident reporting, which becomes enforceable on September 11, 2026. This is the CRA's first operational requirement with real teeth, and it applies to a far wider set of products than most manufacturers assume - including products that have been sitting on the EU market for years.
If your IoT gateway shipped in 2019 and a critical vulnerability in it starts being actively exploited in October 2026, you are legally required to report it. The age of the product doesn't matter. What matters is whether it's still available on the EU market on or after September 11, 2026.
What "Products with Digital Elements" Actually Covers
The CRA's scope is intentionally broad. It applies to hardware and software products whose intended or foreseeable use includes a direct or indirect data connection to a device or network. In practice, that spans consumer IoT devices, networking equipment, industrial and OT systems, medical devices with connectivity, embedded systems and firmware, and standalone software products.
Some categories - smartcards, tamper-resistant microcontrollers, and certain security-critical hardware - are classified as "important" or "critical" products and face stricter conformity requirements. But for the September 2026 reporting obligation specifically, the bar for who's affected is simple: if you place a connected product on the EU market, you're in scope.
What You're Actually Required to Report - and How Fast
Article 14 sets up a staged, time-boxed reporting cascade once a manufacturer becomes aware of an actively exploited vulnerability or a severe incident affecting one of their products:
| Stage | Deadline | What's Required |
|---|---|---|
| Early warning | Within 24 hours | Initial notification that a vulnerability is being actively exploited or a severe incident has occurred |
| Full notification | Within 72 hours | More detailed information on the nature and impact of the event |
| Final report | Within 14 days (vulnerabilities) or 1 month (incidents) | Full report once a corrective or mitigating measure is available |
Reports go through the CRA Single Reporting Platform (SRP), which routes the notification to the relevant national CSIRT and simultaneously makes it available to ENISA. Manufacturers report once - the platform handles distribution.
One important nuance: the reporting trigger is active exploitation, not just the existence of a CVE. A public proof-of-concept or a researcher's disclosure isn't enough on its own - the CRA requires evidence that a malicious actor actually exploited the vulnerability in the wild. That distinction matters, because it means you need a triage process capable of telling the difference under time pressure, not just a CVE feed.
Why You Can't Report What You Can't See
Here's the operational trap a lot of manufacturers are walking into: the reporting obligation starts in September 2026, but the SBOM (Software Bill of Materials) mandate technically isn't enforceable until the December 2027 full-application date. On paper, that looks like breathing room. In practice, it isn't.
To meet a 24-hour reporting window, you first have to know whether a newly disclosed, actively exploited vulnerability actually affects your product. Without a current, accurate SBOM mapping every component in a device - including third-party and open-source dependencies - that determination can take days, not hours. SBOM capability is a practical prerequisite for the 2026 deadline, even though it isn't formally required until 2027.
This is especially sharp for products carrying end-of-life dependencies - frameworks and libraries that have stopped receiving security patches from their maintainers but are still embedded in shipping products. If you don't know a component is there, you can't monitor it, and you can't report on it.
Penalties Are Not Symbolic
The CRA's enforcement structure mirrors GDPR in scale. Non-compliance with core obligations can carry fines of up to €15 million or 2.5% of global annual turnover, whichever is higher. Supplying incorrect, incomplete, or misleading information to authorities carries its own penalty tier, up to €5 million or 1% of global turnover. Certain other obligations - around importers, distributors, and documentation - carry penalties up to €10 million or 2% of turnover.
There's a narrow carve-out for microenterprises and small enterprises that miss the 24-hour early warning deadline, and open-source software stewards face a lighter regime. But for the vast majority of manufacturers selling connected products into the EU, the exposure is real and the enforcement mechanism is fast - a missed 24-hour window is the kind of failure that gets noticed in near-real time, not years later in an audit.
A Practical Readiness Checklist
With the deadline now measured in weeks rather than quarters, here's where to focus:
- Build a CRA-relevant product inventory covering new and legacy products, hardware and software, embedded components, and anything currently available on the EU market - regardless of when it was originally released.
- Generate SBOMs for every in-scope product using a machine-readable, commonly accepted format (SPDX or CycloneDX). This is the foundation everything else depends on.
- Stand up automated vulnerability monitoring against your SBOMs - you need continuous visibility into whether newly disclosed CVEs affect components you actually ship, not a quarterly manual review.
- Identify your reporting entity and escalation path, including a backup for when the primary contact is unavailable.
- Draft and pre-approve report templates for the early warning, full notification, and final report stages before you need them.
- Establish a Coordinated Vulnerability Disclosure (CVD) policy, including a public security contact point.
- Run a drill - measure your actual time from "vulnerability becomes known" to "report filed." Most organisations discover that 24 hours is not realistic with their current process.
- Validate your assumptions with independent testing - an SBOM tells you what's in a product, not what's exploitable. Penetration testing is how you find out whether a listed component is actually reachable and exploitable in your specific configuration.
Where This Connects to Security Testing
A compliance process built entirely on paperwork - SBOMs, policies, escalation charts - only tells you what you think is true about your product's security posture. It doesn't tell you what an attacker can actually do with it.
This is where independent security assessment earns its place in a CRA readiness programme: is that hardcoded credential in your firmware actually reachable from the network? Does that outdated library in your SBOM translate into a real exploitation path on your device? Would your team's current detection process actually catch active exploitation within 24 hours?
Conclusion
September 11, 2026 is not a soft deadline, and it's not the one most compliance roadmaps have been built around. If your product inventory, SBOMs, and reporting process aren't ready before then, the exposure is immediate rather than theoretical. The good news is that none of the steps above require years of lead time - they require starting now.
If you're mapping your product inventory against the September deadline and want an independent read on where the real exposure is - not just where the paperwork says it should be - we can help. Get in touch.