What Counts as a Reportable CRA Event?
The central problem in CRA reporting is classification, not paperwork. This chapter defines the product boundary, identifies which actor carries the manufacturer role, and separates the legal meanings of a vulnerability, an actively exploited vulnerability, and a severe incident. That distinction gives the reader a practical judgment: when a security observation becomes an Article 14 event, and when the manufacturer’s awareness starts a duty that cannot be postponed until every technical detail is known.
The product boundary follows connection and responsibility
The Cyber Resilience Act applies to “products with digital elements.” That phrase covers software and hardware, remote data-processing solutions, and software or hardware components placed on the market separately. The connection can be direct or indirect, logical or physical. A product does not have to look like a traditional computer to matter. A network-connected controller, a software package embedded in another device, or a component that provides a necessary remote function may all sit inside the CRA’s product boundary when their intended purpose or reasonably foreseeable use includes a connection to a device or network.
The two kinds of connection are worth keeping separate. A physical connection may use an electrical, optical, mechanical, wired, or radio interface. A logical connection is a virtual data connection implemented through software. An indirect connection exists when the product does not connect straight to the device or network but becomes part of a larger system that does. These definitions prevent a manufacturer from treating the boundaries of a larger system as a reason to ignore a component’s security role.
The scope is broad, but it is not limitless. The Regulation excludes some products covered by other Union laws, including certain medical and in-vitro diagnostic devices and motor-vehicle equipment, and it excludes products developed or modified exclusively for national-security or defence purposes and products specifically designed to process classified information. Where another Union framework addresses the same cybersecurity risks at the same or a higher level, the CRA’s application may be limited or excluded. A product-specific scope decision therefore depends on its function, use, connection, and applicable sectoral law. The existence of software alone does not answer the question.
The manufacturer role supplies the next boundary. Under the CRA, a manufacturer is the person that develops or makes a product, has it designed or made, and markets it under their name or trademark. The rule focuses on responsibility for the product presented to the market, not only on which team wrote the code. That is why a company that contracts out development can still carry the manufacturer role if it markets the result under its own name.
Importers and distributors normally have different duties. They must exercise care before placing or making a product available and must escalate significant cybersecurity risks they identify. But an importer or distributor is considered a manufacturer for CRA purposes if they place the product on the market under their own name or trademark or substantially modify a product already placed on the market. A substantial modification is a post-market change that affects compliance with the essential cybersecurity requirements or changes the intended purpose for which the product was assessed.
That distinction matters at the moment of reporting. A reseller that merely makes another company’s unchanged product available is not automatically the Article 14 manufacturer. A distributor that rebrands it, or an importer that changes it in a way that affects its compliance, can inherit the manufacturer’s obligations. Organizations need a role map that follows branding, design responsibility, modification, and market placement rather than assuming that the legal answer is always “the original developer.”
Consider a connected access-control device assembled from a controller, firmware, and a separately sourced authentication component. The device maker may be the manufacturer even if another organization maintains the authentication component. If the device maker learns that an attacker has used a weakness in that component against the marketed device, the supplier relationship is relevant but not decisive. The product maker must still analyze the event under the CRA. The component maintainer may need to receive vulnerability information as part of the manufacturer’s component-handling duties, but that does not erase the product maker’s responsibility for the product under its name.
From a weakness to a statutory trigger
The CRA uses a ladder of terms because not every security concern has the same evidentiary status. A vulnerability is a weakness, susceptibility, or flaw in a product with digital elements that can be exploited by a cyber threat. This is a broad starting point. It includes a condition that deserves analysis and remediation, but the definition alone does not say that an attacker has used it.
An exploitable vulnerability is narrower. It has the potential to be effectively used by an adversary under practical operational conditions. The question has moved from “is there a weakness?” to “could an adversary realistically use it?” A laboratory proof of a defect may be important, but it does not automatically establish that the weakness is exploitable in the conditions in which the product operates.
An actively exploited vulnerability is narrower still. The CRA requires reliable evidence that a malicious actor has exploited the vulnerability in a system without the system owner’s permission. This is the definition that activates the mandatory vulnerability-reporting track. It is not enough that a scanner found a flaw, that a researcher demonstrated a theoretical attack, or that a weakness has a high internal severity score. Those facts may demand urgent action, but they are not by themselves the statutory fact of active exploitation.
The distinction cuts in both directions. A manufacturer should not report every theoretical weakness as though the 24-hour active-exploitation clock had begun. But the manufacturer should also not demand proof of widespread damage before escalating reliable evidence that an unauthorized actor has already used the weakness. The legal threshold concerns evidence of exploitation, not a completed disaster.
The second mandatory category is a severe incident having an impact on the security of the product with digital elements. An incident has an impact when it negatively affects, or is capable of negatively affecting, the product’s ability to protect the availability, authenticity, integrity, or confidentiality of data or functions. The wording covers both actual negative effect and credible capability to cause it. Product security is not limited to secrecy: a loss of availability, an unauthorized change to commands or configuration, or a failure to establish that data and functions are genuine can be part of the analysis.
The incident becomes severe under either of two conditions. First, it negatively affects or is capable of negatively affecting the product’s ability to protect sensitive or important data or functions. Second, it has led or is capable of leading to the introduction or execution of malicious code in the product or in the user’s network and information systems. The test is therefore tied to the importance of what the product protects and to the potential path from the incident to malicious code.
This potential-impact language is deliberate. If a product has been compromised in a way that could execute malicious code in a user’s network, waiting until every affected system is identified would make the preventive purpose of the rule harder to achieve. At the same time, “capable of” does not mean “anything imaginable.” The manufacturer still needs facts connecting the incident to protected data, functions, code execution, or another security impact. Internal labels such as “critical” or “high” can support triage, but they do not replace the statutory predicates.
Why the two tracks can overlap
The two categories describe different aspects of an event. The actively exploited vulnerability track focuses on reliable evidence that an unauthorized actor has used a weakness in the product. The severe-incident track focuses on the resulting or potential impact on the product’s protection of important data or functions, including malicious-code introduction or execution. One event can contain both facts.
Suppose the access-control device in the earlier example has a remotely reachable authentication flaw. The company finds reliable evidence that an attacker used the flaw. That supports the active-exploitation analysis. If the attacker also executed malicious code on the device or reached a user’s network, the same event may satisfy the severe-incident conditions. The company should preserve the vulnerability facts—what the flaw is, how it was exploited, and what fix addresses it—and the incident facts—what happened, how serious the impact is, what threat or root cause is suspected, and what mitigation continues.
This does not mean filing two disconnected stories with no coordination. It means not forcing distinct legal questions into one severity label. A vulnerability notification can be technically accurate while saying little about operational impact; an incident notification can describe impact while leaving the underlying flaw uncertain. The later reporting rules give those tracks different minimum content and different final-report anchors. Classification should preserve that distinction from the first internal record.
The word “awareness” is also important. Article 14 refers to the manufacturer becoming aware of the actively exploited vulnerability or severe incident. The duty is not framed as beginning when a national authority confirms the event, when a patch is finished, or when a public announcement is made. A manufacturer therefore needs an internal account of how reliable information reached the organization and when the responsible organization had enough knowledge to treat it as awareness. The legal text does not provide a universal technical formula for every awareness scenario; that is a fact-specific judgment that should be documented rather than hidden behind a generic incident ticket.
A useful triage sequence follows the legal logic without replacing it:
- Identify the product and confirm that its intended purpose or reasonably foreseeable use places it within the CRA’s connection-based scope, subject to exclusions or sectoral rules.
- Identify the responsible role, including whether the organization markets the product under its own name or has substantially modified it.
- Describe the security fact without jumping straight to a label: weakness, practical exploitability, evidence of unauthorized use, or incident impact.
- Test the statutory branches separately: reliable evidence of active exploitation, and impact or potential impact on important data/functions or malicious-code execution.
- Record what is known, when the manufacturer became aware, and which facts remain uncertain before the timed notification process is developed.
This is not a substitute for legal advice or a universal severity matrix. It is a way to stop three common errors: treating every vulnerability as active exploitation, treating every incident as severe without identifying the protected function or potential code execution, and assigning responsibility to the wrong actor because the supply chain is complicated.
The diagram’s branches can coexist. A practical exploitability finding is not the same as evidence of active use, and an incident affecting product security is not severe unless the additional impact conditions are met. When both terminal branches apply, the manufacturer has one connected event with two reporting dimensions, not one label that makes the second dimension disappear.
The judgment that starts the clock
The CRA’s first reporting judgment is consequently a chain of facts: what the product is, who carries the manufacturer role, what the organization knows, and what the event does or could do. The product boundary prevents a company from isolating a connected component from the system in which it performs its security function. The role rules prevent a company from assuming that outsourcing development or reselling a product always removes responsibility. The threshold rules prevent both indiscriminate escalation and dangerous delay.
Once reliable evidence of active exploitation exists, the next problem is not to wait for a perfect investigation. It is to send the right information in stages. The vulnerability track begins with an early warning within 24 hours of the manufacturer becoming aware, followed by a fuller notification within 72 hours and a final report after a corrective or mitigating measure becomes available. Those deadlines make the classification work in this chapter consequential: the label determines which clock the manufacturer must be ready to run.