Product security continues to stand as a forefront of risk for manufacturers and developers worldwide. Consumers are consistently seeking new ways to protect themselves, their environments and their own systems. While some of this responsibility may fall on user’s, many look to the product engineers behind their solutions as a first line of defense. Secure by design, secure configurations by default and vulnerability management all serve to help improve the underlying security of digital products.
TL;DR – The European Union Cyber Resilience Act’s vulnerability and incident reporting obligations went live September 11, 2026 and manufacturers that haven’t completed a product-level risk assessment are at risk of non-compliance.
Many of these security expectations all fall well within the expectations of the European Union (EU) Cyber Resilience Act (CRA), the EU’s latest effort at helping secure products with digital elements. And while this regulation is enforced in the EU, any organization with a product that has digital elements that are sold in the EU are under obligation to follow the framework. The concept of products with digital elements may seem new, but the applied concept is designed to encompass most hardware and software solutions. These include “software or hardware product and its remote data processing solutions, including software or hardware components being placed on the market separately”
While full compliance is not required until December 11, 2027, an earlier milestone arrived September 11, 2026. The CRA’s incident and vulnerability reporting obligations is now in effect and stands as the first fully required component of the CRA.
Before the reporting clock starts ticking, it’s worth noting what the CRA expects manufacturers to have already completed a product-level cybersecurity risk assessment (Article 13(2)). This is the foundational step that determines how manufacturers identify, classify and respond to the incidents and exploits that trigger reporting.
A product risk assessment establishes:
Without this foundation, manufacturers are left classifying their incidents as “severe” and “active” without a defined baseline.
This milestone set a stringent reporting timeline designed to help ensure consumers are both aware of and protected from, active attacks against a product with digital elements. Whenever an active exploit or severe incident, is uncovered, manufacturers will have a set amount of time to report this information to the CRA Single Reporting Platform (SRP).
Before we discuss the timeline however, it’s important to determine what an active exploit or a severe incident is.
Per the SRP an “active exploit” is described as a vulnerability with “reliable evidence that a malicious actor has exploited it in a system without permission of the system owner.” Notably, the created definition states “without permission of the system owner.” This stands as an important clarification. The CRA is not intended to disincentive security researchers or manufactures from engaging in good faith research and vulnerability hunting. “Active exploits” are those that are being used to target a system in a malicious manner and generally won’t include responsible disclosure (unless there is evidence to suggest the vulnerability is being actively exploited).
“Severe Incidents” are those which “have a severe impact on the security of the product with digital elements.” In this case, “severe” include any incidents which “negatively affects the ability of a product with digital elements to protect the availability, authenticity, integrity or confidentiality of sensitive or important data or functions” or those incidents which “lead to the introduction or execution of malicious code in a product with digital elements or in the network and information systems of a user of the product with digital elements.”
The CRA’s definition of severity directly relates to a product risk assessment’s loss scenarios. If the risk assessment has already scored scenarios against these four dimensions, you have a pre-built severity classification engine. When an incident occurs, you’re not debating whether it’s “severe” as the risk assessment has answered that question.
If either of the two described events occur, reporting timelines include the following.
|
Milestone
|
Active Exploit Timeline
|
Severe Incident
|
|---|---|---|
|
Early Warning |
24 hours |
24 hours |
|
Vulnerability/Incident Notification |
72 hours |
72 hours |
|
Final Report |
14 days |
|
Based on the milestone, the CRA requires various information, but with each passing milestone, additional information is expected. The goal of these reporting timelines is to ensure that users, organizations and manufacturers are all able to respond in a timely and effective, manner to threats with the goal of reducing their overall risk and exposure. Things such as the affected product and scope of a vulnerability capture some of the early information expected. Details surrounding vulnerability descriptions and the nature of the active exploit or incident are generally expected within 72 hours. And a full description of the exploit/incident and remediation efforts taken is expected by the final report.
While the “What” is clear, some organizations may find that the “How” is less obvious. In concept the idea of reporting vulnerabilities is simple, but this all stems on being able to identify active exploits or incidents. The ability to respond to this in a timely manner requires a careful combination of asset, document, vulnerability and incident response management.
Reporting on an “active exploit” implies the ability to respond rapidly to new and emerging threats within a product or suite of products. The CRA requires organizations to maintain an SBOM for their products. While this documentation isn’t technically required by the CRA until December 2027, it can serve as the basis for proper vulnerability management and identification.
An SBOM scored against your product risk assessment is a prioritized action list. When a new CVE drops, the risk assessment context tells you whether that component’s exploitation represents a critical reporting trigger or a low-severity issue that doesn’t meet the “active exploit” threshold.
While the “What” is clear, some organizations may find that the “How” is less obvious. In concept the idea of reporting vulnerabilities is simple, but this all stems on being able to identify active exploits or incidents. The ability to respond to this in a timely manner requires a careful combination of asset, document, vulnerability and incident response management.
An accurate view of a product’s components is a great step towards identifying components which may be exploited. However, for timely and effective response, tailored and focused threat and vulnerability feeds are imperative to understanding active exploits and risks around potential incidents.
A product risk assessment identifies which threat actors are likely to target your product class, which attack vectors are most probable given your architecture and which exploitation scenarios would trigger reporting obligations.
An SBOM scored against your product risk assessment is a prioritized action list. When a new CVE drops, the risk assessment context tells you whether that component’s exploitation represents a critical reporting trigger or a low-severity issue that doesn’t meet the “active exploit” threshold.
While the “What” is clear, some organizations may find that the “How” is less obvious. In concept the idea of reporting vulnerabilities is simple, but this all stems on being able to identify active exploits or incidents. The ability to respond to this in a timely manner requires a careful combination of asset, document, vulnerability and incident response management.
An incident can only be reported if it is properly identified and recognized early. Continuous monitoring, effective detection and rapid response are all key to properly understanding and reporting a severe incident.
A product risk assessment identifies which threat actors are likely to target your product class, which attack vectors are most probable given your architecture and which exploitation scenarios would trigger reporting obligations.
An SBOM scored against your product risk assessment is a prioritized action list. When a new CVE drops, the risk assessment context tells you whether that component’s exploitation represents a critical reporting trigger or a low-severity issue that doesn’t meet the “active exploit” threshold.
While the “What” is clear, some organizations may find that the “How” is less obvious. In concept the idea of reporting vulnerabilities is simple, but this all stems on being able to identify active exploits or incidents. The ability to respond to this in a timely manner requires a careful combination of asset, document, vulnerability and incident response management.
If not already in place, manufacturers may need to create, maintain and implement new vulnerability reporting and incident response procedures. Timelines associated with the CRA reporting obligations are strict. Failure to comply can lead to significant financial penalties.
While the CRA’s initial milestone may be fast approaching, much of what is covered by the CRA falls well within security best practice. Things such as secure by design, effective vulnerability management and threat modeling fall well within the realm of security that GuidePoint and its partners have championed. While the CRA is new, the problems it seeks to solve are not.
Ready to assess your products against compliance requirements? Connect with our team to schedule an assessment and identify potential gaps and next steps.
Want to learn more about the EU Cyber Resilience Act (CRA)? Explore our datasheet for key requirements, considerations and guidance.
Will Klotz is a Senior Security Consultant with over a decade of experience building and leading cybersecurity and risk management programs across a range of industries, including banking, fintech, federal, insurance, healthcare and software. Since entering the security field in 2010, Will has developed and implemented enterprise-wide frameworks for information security, third-party risk, policy exception handling and AI risk governance.