The EU Cyber Resilience Act introduces the first cybersecurity reporting obligation in Europe measured in hours, not weeks. From September 11, 2026, manufacturers of products with digital elements must report actively exploited vulnerabilities and severe incidents to EU authorities on a strict clock. This is EU CRA vulnerability reporting, and it applies to your current product portfolio, including products you shipped years ago.

Most CRA coverage focuses on the December 2027 conformity deadline. For product security and compliance leaders, that is the wrong date to plan around first. The reporting obligation under Article 14 arrives fifteen months earlier and carries the same maximum penalty as the essential cybersecurity requirements.

If you want to understand your current exposure before the deadline, you can book a compliance risk assessment to map which products, components, and suppliers fall in scope.

Key Takeaways

📌 EU CRA vulnerability reporting under Article 14 applies from September 11, 2026, well ahead of the December 11, 2027 full-application date.

⏳ Manufacturers must submit a 24-hour early warning, a 72-hour full notification, and a final report to ENISA and their national CSIRT.

⚠️ Reporting is triggered only by an actively exploited vulnerability or a severe incident, not by every CVE or routine patch.

🔗 The obligation applies retroactively to products already placed on the EU market before December 2027.

📄 The software bill of materials and vulnerability handling policy are Article 13 and Annex I duties that bind from December 2027, but you cannot meet the 24-hour window without them.

⚠️ Non-compliance sits in the top penalty tier: up to €15 million or 2.5% of global annual turnover, whichever is higher.

🤖 You cannot report in 24 hours what you cannot see in real time, which makes continuous component monitoring the operational foundation of CRA readiness.

What the EU Cyber Resilience Act Requires

The Cyber Resilience Act, formally Regulation (EU) 2024/2847, is EU product cybersecurity law for connected products, referred to in the text as products with digital elements. It entered into force on December 10, 2024, and applies across the EU without national transposition.

Its obligations phase in over time. According to the European Commission's CRA summary, the notification of conformity assessment bodies applies from June 11, 2026, the Article 14 reporting obligations apply from September 11, 2026, and the full set of requirements, including essential cybersecurity requirements, conformity assessment, and CE marking, apply from December 11, 2027.

For security and compliance teams, September 2026 is the operative near-term date. It is a current-portfolio problem, not a future-product problem. Certivo's EU Cyber Resilience Act framework page breaks down the wider obligation set, and our analysis of why the CRA is not just a cyber law explains why product and compliance functions must coordinate early.

The 24-Hour and 72-Hour Reporting Mechanics

Article 14 establishes a staged reporting timeline. When a manufacturer becomes aware of a reportable event, the clock starts. Based on the European Commission's reporting guidance, the sequence is as follows.

• 24 hours: An early warning notification to ENISA and the relevant national CSIRT, from the moment of awareness.

• 72 hours: A fuller notification, including corrective or mitigating measures taken.

• Final report: No later than 14 days after a corrective or mitigating measure is available for an actively exploited vulnerability, and within one month of the initial notification for a severe incident.

Reports are filed through the ENISA Single Reporting Platform established under Article 16, a centralized system that routes simultaneous notification to ENISA and the designated Member State CSIRT. The platform was still being finalized in mid-2026, which is one more reason to prepare internal workflows now rather than waiting for the published mechanics.

The practical challenge is speed. Twenty-four hours does not leave room for internal escalation debates. Teams need to know in advance who decides a report is due, who drafts it, and who submits it. This is where continuous compliance monitoring and audit readiness shift from a nice-to-have to a hard operational requirement.

CRA 24-hour and 72-hour vulnerability reporting timeline for manufacturers

Click on image to view full

Actively Exploited Vulnerability vs. Severe Incident

The two reporting triggers are narrower than they first appear, and the distinction matters for scoping your process correctly.

What counts as an actively exploited vulnerability

The CRA defines a vulnerability as a weakness, susceptibility, or flaw that can be exploited by a cyber threat. An actively exploited vulnerability is narrower: it is a vulnerability for which there is reliable evidence that a malicious actor has exploited it in a system without the system owner's permission.

The obligation is not triggered by every vulnerability in a product. A flaw you discover and patch before exploitation is managed through your ordinary vulnerability handling process, not through Article 14 reporting. The report is required only once you become aware that the vulnerability is being exploited in the wild.

What counts as a severe incident

A severe incident is an incident that has a negative impact on the security of a product with digital elements. Like the vulnerability trigger, it runs on the 24-hour and 72-hour clock, with a final report due within one month.

A common source of confusion is that a vulnerable component may sit deep in your dependency tree. If an open-source library inside your product carries an actively exploited flaw, you as the manufacturer of the finished product are legally obligated to report it, even though you did not write the vulnerable code. That responsibility is what makes multi-tier supply chain transparency central to CRA readiness. Our guide on Cyber Resilience Act vs. product compliance covers this engineering-to-compliance handoff in more depth.

Where the SBOM Fits, and When It Legally Applies

There is a widespread misconception that the software bill of materials becomes a legal requirement on September 11, 2026. It does not. Getting this right matters for planning and for credibility with auditors.

Article 14 itself contains no duty to maintain an SBOM, publish a coordinated vulnerability disclosure policy, or actively monitor for vulnerabilities. Those duties sit in Article 13 and Annex I Part II, which apply from December 11, 2027. Annex I Part II point 1 requires a machine-readable SBOM covering at least the top-level dependencies, kept current for the support period. Per BSI guidance, the SBOM does not have to be published, but it must be available to market surveillance authorities on request.

Here is the operational reality, and it is the point most manufacturers miss. To report an actively exploited vulnerability within 24 hours, you must know exactly which components exist in your products. To know that, you need an accurate, continuously updated component inventory. The SBOM is therefore a practical prerequisite for the September 2026 reporting obligation, even though the legal SBOM deadline is December 2027. Teams that wait until 2027 to build component inventory pipelines will not be able to meet the 24-hour window in 2026.

This connects directly to BOM-level compliance intelligence and continuous dependency tracking. Certivo's approach to BOM-level compliance applies the same principle used for material content to software components: you cannot report on what you did not know you shipped.

If your current process depends on manual spreadsheets, our overview of moving from spreadsheets to AI-powered compliance systems outlines why that model cannot scale to 24-hour reporting.

CRA vulnerability reporting versus vulnerability handling deadlines for manufacturers

Click on image to view full

Who Is In Scope and Which Industries Are Affected

The CRA applies to products with digital elements placed on the EU market, meaning almost any hardware or software product that can connect directly or indirectly to a device or network. That is a wide net.

The reporting obligation is felt most acutely by:

🏭 Electronics manufacturers shipping connected devices and embedded systems.

🏭 Semiconductor and high-tech producers supplying components with firmware.

🏭 IoT and industrial automation vendors with fielded, long-lived products.

🏭 Medical device manufacturers with connected equipment and software.

The retroactive scope is the part that catches teams off guard. Under Article 69(3), the Article 14 reporting requirements apply to products already placed on the EU market before December 11, 2027. A product that shipped in 2019 and is still in use is in scope for reporting from September 2026 if it contains an actively exploited vulnerability. This is why a centralized compliance data backbone covering your full active portfolio, not just new releases, is essential.

CRA Penalties and Enforcement Exposure

Enforcement occurs primarily at national level. Each Member State designates market surveillance authorities that operate under the Market Surveillance Regulation (EU) 2019/1020, which provides the procedural basis for inspections, information requests, and corrective measures.

Article 64 sets a three-tier penalty structure.

Reporting obligations sit in the top tier. For a company with €1 billion in turnover, 2.5% equals €25 million, which exceeds the fixed ceiling. Beyond fines, authorities can order corrective action, withdrawal, recall, or restrictions on market availability. For many manufacturers, losing EU market access is the more serious consequence.

Documentation and Audit Readiness Under the CRA

Meeting the reporting clock is not only about detection. It is about being able to show your work under multiple forms of scrutiny.

Manufacturers face several audit types that intersect with the CRA: internal audits, customer audits driven by OEMs and enterprise buyers, regulatory inspections by market surveillance authorities and CSIRTs, and certification audits under standards such as ISO 9001 and, for security management, ISO/IEC 27001. Each asks a version of the same question: can you produce point-in-time evidence of what you knew and when.

Historic state tracking is fundamentally a data versioning problem. When an authority or customer asks what your component inventory looked like on a given date, you need immutable audit logs, time-stamped declarations, and point-in-time retrieval. Evidence chain integrity matters as much as the evidence itself: who submitted a component declaration, when it was submitted, and with what authority.

No software eliminates audit findings, and no platform is audit-proof. The realistic objective is to be audit-ready, reducing surprises and shortening response time from days to hours. Continuous audit-ready documentation and a customer-facing trust center, similar to the self-service models used by large technology and automotive OEMs, let you answer buyer security questionnaires without a fire drill each time. Certivo's stay audit-ready across frameworks approach is built around exactly this evidence discipline.

Compliance Preparation Checklist for September 2026

Use this checklist to close the gap before the deadline.

✓ Confirm scope. Identify every product with digital elements placed on the EU market, including legacy products still in use.

✓ Build component visibility. Establish a continuously updated software bill of materials for each product, covering at least top-level dependencies.

✓ Wire up monitoring. Match your components against known-vulnerability sources such as the NVD and the EU vulnerability database so an actively exploited flaw surfaces in hours.

✓ Define the reporting workflow. Assign the decision-maker, drafter, and submitter in advance, and pre-register for the ENISA Single Reporting Platform.

✓ Update incident response. Integrate the 24-hour, 72-hour, and final-report timelines into your existing plan, aligned with parallel NIS2 and GDPR obligations.

✓ Review supplier contracts. Add flow-down clauses so upstream suppliers notify you fast enough to meet your own 24-hour clock.

✓ Prepare documentation. Begin the vulnerability handling policy and security update process now, ahead of the December 2027 Article 13 deadline.

Struggling to see your component and supplier exposure across products? You can request a compliance review to pressure-test your readiness before the September window.

How AI-Native Compliance Automation Supports CRA Readiness

The CRA rewards manufacturers who can see their products in real time. That is a data and automation problem before it is a legal one.

Certivo functions as a compliance data backbone that unifies product, component, and supplier information across frameworks, from the CRA to REACH, RoHS, PFAS, and the Digital Product Passport. Rather than managing cyber obligations in a silo, teams manage them alongside material and environmental obligations in one system of record. Our overview of cybersecurity and digital compliance shows how these threads connect.

CORA-powered regulatory intelligence supports the reporting workflow in three ways. It applies regulatory intelligence and horizon scanning to track CRA developments, implementing acts, and harmonized standards as they publish. It uses AI document parsing and certificate validation to structure supplier evidence at scale, which our piece on automating supplier evidence collection for the CRA describes in practice. And it turns automated supplier data collection and portals into a repeatable process, so component and vulnerability data flows in continuously instead of being chased by email.

The result is a shift from reactive, periodic checks to continuous readiness. That shift is what makes 24-hour reporting operationally possible, because you cannot report what you cannot see. For the broader picture, see our guide to AI tools for compliance management and how Certivo helps manufacturers prepare for the CRA.

To see how continuous monitoring maps to your portfolio, speak with a compliance specialist.