As of 11 September 2026, manufacturers of software, IoT products and other products with digital elements face the first binding obligation under the EU Cyber Resilience Act. EU CRA vulnerability reporting under Article 14 requires an early warning to authorities within 24 hours of becoming aware of an actively exploited vulnerability or a severe incident. This obligation applies today, more than a year before the rest of the regulation, and it applies to products already on the market.

For CISOs, VP-level product security leaders, and compliance directors, the operational problem is not understanding the deadline. It is proving, on a Friday evening, that your organization can detect exploitation, assemble the required facts, secure internal approval, and file through an official EU platform inside 24 hours. That is an evidence and workflow problem before it is a security problem.

Certivo maps connected-product obligations like the CRA against your portfolio so reporting readiness is verifiable rather than assumed. If you want to understand your current exposure, you can request a compliance review of your CRA reporting readiness.

Key Takeaways

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

⏳ The obligation is two parallel cascades: 24-hour early warning, 72-hour notification, and a final report at 14 days (vulnerability) or one month (severe incident).

⚠️ Reporting is triggered by an actively exploited vulnerability or a severe incident, and the clock runs from awareness, not from a confirmed fix.

🔗 Reports go simultaneously to ENISA and the coordinating CSIRT through the single reporting platform under Article 16.

📊 Penalties reach €15 million or 2.5% of worldwide annual turnover under Article 64(2), the CRA's highest tier.

🏭 The obligation applies to all products with digital elements on the EU market, including legacy products shipped years ago.

🤖 Real-time component visibility is the operational foundation, because you cannot report in 24 hours what you cannot see.

What EU CRA Vulnerability Reporting Requires Under Article 14

Article 14 of Regulation (EU) 2024/2847 obliges manufacturers to report two categories of event: an actively exploited vulnerability in a product with digital elements, and a severe incident affecting the security of such a product. Importers and distributors are subject to their own inspection, monitoring, and cooperation obligations but are not addressees of the reporting and early-warning duties. The reporting duty falls on the manufacturer.

The clock is unforgiving because both 24-hour clocks start when the manufacturer becomes aware, including on a Friday evening. A process that assumes the decision will be taken at Monday's meeting fails at the very first step. Awareness, not confirmation of a fix, is the trigger.

This is why continuous component monitoring matters operationally. You cannot report within 24 hours what you cannot see in real time, and detection capability is what turns a legal obligation into an achievable one. Certivo's approach to continuous compliance monitoring treats connected-product obligations as an ongoing readiness state rather than a periodic check, which is the posture Article 14 assumes.

Two Reporting Cascades, Not One

A frequent and material misreading is to treat Article 14 as a single four-step chain. It is not. There are two parallel cascades of three reports each, and the last report in each is counted from something different.

The final-report trigger is the detail teams most often get wrong. For a vulnerability, the 14 days do not run from the discovery of the vulnerability, nor from the 72-hour notification, but from the availability of the fix or mitigation.

What the 24-Hour, 72-Hour, and Final Reports Must Contain

Each stage carries a different evidentiary burden. The 24-hour early warning is deliberately thin. The later stages demand structured technical and business facts that are difficult to assemble under pressure unless they already exist in a retrievable form.

The 72-hour notification is where evidence retrieval becomes the bottleneck. Article 14(8) of the CRA requires them to inform affected users, so the organization needs to think in advance about how they would do this. User notification is a parallel obligation running alongside the authority-facing cascade, not a later step.

For manufacturers of connected products, the practical readiness question is whether product identification, component inventory, and affected-market data can be produced on demand. This is the same audit-ready documentation discipline that applies across other frameworks: time-stamped records, known evidence ownership, and point-in-time retrievability.

CRA Article 14 vulnerability reporting two-cascade structure for manufacturers

Click on image to view full

Where the Report Goes: ENISA and the CSIRT Coordinator

Reports have two recipients but one submission. Article 14(1) CRA obliges the manufacturer to report an actively exploited vulnerability simultaneously to the CSIRT designated as coordinator and to ENISA. For severe security incidents, paragraph 3 says the same.

The technical route is the ENISA Single Reporting Platform (SRP), established under Article 16. Reports go to ENISA and to the CSIRT designated as coordinator, through a single entry point rather than separate filings to each national authority.

Which member state's CSIRT coordinates is determined by a cascade. What governs is the member state where the authorised representative sits for the largest number of products. Failing that, the importer. Failing that, the distributor. If that remains open, the member state with the most users decides. Manufacturers should determine their coordinating CSIRT in advance, not during an incident.

One nuance security leaders should understand: a receiving CSIRT can pause the dissemination of a reported vulnerability, but that does not pause your filing clock. You cannot delay filing; the 24-hour, 72-hour and final-report windows run from awareness. What you can do is flag sensitivity, which limits who sees the content.

The Penalty Exposure Under Article 64

Article 14 sits in the CRA's highest enforcement tier. Article 64 puts failures of the Article 13 and 14 obligations, alongside the Annex I essential requirements, at administrative fines of up to €15,000,000 or 2.5% of total worldwide annual turnover, whichever is higher.

There is a narrow carve-out. Microenterprises and small enterprises are not fined for missing the 24-hour early warning specifically, under Article 64(10), but the obligation to report still applies to them.

For a board or CFO, the exposure calculation is straightforward: a turnover-linked ceiling on a reporting failure means the financial risk scales with company size, and it attaches to a process failure rather than to the underlying security event. A well-run vulnerability response that misses the 24-hour filing window is still a reportable breach.

Scope: Legacy Products Are Included

The most consequential scoping point is retroactive reach. Products placed before December 11, 2027 are not retroactively subject to the Cyber Resilience Act unless they undergo a "substantial modification" after that date; vulnerability/incident reporting in Article 14 applies earlier to all products, including legacy ones, from September 11, 2026.

This means a router, industrial controller, or software product on sale today falls within the reporting obligation the moment an actively exploited vulnerability is identified, regardless of when it shipped. For manufacturers with long-lived industrial or connected product fleets, the readiness question spans the entire installed base, not just new releases.

The EU Cyber Resilience Act framework overview sets out how these obligations interact with the broader secure-by-design requirements that follow in December 2027. And as we have written in why the CRA is not just a cyber law, the reporting obligation pulls compliance, engineering, and product security into a single accountable workflow.

The Commission Guidance and What It Does Not Change

On 27 July 2026, the European Commission published its first official application guidance. It is the Commission's most substantial interpretive document on the CRA so far, and it lands less than seven weeks before the first hard deadline. The guidance changes no obligation and no date.

Issued as Communication C(2026) 5252 with a detailed annex, the guidance clarifies scope questions including remote data processing solutions and free and open source software, what constitutes a "substantial modification," how support periods should be understood and applied, and how to meet reporting obligations and risk assessment requirements. It is non-binding but authoritative as a statement of Commission interpretation.

The practical takeaway for compliance directors: the guidance resolves interpretive ambiguity, but it does not soften the timeline or the evidentiary burden. Readiness work planned on the assumption of a delay is misplaced.

Building the Evidence System: A Readiness Checklist

Article 14 compliance is an operational capability, not a document. The following capabilities determine whether a manufacturer can actually file within the window.

📄 Detection and awareness

• Continuous monitoring of components and dependencies so that active exploitation is visible, not discovered late

• A defined trigger for when "awareness" begins, since the clock runs from it

📊 Evidence retrieval

• Product identification and affected-market data available on demand

• Component inventory and version mapping retrievable per product

• Historic, time-stamped records of product state

⏳ Decision and authorization

• A named person with authority to file, available outside business hours

• A pre-agreed triage and approval path that fits inside 24 hours

🔗 Filing readiness

• Coordinating CSIRT identified in advance

• ENISA SRP registration and EU Login credentials in place

• A parallel process for Article 14(8) user notification

📌 Governance

• Ownership assigned across product security, compliance, and legal

• Dry-run rehearsal of the 24-hour scenario before it is real

Manufacturers managing connected-product portfolios can use Certivo to hold this evidence in a centralized compliance data backbone, so that the facts required for a 72-hour notification are retrievable rather than reconstructed under pressure. CORA-powered regulatory intelligence tracks how obligations like the CRA map to your product scope, which shortens the assessment step when an incident lands.

How Certivo Supports CRA Reporting Readiness

The CRA does not reward organizations that understand the rule. It rewards those that can execute under a 24-hour clock. The gap between the two is an evidence-retrieval and workflow problem.

Certivo functions as a system of record for connected-product compliance. It maps CRA obligations against your portfolio, holds the product and component evidence that the 72-hour and final reports demand, and maintains time-stamped, audit-ready records so that response time is spent on the incident, not on assembling facts. CORA, its embedded regulatory intelligence, keeps the mapping between obligation and product current as guidance evolves. The goal is not to eliminate incidents. It is to make 24-hour reporting operationally possible and to reduce the surprises that turn a security event into a compliance breach.

To assess where your organization stands against the 11 September 2026 obligation, speak with a compliance specialist about a CRA reporting readiness review.