What happened
On 11 September 2026, Cyber Resilience Act Article 14 reporting obligations became applicable to manufacturers of products with digital elements placed on the European Union market. The CRA’s main product-security provisions remain scheduled to apply from 11 December 2027; today’s change is the earlier reporting regime. The European Commission identifies two triggering classes: actively exploited vulnerabilities and severe incidents affecting the security of a product with digital elements.
A covered manufacturer must submit an early warning within 24 hours, a full notification within 72 hours, and a final report within 14 days after a corrective measure for an actively exploited vulnerability or within one month for a severe incident. Notifications pass through the CRA Single Reporting Platform to the relevant CSIRT and ENISA, with dissemination to other affected Member State CSIRTs except where justified security grounds support delay.
ENISA states that the Single Reporting Platform launches without an application programming interface, so initial submissions must use the platform interface. That limitation is operationally significant for enterprises that planned to integrate regulatory notification into ticketing, vulnerability-management or incident-orchestration systems. Named users, deputies, platform access and evidence retention must work manually at launch.
The reporting duty covers in-scope products made available before 11 December 2027, including products already on the market. An actively exploited vulnerability already known before 11 September 2026 is not retrospectively reportable, but awareness gained after that date triggers the duty even if the vulnerability is older. The trigger therefore depends on when the manufacturer becomes aware of active exploitation, not simply when the underlying flaw was created or disclosed. Attribution posture: This is a regulatory commencement, not an attributed cyber incident, and the cited authorities name no threat actor.
Why this matters now
The immediate change is organisational rather than technical. A vulnerability or product incident that previously stayed inside engineering and incident-response workflows can now start a statutory clock before root cause, affected versions, customer impact or attribution is settled. Security leaders need an evidence threshold for becoming aware, not a process that waits for forensic certainty.
The scope follows access to the EU market rather than corporate headquarters. US and other non-EU manufacturers can therefore face the same reporting decision when their connected hardware or software is distributed in Member States. Product security, legal, privacy, engineering and regional management need one shared map of covered products and responsible entities.
Third-party components create a particularly difficult decision path. ENISA’s FAQ directs manufacturers to Commission guidance concerning exploited vulnerabilities originating in third-party components. Enterprises cannot assume that an upstream maintainer owns the reporting decision; contracts and product inventories must establish how exploitation evidence reaches the manufacturer quickly enough.
The absence of an application programming interface at launch makes operational preparation more important. Organisations expecting automated regulatory orchestration must initially preserve human access, credentials, deputies and submission evidence for the platform interface, including coverage during weekends, leave and simultaneous incidents.
The decision for security leaders
Assign one accountable decision owner across product security, incident response and legal. A committee can advise, but it cannot be allowed to obscure when the organisation became aware or who authorised the early warning.
Adopt a staged evidence standard. The 24-hour submission should record what is known, unknown and being validated; it should not wait for the certainty expected in a final forensic report. Preserve the evidence supporting both submission and non-submission decisions.
Connect the product inventory to legal manufacturer status, EU market availability, component ownership and regional CSIRT routing. A conventional asset inventory is insufficient if it cannot answer which corporate entity carries the reporting obligation for a specific product release and geography. “Who is the product owner?” must have a deterministic answer before an incident begins, including for acquired products and white-labelled offerings with split responsibilities across legal entities, engineering teams or distributors. Document which entity decides awareness, which submits the report and which retains the evidence. If those answers differ by product, market or distribution model, record the exceptions explicitly and review them after organisational or portfolio changes. A reporting process without this product-to-entity map can lose critical hours establishing basic scope while investigators are already managing containment, customer communications and technical uncertainty. That governance gap, rather than an unavailable technical control, is the avoidable failure mode. This mapping should therefore be treated as a maintained control record, not a one-time legal interpretation exercise conducted only when an incident occurs or a regulator asks for evidence. It should identify current deputies, after-hours contacts and the approved source of truth used by legal, security and product engineering during a live reporting decision. “Which version is affected?” and “which company placed it on the market?” are separate questions, and the operating model must answer both without relying on informal knowledge. The map should also show how inherited products, embedded components and services distributed through partners reach the correct manufacturer decision path. “Unknown” is a valid inventory status only when it has an owner, a deadline and an approved interim reporting assumption. Otherwise, uncertainty becomes an unmanaged exception that can silently consume the statutory window. Security leadership should require evidence that the product catalogue, legal-entity register and incident-escalation directory reconcile, with discrepancies tracked through normal risk governance rather than left for an emergency. “We believed another entity was responsible” is not an operating model. It is an unresolved control dependency that must be assigned, tested and documented before exploitation or a severe incident creates the first real clock. The decision is not to produce more documentation; it is to ensure that the facts required to identify the obligated manufacturer are available at incident speed, from an authoritative record, to the people who must act. That capability belongs jointly to product, legal and security leadership and should survive staff turnover, acquisitions, outsourcing and regional restructuring. Evidence of readiness is a sampled demonstration that a responder can take a named product and release, identify the relevant manufacturer and CSIRT route, contact the authorised decision owner and open the reporting workflow without searching across disconnected spreadsheets, contracts and organisational charts. Where distributors, importers or open-source stewards share responsibilities, the map should state the evidence and contractual assumptions behind the allocation rather than presenting a false certainty. The practical objective is decision-grade scope under time pressure: enough verified ownership and market information to support an early warning while the technical investigation continues. This is a control-plane problem for the product portfolio, and it deserves the same lifecycle discipline applied to privileged identities, signing keys and production infrastructure. Changes to product ownership, market availability or legal structure should trigger record updates, while periodic exercises should test whether the organisation can still identify the obligated party and submit through the required platform. Leadership should reject closure based solely on a policy stating that reporting responsibilities exist. Closure requires an authoritative map, named accountable people, tested access and evidence from exercises showing that the decision path works in the time available. “Covered product” must become a queryable operational attribute, not a conclusion reconstructed from legal memoranda after the clock has started. “Responsible manufacturer” must likewise resolve to a current legal entity and authorised reporter. The organisation should know which upstream component notices, researcher reports, customer incidents and threat-intelligence observations can create awareness, and how those signals are routed into the same decision process. This mapping is also necessary to separate CRA reporting from overlapping privacy, NIS2, DORA, contractual and securities obligations without assuming that one submission satisfies another. Each regime may have a different trigger, accountable entity, recipient and evidentiary standard. The product-to-entity record should therefore link, rather than collapse, those obligations. During an incident, legal can then determine which clocks have started from one consistent factual baseline. The operational advantage is substantial: investigators continue containment while a parallel governance track handles notifications from the same verified facts, reducing duplicate interviews, contradictory timelines and delays caused by re-establishing scope for each regime. The leadership decision today is to make that parallel process real, assigned and testable before the first qualifying indication arrives. “We have a regulatory team” is not sufficient if the team cannot identify the relevant product, entity, CSIRT route and technical owner at 02:00. Readiness must extend beyond office hours and named individuals who may be unavailable. Deputies and access continuity are part of the control. The map should also include products nearing end of support, because continued EU availability and awareness of active exploitation may still create decisions even when engineering ownership has weakened. Legacy products are where ambiguous accountability and slow evidence collection become most dangerous. Assigning them explicitly prevents silence from being mistaken for exemption. Product-security leaders should review whether vulnerability disclosure channels, support cases, abuse reports and supplier notifications capture the time of receipt and preserve the original evidence, because that timestamp may become central to demonstrating when awareness began. Finally, align the map with board and executive reporting thresholds so a CRA notification cannot occur without appropriate leadership visibility, while avoiding approval chains that consume the reporting window. Executive awareness and operational speed are compatible when authority is pre-delegated and escalation criteria are explicit. The outcome should be a controlled, evidence-backed route from signal to product scope, legal entity, reportability decision and submission, with no dependency on institutional memory. That route is what security leadership must commission now.
Evidence of closure
- Approved product-to-manufacturer register identifies every EU-market product.
- Named primary and deputy reporters can access the SRP.
- Exercise evidence shows an early warning submitted within 24 hours.
- Supplier contracts contain timed exploitation-notification obligations.
The Security.io assessment
The principal failure mode is not simply missing a deadline. It is spending the deadline debating whether incomplete telemetry constitutes awareness, which entity is the manufacturer and whether a supplier owns the problem. Those ambiguities should be governed as pre-existing control gaps.
Early notification and incident containment can compete for the same specialists. The stronger operating model separates responsibilities while sharing a single factual timeline, allowing responders to contain the issue as legal and product-security owners prepare a qualified report that states uncertainty without overstating impact.
The lack of a launch API creates a foreseeable resilience dependency on human access to the platform. Organisations should treat unavailable credentials, absent deputies or an untested submission interface as reporting-control failures, even if no qualifying incident has yet occurred.
The regulation does not turn every severe vulnerability into a notification. The relevant question is whether active exploitation or a qualifying severe product-security incident is known. A defensible non-reporting decision therefore requires recorded evidence and authority, not silence or an unresolved ticket.
Questions for the morning meeting
- Who has authority to start the CRA reporting clock?
- Which legal entity is the manufacturer for each EU product?
- Can product security submit an early warning without delaying containment?
- Which suppliers must provide evidence inside the 24-hour window?