The EU Cyber Resilience Act (CRA) changes the way manufacturers need to think about product cybersecurity.
Cybersecurity is no longer only something to demonstrate before a product reaches the market. Under the CRA, manufacturers are responsible for handling vulnerabilities throughout the product’s expected support period - including identifying vulnerabilities, addressing them, providing security updates (patches) and keeping relevant cybersecurity information up to date.
That makes one thing increasingly important: continuous monitoring.
A product can pass a security assessment today and still contain a newly disclosed vulnerability tomorrow. A component can receive a critical CVE months after the product was released. A vulnerability that initially appears theoretical can later become actively exploited.
For manufacturers, the challenge is therefore not simply to know whether a product is secure at a given point in time, but to understand how its security posture changes over time.
What does the CRA require?
The CRA applies broadly to hardware and software products with digital elements that are made available on the EU market and have a direct or indirect logical or physical connection to a device or network. This includes both complete products and components placed separately on the market.
The regulation requires manufacturers to address cybersecurity throughout the whole product lifecycle.
Among other requirements, manufacturers must:
· identify and document vulnerabilities and the components contained in their products;
· maintain a software bill of materials (SBOM) covering at least the top-level dependencies;
· address and remediate vulnerabilities without delay, including through security updates;
· carry out effective and regular security testing and reviews;
· provide information about fixed vulnerabilities and appropriate remediation;
· maintain vulnerability handling throughout the defined support period.
There is also a significant new reporting obligation.
Since 11 September 2026, manufacturers must report actively exploited vulnerabilities and severe incidents affecting the security of products with digital elements. The CRA requires an early warning within 24 hours of becoming aware, followed by a main notification within 72 hours.
This creates a very practical question for manufacturers:
How do you know what vulnerabilities affect your products - and how quickly can you determine whether a newly discovered vulnerability is actually relevant to you?
Why continuous monitoring matters
Traditional security testing provides an important point-in-time view.
A penetration test, security assessment or code review can identify weaknesses before or during product release. But the threat landscape does not stop changing when the assessment ends.
New vulnerabilities are disclosed continuously. Attack techniques evolve. Previously unknown vulnerabilities may be discovered in third-party components. Exploitation can also change the significance of an existing vulnerability.
Continuous monitoring complements point-in-time testing by providing an ongoing view of the product's vulnerability exposure.
A practical continuous monitoring capability can connect several pieces of information:
Product → Components → Vulnerabilities → Exploitability → Threat intelligence → Remediation
This can help manufacturers answer questions such as:
· Which vulnerabilities affect components actually used in our product?
· Is the affected component present in the current product version?
· Is the vulnerable code reachable or relevant to the product's functionality?
· Is there evidence of exploitation in the wild?
· Which products, firmware versions or deployed assets are affected?
· Has a patch already been released?
· Has the vulnerability been remediated and verified?
· Do we need to communicate or report the issue?
The value is not simply having more vulnerability data.
The value is being able to connect vulnerability intelligence to the products and components you actually have.
SBOM is the starting point - not the finish line
The CRA explicitly introduces SBOM-related requirements as part of vulnerability handling.
An SBOM provides visibility into the software components that make up a product. But an SBOM alone does not tell a manufacturer whether a newly disclosed vulnerability creates a meaningful security risk or not.
Consider a simple example.
A manufacturer has a device containing 200 software components. A new vulnerability is disclosed in one of them.
An automated vulnerability scanner may immediately identify a version match.
But the manufacturer still needs to understand:
Is that component actually present in the affected product version? Is the vulnerable functionality used? Is the vulnerability exploitable in this specific implementation? Is the product exposed in its deployed environment? Is a fix available?
This is where continuous monitoring becomes more than CVE matching.
Combining SBOM data, vulnerability intelligence and product-specific analysis can help reduce the distance between “a vulnerability exists somewhere in our software stack” and “this vulnerability requires action on this product.”
Which products are affected?
The CRA has a broad scope.
It covers many everyday connected products, software products and embedded devices, as long as they meet the definition of a product with digital elements and are made available on the EU market. Examples include IoT products, smart-home devices, software applications, connected hardware and components.
The regulation also identifies important and critical product categories that face additional conformity assessment requirements.
Important products include categories such as:
· identity and privileged access management systems;
· browsers;
· password managers;
· anti-malware software;
· VPN products;
· network management systems;
· SIEM systems;
· operating systems;
· network interfaces;
· routers, internet modems and switches;
· security-related microprocessors;
· hypervisors and container runtimes;
· firewalls and intrusion detection/prevention systems;
· tamper-resistant microprocessors and microcontrollers.
Critical products include, among others:
· hardware devices with security boxes;
· smart-meter gateways and certain advanced security devices;
· smartcards and similar devices, including secure elements.
The CRA therefore reaches far beyond traditional consumer software.
Which industries should pay attention?
Because the CRA is product-focused rather than limited to a particular industry, its impact can extend across a wide range of manufacturers.
Automotive
Connected vehicles contain large numbers of software components, ECUs, connectivity modules and backend interfaces.
For automotive manufacturers and suppliers, continuous vulnerability monitoring can complement existing security engineering and testing processes by tracking vulnerabilities in the components that ultimately become part of vehicle products and supporting infrastructure.
The CRA also needs to be considered alongside sector-specific legislation. Notably, the CRA excludes products covered by certain other EU legislation, including Regulation (EU) 2019/2144, so the precise regulatory position of a particular automotive product needs to be assessed rather than assumed.
Industrial and OT
Industrial devices increasingly combine embedded software, networking and remote connectivity.
For manufacturers of industrial equipment and connected control products, vulnerability monitoring can provide visibility into vulnerabilities affecting firmware, operating systems, libraries and other third-party components throughout the product support period.
Energy and utilities
Connected energy products - including smart-metering infrastructure and certain security-related devices - are directly relevant to the CRA's critical product categories.
Here, understanding whether a newly disclosed vulnerability affects deployed products can be particularly important because products may remain in operation for many years.
Fintech and payment technology
Payment terminals, embedded payment devices, authentication hardware and other connected products can contain complex combinations of firmware, operating systems, third-party libraries and security components.
Continuous monitoring can help manufacturers maintain visibility of vulnerabilities across these components rather than relying exclusively on periodic security assessments.
Consumer electronics and IoT
Smart appliances, connected devices, wearables and other consumer products can remain deployed for years after their initial release.
For manufacturers, the security responsibility therefore continues after the product launch - making ongoing vulnerability intelligence and an effective remediation process important parts of the product lifecycle.
Continuous monitoring does not replace security testing
Continuous monitoring should not be viewed as a replacement for penetration testing, product security assessments or secure development practices.
Each provides a different type of visibility.
|
Capability |
What it helps answer |
|
Security assessment / |
Can this product be attacked through its exposed functionality? |
|
SBOM |
What software components are included? |
|
Vulnerability monitoring |
Which known vulnerabilities could affect those components? |
|
Threat intelligence |
Which vulnerabilities are being exploited or actively targeted? |
|
Continuous monitoring |
How does the product's vulnerability exposure change over time? |
|
Patch validation |
Has the vulnerability actually been addressed? |
For manufacturers, the strongest approach is therefore not testing versus monitoring, but a combination of these capabilities.
From vulnerability discovery to actionable intelligence
The practical challenge of CRA compliance is not collecting the largest possible number of vulnerabilities.
It is knowing which vulnerabilities matter, to which products, and what needs to happen next.
A continuous monitoring process can provide a feedback loop:
Monitor → Identify → Analyse → Prioritise → Remediate → Validate → Monitor again
This is particularly relevant for products with long lifecycles and complex software supply chains, where the security posture can change many times after the initial conformity assessment.
The CRA effectively makes product security a lifecycle responsibility.
Continuous monitoring provides the operational mechanism to support that responsibility.
The shift from point-in-time security to lifecycle security
The CRA does not make a single security assessment irrelevant. Instead, it places that assessment within a much larger lifecycle.
A product may be secure when it is released.
The question is whether the manufacturer can continue to understand and manage its security exposure months or years later.
That requires visibility into components, vulnerabilities, exploitation, remediation and changes to the product over time.
Continuous vulnerability monitoring and threat intelligence can help turn this from a reactive process into an ongoing product security capability - supporting manufacturers not only in meeting CRA requirements, but in understanding what is happening to their products after they leave the development environment.
The CRA's main obligations will be fully in effect from 11 December 2027, while the vulnerability and incident reporting requirements have already started applying from 11 September 2026.
For manufacturers, the time to build the processes and visibility needed for continuous vulnerability handling is therefore not after the next vulnerability is discovered. It is before it happens.
