From 11 September 2026, a qualifying product-security event can trigger an EU early warning within 24 hours. Companies need product lineage, decision rights and rehearsed reporting, not another generic incident policy.
Standfirst
The Cyber Resilience Act’s first operational deadline arrives before its main product obligations. From 11 September 2026, manufacturers must report actively exploited vulnerabilities and severe incidents affecting products with digital elements through the EU Single Reporting Platform. The early-warning clock is short enough to expose weak product inventories, unclear manufacturer roles and fragmented security evidence. A focused readiness sprint can turn the deadline into a stronger product-security operating model.
Why the September 2026 CRA deadline is different
The Cyber Resilience Act is a horizontal framework for hardware and software products made available on the EU market. Most obligations apply from 11 December 2027, but the reporting duties start earlier. European Commission reporting guidance states that, from 11 September 2026, manufacturers must report actively exploited vulnerabilities and severe incidents having an impact on product security.
The timing is demanding: an early warning is due within 24 hours of awareness and a fuller notification within 72 hours. For an actively exploited vulnerability, the final report is due no later than 14 days after a corrective or mitigating measure becomes available; for a severe incident, it is due within one month, according to the Commission’s reporting page. These are not simply legal deadlines. They are data-availability deadlines.
A company cannot decide quickly if it does not know which legal entity is the manufacturer, which products and versions contain the affected component, where those products are available, who owns the fix, and whether available evidence crosses a reporting threshold. The programme therefore belongs in product engineering and operations as much as in legal or cybersecurity.
Start with role and product scope
The first readiness task is to identify where the company acts as a manufacturer. Brand ownership, software distribution, hardware integration and substantial modification can create responsibilities that do not align neatly with internal business-unit boundaries. A group may be a manufacturer for one product, a distributor for another and a commercial user of a third-party service elsewhere.
The Commission’s CRA implementation FAQ describes the framework as applying to hardware and software products with digital elements made available on the Union market, including final products and components placed on the market separately. Companies should turn that legal framing into a controlled product register, not rely on a procurement list or software asset inventory designed for another purpose.
For each in-scope product family, record the manufacturer entity, responsible product owner, product type, versions in support, EU markets, distribution routes, important or critical classification where applicable, support period, security contact, build repositories, component evidence and incident channels. The register should also flag products whose scope or role needs counsel review. An unresolved flag is useful; a hidden assumption is not.
Map components to shipped products
Reporting decisions often begin with a component alert. The operational question is which shipped products contain the component, in which versions and configurations, and whether exploitation is relevant to the product’s actual exposure. Software bills of materials can help, but a static document at release is insufficient. Companies need versioned lineage connecting source and third-party components to builds, releases, customers or distribution regions, and current support status.
The minimum viable capability is a query that product security can run under pressure: given a component and affected version range, return candidate product releases, owners and markets, along with confidence and evidence gaps. That output drives triage, customer protection and reporting. It also exposes suppliers whose advisories lack usable identifiers or version detail.
Define the two reportable event tests
The regulation and guidance distinguish an actively exploited vulnerability from a severe incident. ENISA’s Single Reporting Platform information describes the first as a vulnerability for which reliable evidence indicates exploitation by a malicious actor, and the second as an incident with a severe impact on product security, including availability, authenticity, integrity or confidentiality.
Companies should translate those definitions into decision trees approved by product security, incident response and legal teams. The tree should specify evidence sources, required facts, who may conclude that a threshold is met, and who may submit when facts remain incomplete. The 24-hour early warning is designed for incomplete information; waiting for root cause or a finished patch can itself create failure.
· Event identity: vulnerability or incident, first awareness time, reporter and evidence source.
· Product impact: affected products, versions, components, security properties and supported markets.
· Threshold evidence: reliable exploitation evidence or facts supporting severity, with confidence and open questions.
· Immediate action: mitigations, customer guidance, containment, patch status and sensitive information handling.
· Decision record: accountable decision maker, rationale, platform submission status and next deadline.
The company should define “awareness” operationally and preserve the timestamp. Alerts arrive through researchers, customers, suppliers, telemetry, bug bounties, support teams and public advisories. A central intake route helps, but it must not become a queue that delays escalation. Local teams need a clear trigger for paging the CRA response group immediately.
Build a 24-hour operating rhythm
Hours 0-4: establish facts and ownership
Open a product-security case, preserve the awareness timestamp and assign an incident lead. Confirm the potential manufacturer entity, affected product owner and relevant security specialists. Capture the source, vulnerability or incident identity, exploitation evidence, product exposure and immediate customer risk. At this stage the objective is a shared factual record, not a polished narrative.
Hours 4-12: decide, contain and draft
Apply the approved threshold tests. Run component-to-product queries, validate versions and markets, and determine the receiving CSIRT based on the manufacturer’s main establishment. Begin containment or mitigation without waiting for the report. Draft the early warning from structured case data so the submission and internal record do not diverge.
Hours 12-24: challenge and submit
A second qualified reviewer should challenge the event type, scope, awareness time and rationale. Executives do not need to rewrite the report, but the accountable decision maker should confirm submission or record a reasoned non-reporting conclusion. Submit through the Single Reporting Platform, preserve acknowledgement and schedule the 72-hour workstream.
ENISA says the platform will act as a single entry point and route notifications to the selected CSIRT and ENISA, subject to exceptional handling provisions. Its published information also says no API will be provided at the initial stage. Companies planning high-volume automation should therefore prepare structured internal data and controlled browser-based submission, while watching the platform guidance for operational changes.
Treat the 72-hour notification as a data product
The fuller notification should be assembled from the same case record, not recreated in a separate compliance document. By 72 hours the company should refine affected products and markets, the nature of the vulnerability or incident, exploitation or impact, corrective and mitigating measures, user actions and sensitivity considerations. Ownership of each field should be preassigned.
A practical data model links the event, product, versions, component, markets, manufacturer entity, evidence, customer communications, mitigation, patch and submissions. Every update should be timestamped. This supports the final report and enables consistent answers when multiple authorities, partners or customers ask related questions. It also prevents unverified detail from entering public advisories merely because it appeared in an early internal chat.
Sensitive vulnerability information requires deliberate handling. The response team should separate facts needed for regulatory coordination from exploit-enabling technical detail and from customer instructions. Security and legal review should be rapid and rule-based, with pre-agreed escalation for particularly sensitive cases rather than improvised redaction.
Connect reporting to product-security operations
The Commission’s July 2026 implementation update says its new guidance addresses scope, substantial modification, support periods, reporting and risk assessment. Companies should use the near-term reporting deadline to test the broader system they will need for the main 2027 obligations: secure development, vulnerability handling, support-period management and evidence.
The reporting playbook should connect to vulnerability disclosure, supplier security, engineering incident management, release management, customer support and communications. A supplier alert must become a product query; a triage decision must become a tracked engineering action; a patch must become a verified release and customer message; and the final report must reflect what was actually delivered.
Third-party components deserve a clear responsibility model. Product teams cannot outsource the reporting decision to a supplier, because the company’s product configuration, exposure and market role may differ. Supplier contracts and operating procedures should require timely identifiers, affected-version ranges, exploitation evidence, mitigation guidance and notice of changes. The company then assesses its own product and obligation.
Rehearse before the platform goes live
A tabletop exercise is the fastest way to expose missing data and authority. Choose a plausible scenario involving a widely used component, evidence of active exploitation and several product versions across EU markets. Start the clock from an out-of-hours alert. Require the team to identify the manufacturer, query affected products, apply the threshold, draft the 24-hour warning, assemble the 72-hour dataset and plan customer action.
· Measure time to accountable owner, product/version scope, reporting decision and submission-ready early warning.
· Record every manual lookup, unavailable owner, conflicting inventory and approval delay.
· Test alternates for holidays, leave and regional time zones, including platform credentials and secure access.
· Repeat the exercise after remediation and require evidence that the bottlenecks are closed.
Success is not a perfect first exercise. It is a reliable improvement loop. Senior management should see a short dashboard: in-scope product coverage, products with verified lineage, named response owners, exercise completion, median decision time, open evidence gaps and late actions. That makes CRA readiness an operating capability rather than a policy attestation.
A 30-day readiness sprint
· Week 1: confirm manufacturer roles, product scope, accountable executives and 24-hour decision authority.
· Week 2: build the minimum product-and-component register, awareness timestamp rule, decision tree and structured reporting record.
· Week 3: configure platform access, draft submission templates, align supplier and customer communications, and train the response group.
· Week 4: run an out-of-hours simulation, close priority gaps and obtain executive acceptance of residual risk before 11 September.
The September deadline should be treated as a production launch. Owners, credentials, support coverage, monitoring and rollback arrangements need the same discipline as a customer-facing system. The organisations best prepared will be those that can explain not only what their policy says, but how a specific product event moves from signal to decision, submission, mitigation and final evidence.
FAQ: CRA reporting 2026
When do the CRA reporting obligations start?
The reporting obligations for actively exploited vulnerabilities and severe product-security incidents apply from 11 September 2026, ahead of the main CRA obligations in December 2027.
What is due within 24 hours?
The manufacturer must submit an early warning after becoming aware of a reportable event. The process should preserve the awareness time and allow submission while technical investigation continues.
What is due within 72 hours?
A fuller notification is required, adding available information about the product, vulnerability or incident, exploitation or impact, and corrective or mitigating measures.
Do all vulnerabilities need to be reported?
No. The mandatory vulnerability trigger concerns actively exploited vulnerabilities. Companies still need a documented test and evidence trail for the decision.
Where are reports submitted?
Reports are submitted through ENISA’s Single Reporting Platform and directed to the relevant CSIRT, generally based on the manufacturer’s main establishment.
What should companies do first?
Confirm manufacturer roles and in-scope products, then build the product/component lineage and decision authority needed to reach a defensible answer inside 24 hours.
References:
1. Regulation (EU) 2024/2847: Cyber Resilience Act
2. European Commission: CRA reporting obligations
3. European Commission: CRA implementation frequently asked questions
4. European Commission: July 2026 CRA implementation guidance update