The Deadline That Arrived Before the CRA
The subject of this series is the Cyber Resilience Act’s first live compliance duty: how manufacturers must respond when a product with digital elements contains an actively exploited vulnerability or is involved in a severe security incident. This opening focuses on the unusual timing of that duty and on the chain it creates between a product, its manufacturer, users, national cybersecurity teams, the European Union Agency for Cybersecurity (ENISA), and market-surveillance authorities. By the end, the key judgment should be clear: the immediate question is not whether an organization has read the whole CRA, but whether it can recognize a qualifying event and move reliable information through the right route before the broader regime applies.
A date that changes behavior
The Cyber Resilience Act is easy to misread if its dates are treated as one starting line. Regulation (EU) 2024/2847 generally applies from 11 December 2027. That is the date associated with full application of the rulebook. But Article 14, which contains the mandatory reporting obligations for manufacturers, applies from 11 September 2026. The European Commission’s implementation timeline presents those as separate milestones, and its reporting page states that the Single Reporting Platform is operational from the earlier date.
That distinction has practical force. A company does not receive a general two-year pause on reporting simply because other parts of the CRA have not yet reached full application. From the earlier date, a manufacturer that becomes aware of a qualifying product-security event must be able to act under Article 14’s reporting model. The immediate obligation concerns two kinds of event: an actively exploited vulnerability in a product with digital elements, and a severe incident having an impact on the security of such a product. The details of those thresholds and the deadlines they create come later. The important orientation here is that the reporting clock starts before the rest of the CRA’s obligations arrive as one package.
The transition rule is broader than a rule for products launched during this interim period. Article 69(3) says that the Article 14 obligations apply to all products with digital elements within the Regulation’s scope that were placed on the market before 11 December 2027. A manufacturer cannot therefore limit its preparation to a new-product pipeline. A weakness discovered in an older connected product may still lead to a current reporting duty if the product is in scope and the statutory event threshold is met.
This is why the first deadline is an operating deadline rather than a date to circle on a compliance calendar. An organization needs to know which products it has put on the Union market, where those products have been made available, who owns product-security decisions, how an event becomes known internally, and who can submit on its behalf. It also needs a way to continue the process after the first notice. The first date is early, but the duty is not shallow.
The product is the unit, but reporting is a chain
The CRA starts from a broad product concept. A product with digital elements can be software, hardware, a remote data-processing solution, or a software or hardware component placed on the market separately. The Regulation covers products whose intended purpose or reasonably foreseeable use includes a direct or indirect logical or physical connection to a device or network. That language reaches beyond a standalone laptop or phone. It can include a connected component whose role becomes significant only when integrated into a larger product or service.
The legal role of the manufacturer is equally important. The manufacturer is the person that develops or makes the product, or has it designed or made, and markets it under their name or trademark. That role carries the central responsibility for vulnerability handling, reporting, user communication, and corrective action. The supply chain can change the answer: an importer or distributor is treated as a manufacturer when they market a product under their own name or trademark or substantially modify a product already placed on the market. But the rule does not mean that every organization that sells or distributes a digital product automatically becomes the reporting manufacturer.
Other actors complete the chain. The manufacturer sends a mandatory notification through the CRA Single Reporting Platform. A designated coordinator CSIRT—the national computer security incident response team responsible for coordinating such reports—receives it through the relevant national endpoint. ENISA has simultaneous access and manages the platform’s day-to-day operation. The initial CSIRT shares the notification with coordinator CSIRTs in other Member States where the manufacturer has indicated that the product was made available. Those national teams can provide the necessary information to their market-surveillance authorities.
Users are not an afterthought in this structure. The manufacturer must inform impacted users, and where appropriate all users, about an actively exploited vulnerability or severe incident and about measures they can take to reduce the impact. A report that reaches an authority but leaves exposed users without usable advice has not completed the risk-reduction chain. Later chapters will examine the content and timing of those communications. For now, the relationship matters: the CRA connects regulatory notification to the people and systems that must act on the information.
A simple example shows why the chain matters. Imagine a company that sells a network-connected building controller under its own name. The controller includes a third-party software component. A researcher’s report first arrives at the component maintainer, and the company then obtains reliable evidence that an attacker has used the weakness against deployed controllers. The company must not treat the issue as only a supplier conversation. It must determine whether the product is within the CRA’s scope, identify when the manufacturer became aware, establish where the controller was made available, notify through the required route, and tell affected users what they can do. The scenario is illustrative, but each relationship follows the Regulation’s structure.
From a filing date to a response system
The most misleading mental model is to picture Article 14 as a single form submitted at the end of an investigation. The Regulation instead assumes that information changes over time. A manufacturer may know enough to issue an early warning before it knows the full root cause, the complete impact, or the final corrective measure. The reporting system gives that changing knowledge several formal points at which it can be shared. It also links the report to dissemination, user protection, remediation, and later supervisory learning.
That design creates a productive tension. Speed matters because active exploitation can continue while an organization is still assembling facts. Accuracy matters because a notification can affect multiple Member States, users, national authorities, and the handling of sensitive vulnerability information. The answer is not to choose speed over accuracy or accuracy over speed. It is to separate what must be known immediately from what can be supplied as the investigation and correction mature, while recording the awareness point and the decisions that follow it.
The distinction between the two dates reinforces the same idea. Before 11 September 2026, an organization could treat CRA reporting as preparation for a future regime. From that date, the relevant capability is present-tense: detect, classify, timestamp, notify, route, communicate, and remediate. By 11 December 2027, that capability sits within the full CRA framework, including the wider product, process, conformity, and market-surveillance obligations. The first date is therefore a leading indicator of whether the organization’s product-security lifecycle is real enough to support the second.
The diagram is deliberately simple. It does not claim that every report follows one identical technical investigation or that ENISA replaces national responsibility. It shows the basic relationship the dates can obscure: the earlier legal trigger activates a route through which product knowledge is shared, while user action and authority coordination remain part of the same response.
The question behind the deadline
A dated duty is useful only when the organization can recognize the event that activates it. A vulnerability is not automatically an actively exploited vulnerability. An incident is not automatically severe merely because it is embarrassing, expensive, or technically interesting. The CRA uses defined evidence and impact conditions, and those conditions determine which clock begins. That is the first judgment a manufacturer must make, before it can decide what to put in a notification.
The route also depends on facts that are easy to lose during an investigation: the product’s legal identity, the manufacturer’s role, the Union location where product-security decisions are predominantly taken, and the Member States in which the product has been made available. A technically correct description sent to the wrong endpoint or without a credible market-availability picture cannot produce the coordinated response the system is designed to provide.
This series will therefore follow the CRA from threshold to consequence. It will first establish what counts as a reportable event and whose awareness matters. It will then trace the actively exploited vulnerability through its staged deadlines, compare that path with severe-incident reporting, and examine how one submission moves through the Single Reporting Platform. Finally, it will connect notification to users, updates, component handling, open-source stewardship, supervision, and the readiness judgment that sits between the live 2026 duty and full application in 2027.
The central conclusion of this opening is modest but consequential: 11 September 2026 is the CRA’s first real compliance deadline because it turns product-security knowledge into an immediate legal and operational chain, even while the wider Regulation is still being implemented. The next question is the one that gives that date meaning: what, precisely, counts as an actively exploited vulnerability or a severe incident affecting a product with digital elements, and whose awareness starts the clock?