Is Your Product Ready?
Most manufacturers believe they have until December 2027 to comply with the EU Cyber Resilience Act. That assumption could cost them dearly. The first, fully enforceable obligation goes live on 11 September 2026. Less than 6 months from now to comply to CRA Vulnerability Reporting.
The EU Cyber Resilience Act (CRA) entered into force on 10 December 2024 and represents the most significant shift in product cybersecurity regulation Europe has ever seen. It establishes binding and enforceable security requirements. These apply to any hardware or software product on the EU market containing digital elements. This includes products ranging from smart home sensors and industrial controllers to firmware, routers, and connected medical devices.
While the full set of CRA obligations only applies from 11 December 2027, a critical pillar is much closer. Article 14 vulnerability and incident reporting becomes mandatory on 11 September 2026. If you manufacture, import, or distribute products with digital elements and sell them in the EU, that deadline applies to you, including for products already on the market.
1. What Is the Cyber Resilience Act, and Who Does It Cover?
The CRA (Regulation EU 2024/2847) establishes horizontal cybersecurity requirements for products with digital elements. Unlike previous frameworks such as ISO 27001 or IEC 62443, which were voluntary or sector-specific, the CRA is:
- Mandatory — non-compliance results in enforcement and fines up to €15 million or 2.5% of global annual turnover, whichever is higher.
- Horizontal — it cuts across all industries and product categories without distinction.
- Lifecycle-binding — obligations don’t end at market placement but continue throughout the product’s support period.
In practice, the CRA covers an enormous range of products:
- Consumer electronics: laptops, smartphones, tablets, smart speakers, routers
- Smart home devices: connected cameras, smart locks, baby monitors, smart thermostats
- IoT and sensors: smart meters, industrial sensors, cameras, industrial control systems
- Software and firmware: operating systems, mobile apps, desktop software, SDKs
- Components: processors, graphics cards, semiconductors
Notably, the regulation also applies to legacy products — those already on the market before December 2027. From September 2026, if an actively exploited vulnerability is discovered in a product you shipped in 2019, you are still required to report it.
Key exclusion: products already regulated by sector-specific cybersecurity rules (medical devices, automotive, civil aviation, marine equipment) fall outside the CRA’s scope.
2. The September 2026 Deadline: What Triggers CRA Vulnerability Reporting?
Starting 11 September 2026, manufacturers must report two types of events to the relevant national CSIRT (Computer Security Incident Response Team) and simultaneously to ENISA, via the new Single Reporting Platform (SRP):
a) Actively exploited vulnerabilities
These are vulnerabilities for which there is reliable evidence of malicious exploitation in the wild — for example, when a CVE in one of your product’s components appears in the CISA Known Exploited Vulnerabilities (KEV) catalog and is confirmed to affect your product. This applies even to components built by third parties and included in your firmware or software stack.
b) Severe incidents impacting product security
These are cybersecurity incidents where the product’s security is materially affected, or where the incident enables (or could enable) execution of malicious code in the product or in user systems connected to it.
The CRA Vulnerability Reporting deadlines are extremely tight and tiered:
- 24 hours: Early warning — notify CSIRT of the existence of the vulnerability or incident as soon as you become aware of it.
- 72 hours: Full notification — provide details including vulnerability description, CVE identifier (if available), affected product versions, evidence of exploitation, potential impact, and any available mitigation.
- 14 days (vulnerability) / 1 month (severe incident): Final report — submitted after a corrective measure is available or the incident is resolved.
Important: CRA notifications do not replace GDPR reporting obligations. If the incident involves personal data, a separate notification to the supervisory authority is typically required within 72 hours under GDPR. NIS 2 reporting obligations may also apply simultaneously.
3. The SBOM Problem: You Can’t Report What You Don’t Know
Here is the core operational challenge: to meet the 24-hour early warning obligation, you need to know, within hours of a vulnerability disclosure, whether your product is affected. This is impossible without a Software Bill of Materials (SBOM).
An SBOM is a structured, machine-readable inventory of every software component, library, open-source package, and third-party dependency inside your product. Think of it as an ingredients label for your firmware or software stack.
The CRA makes SBOMs a formal requirement under Article 13 and Annex I. Manufacturers must:
- Generate a machine-readable SBOM covering at least top-level dependencies.
- Keep it up to date throughout the product’s lifecycle.
- Provide it to market surveillance authorities on request.
- Use it as the foundation for ongoing vulnerability monitoring.
Without an SBOM, the scenario plays out like this: a critical OpenSSL vulnerability is added to the KEV catalog. Your IoT gateway shipped in 2022 uses that version of OpenSSL. But unless you have a complete, maintained SBOM and an automated monitoring pipeline, you won’t know your product is affected until it’s too late to meet the 24-hour window.
According to ENISA, approximately 72% of IoT vulnerabilities originate in third-party components. A product with no SBOM has no reliable way to surface those vulnerabilities in time to comply.
The practical implication is significant: SBOM readiness is a prerequisite for CRA vulnerability reporting compliance. If you intend to meet the September 2026 deadline, you need your SBOM pipeline operational before that date, which means starting now, if you haven’t already.
Recommended SBOM formats
The CRA does not mandate a specific format, but regulators strongly recommend standardized machine-readable options. The three dominant formats in use are:
- CycloneDX — widely favored for embedded systems and firmware because of its alignment with hardware/firmware component models.
- SPDX — strong in software and open-source contexts; well-supported by tooling.
- SWID — used mainly for enterprise software identification.
For most product compliance engineers working in embedded or IoT hardware contexts, CycloneDX is the practical starting point.
4. The ENISA Single Reporting Platform (SRP)
One of the practical improvements introduced by the CRA is the Single Reporting Platform (SRP), managed by ENISA. Instead of navigating different national reporting channels, manufacturers submit a single notification through the SRP, which is then routed to the appropriate CSIRT in the country of the manufacturer’s main EU establishment.
The SRP will be operational by 11 September 2026. A testing period will be available before that date, which manufacturers are strongly encouraged to use to validate their reporting workflows before enforcement begins.
Key aspects of the SRP:
- Single point of submission — one report satisfies obligations to both the national CSIRT and ENISA, unless exceptional circumstances apply.
- Coordinated dissemination — ENISA makes the information available across the EU cybersecurity ecosystem to enable coordinated response.
- Available for testing — manufacturers can familiarise their teams with the platform workflow before the September deadline.
5. The Full CRA Vulnerability Reporting Timeline at a Glance
| Phase | Date | What It Means for You |
| CRA enters into force | 10 Dec 2024 | Regulation is law. Preparation clock starts. |
| Conformity body notifications | 11 Jun 2026 | Member States designate notified bodies for assessments. |
| ⚠ CRA Vulnerability Reporting LIVE | 11 Sep 2026 | 24/72h reporting obligations fully enforceable. |
| Full CRA compliance | 11 Dec 2027 | All products placed on market must meet CRA requirements + SBOM. |
6. What Compliance Engineers Need to Do Now
If your products have digital elements and are sold in the EU, here is the practical sequence to follow before September 2026:
Step 1 — Scope your portfolio
Audit every product you place on the EU market that contains digital elements. This includes not only new products but legacy ones still generating revenue. Determine which fall under CRA scope and which are excluded (e.g., class III medical devices, type-approved vehicles).
Step 2 — Build your SBOM pipeline
Generate SBOMs for every in-scope product using a machine-readable format (CycloneDX or SPDX). This is not a one-time exercise, the SBOM must be kept current and tied to your development and release process. Connect it to CVE feed monitoring and vulnerability databases to enable automated alerting.
Step 3 — Define your ‘awareness’ trigger
The 24-hour clock starts when you ‘become aware’ of an actively exploited vulnerability. Internally, this means defining clearly what constitutes awareness, who in your organization receives CVE feeds, how alerts are triaged, and who has authority to classify a vulnerability as ‘actively exploited in the wild’ with respect to your specific product.
Step 4 — Draft reporting templates and workflows
Create pre-structured templates for the 24-hour early warning, 72-hour full notification, and final reports. Define ownership and escalation chains. Test the process end-to-end before September 2026.
Step 5 — Register on the ENISA SRP and test
Familiarise your team with the Single Reporting Platform ahead of the go-live date. Use the testing period ENISA will provide to validate that your workflow produces compliant, correctly structured notifications.
Step 6 — Check for regulatory overlap
Map your CRA reporting obligations against your existing GDPR incident response and NIS 2 obligations. In many cases, a cybersecurity incident will trigger simultaneous reporting requirements under multiple frameworks. Coordinate these into a unified incident response protocol to avoid missed deadlines or conflicting disclosures.
7. Pre-September 2026 Readiness Checklist
Use this CRA Vulnerability Reporting checklist to assess your current readiness against the September 2026 reporting obligation:
| Action Item | Done? |
| Inventory all products with digital elements sold in the EU | ☐ |
| Identify which products have known or potential vulnerabilities | ☐ |
| Generate and maintain an SBOM for each product | ☐ |
| Set up automated vulnerability monitoring (CVE feeds, KEV catalog) | ☐ |
| Define internal escalation paths: who decides if a vuln is ‘actively exploited’? | ☐ |
| Draft reporting templates for the ENISA Single Reporting Platform (SRP) | ☐ |
| Establish a 24-hour early warning workflow | ☐ |
| Establish a 72-hour full notification process | ☐ |
| Define the 14-day final report procedure | ☐ |
| Align GDPR reporting processes (data breach overlap) | ☐ |
| Check NIS 2 overlap obligations | ☐ |
| Assign a dedicated CRA compliance owner internally | ☐ |
8. What Happens If You Miss It?
Non-compliance with CRA reporting obligations is not a technicality. Article 14 violations are enforceable from 11 September 2026. National market surveillance authorities are empowered to investigate, issue corrective orders, and impose financial penalties.
For serious violations, including failure to notify ENISA and the relevant CSIRT within the required timeframes, fines can reach:
- €15 million, or
- 2.5% of total global annual turnover for the preceding financial year, whichever is higher.
There is one exception: manufacturers qualifying as microenterprises or small enterprises may not be penalised for failing to meet the 24-hour early warning deadline specifically, although all other obligations still apply.
Note: Market access is also at risk. Products found to be non-compliant may be barred from the EU market, and CE marking, which from 2027 will incorporate CRA requirements, can be revoked.
TLDR, Conclusion
The EU Cyber Resilience Act is the most ambitious product cybersecurity regulation Europe has ever introduced. And while December 2027 may feel distant, the real operational urgency is September 2026, now less than six months away.
For compliance engineers, the core message is this: vulnerability reporting compliance is a process and infrastructure challenge, not just a legal one. You cannot report what you don’t know. And you cannot know what’s in your product without a complete, maintained, automated SBOM pipeline.
The manufacturers who will be ready on 11 September 2026 are those who treat it as an engineering milestone, not a legal formality.
