The Cyber Resilience Act and Vulnerability Management: What Digital Product Manufacturers Need to Change
On 27 July 2026, the European Commission published new practical guidance on the application of the Cyber Resilience Act (CRA) – Regulation (EU) 2024/2847.
The guidance addresses several areas that directly affect manufacturers of software, hardware and other products with digital elements, including the scope of the CRA, support periods, cybersecurity risk assessments, substantial modifications, reporting obligations and, importantly, vulnerability handling.
For companies developing digital products for the EU market, the direction is clear: vulnerability management is moving beyond being merely a security best practice or an optional element of the secure development lifecycle. Under the CRA, it becomes part of product compliance and must be maintained throughout the relevant lifecycle of the product.
It is important, however, to be legally precise. The CRA does not establish a separate formal obligation called a “vulnerability management programme.” Instead, it introduces vulnerability handling requirements under Part II of Annex I, together with cybersecurity risk assessment obligations, Article 13 requirements, Article 14 reporting obligations and responsibilities concerning third-party components.
Taken together, these requirements effectively create an ongoing vulnerability management process.
The European Commission describes Part II of Annex I as requiring manufacturers to ensure that vulnerabilities affecting their products and components are effectively handled throughout the applicable support period.
CRA Changes the Product Security Responsibility Model
Before the CRA, product cybersecurity was often organised around individual checkpoints:
- a penetration test before release;
- a security audit requested by a major customer;
- code review before certification;
- an external security assessment once a year.
The CRA follows a different model.
Manufacturers are expected to assess cybersecurity risks during product planning, design and development, take them into account during production, delivery and maintenance, and continue addressing vulnerabilities after the product has entered the market.
In other words, cybersecurity becomes a continuous product responsibility, rather than a periodic IT security activity.
The Commission also clarifies that manufacturers are expected to identify relevant cybersecurity risks, assess their potential impact and implement appropriate measures. A company's willingness to accept a risk, its commercial priorities or the cost of remediation are not, by themselves, sufficient reasons to leave a cybersecurity risk unresolved.
Similarly, manufacturers cannot simply transfer responsibility for weaknesses in product design to customers or third parties.
When Do the Requirements Start Applying?
The CRA entered into force on 10 December 2024.
Most of its provisions will apply from 11 December 2027.
However, the reporting obligations under Article 14 start earlier – on 11 September 2026.
This distinction matters.
The main vulnerability-handling requirements apply to products falling fully within the CRA and continue throughout their support period. Article 14 reporting requirements, however, will also apply from September 2026 to certain products with digital elements that were already placed on the EU market before the CRA becomes fully applicable in December 2027.
Companies should therefore not treat 2027 as the only relevant deadline.
Processes capable of identifying active exploitation, performing an initial technical assessment and preparing regulatory notifications need to be operational significantly earlier.
Who Is Actually Required to Manage Vulnerabilities?
The CRA does not impose identical obligations on every organisation that simply uses software.
The primary responsible party is the manufacturer.
Under the CRA, this includes a natural or legal person that develops or manufactures a product with digital elements – or has such a product designed or manufactured – and markets it under its own name or trademark.
The CRA is concerned with whether the product is made available on the EU market, rather than where the manufacturer is incorporated.
This means the requirements are also relevant to Ukrainian, US and other non-EU companies whose products are offered in the European Union.
The definition of a product with digital elements is broad. It covers hardware and software, including certain software and hardware components as well as some remote data processing solutions.
Examples may include:
- mobile and desktop applications;
- IoT devices;
- networking equipment;
- connected products;
- operating systems;
- developer tools;
- cybersecurity software;
- and many other types of digital products.
An Integrator Can Also Become a Manufacturer
CRA responsibility is not necessarily limited to the original developer of an individual component.
If a company takes existing components, adds its own software or firmware, integrates them into a new solution and places that solution on the market under its own name, the company may become the manufacturer of the resulting product with digital elements and become responsible for the product as a whole.
The same issue can arise when another party makes a substantial modification to an existing product and that modification changes its cybersecurity risk profile. The modified product may effectively be treated as a new product, and the organisation making the modification may assume manufacturer obligations under the CRA.
This is particularly relevant to:
- system integrators;
- OEM models;
- white-label software;
- complex products assembled from multiple third-party components.
What About Importers and Distributors?
Importers and distributors do not automatically replace manufacturers as the primary operators of vulnerability management processes.
However, they have their own obligations.
An importer must, among other things, verify that the manufacturer has complied with relevant cybersecurity requirements and has appropriate processes in place to meet its vulnerability-handling obligations.
If an importer becomes aware of a vulnerability or has reason to believe that a product does not comply with the CRA, additional responsibilities may arise, including responding to the issue, communicating with the manufacturer and cooperating with market surveillance authorities.
A similar approach applies to distributors.
The practical result is that vulnerability information may need to move not only through a manufacturer's internal security organisation, but also across the supply chain.
Vulnerability Management Under the CRA Is Much More Than Running a Scanner
One of the biggest mistakes companies could make is to reduce CRA compliance to periodic vulnerability scanning.
The CRA effectively requires a broader lifecycle:
understand the product and its components → discover vulnerabilities → validate them → assess applicability and risk → remediate → retest → provide security updates → disclose where appropriate → report to regulators when required.
In practical terms, a vulnerability management operating model should include at least the following elements.
- Product and Component Visibility. Companies need to understand which products, versions and third-party components they support. Part II of Annex I also addresses documentation of vulnerabilities and components, including the use of a Software Bill of Materials (SBOM) in a machine-readable format, at least covering top-level dependencies.
- Continuous Vulnerability Discovery. Vulnerabilities may be identified through multiple sources, including independent bug hunters, automated security tools, security researchers, vulnerability databases, security advisories, customer reports and internal security testing and analysis. The Commission's guidance specifically recognises that a vulnerability can become “known” not only through publication in a public database, but also through coordinated disclosure by a security researcher or as a result of the manufacturer's own testing.
- Validation and Triage. Finding a CVE is not enough. A manufacturer needs to establish whether the vulnerability actually affects the specific product, whether the relevant code is reachable, whether exploitation is realistic under actual operational conditions and what impact exploitation could have.
- Remediation and Security Updates. Identified vulnerabilities cannot simply remain in a vulnerability register. They need to be addressed according to risk, and companies need mechanisms for delivering security fixes to users and tracking the remediation lifecycle.
- Effective and Regular Security Testing. Security testing does not end when a product is released. Manufacturers should reassess their testing approach as new vulnerabilities and threats emerge, the product changes and the threat landscape evolves. Where necessary, new or modified tests should be performed.
- Coordinated Vulnerability Disclosure. Companies need a clear mechanism through which independent security researchers and other external parties can securely report vulnerabilities. The organisation must then be able to receive, validate, manage and communicate around those reports.
- Third-Party Component Management. Manufacturers need to exercise appropriate due diligence concerning components incorporated into their products and assess whether those components could undermine the cybersecurity of the product as a whole. Where appropriate, this may include independent security testing of those components.
- Regulatory Reporting Readiness. Organisations need to distinguish quickly between an ordinary vulnerability and an actively exploited vulnerability or a severe incident, and be able to initiate the Article 14 reporting workflow.
- Evidence and Traceability. Risk assessments, testing results, remediation decisions, affected versions, fixes and disclosure actions should be connected to technical documentation and create a reproducible evidence trail. CRA cybersecurity risk assessments and relevant technical documentation also need to remain up to date.
These capabilities – not the ownership of a particular vulnerability scanner – form the real operating model for vulnerability management under the CRA.
The CRA Explicitly Requires Effective and Regular Testing
One particularly important clarification in the Commission's new guidance concerns “effective and regular tests and reviews.”
Part II of Annex I requires manufacturers to perform effective and regular testing and reviews during the support period.
Importantly, “regular” does not necessarily mean repeating exactly the same penetration test every six or twelve months.
Companies should regularly evaluate whether:
- the threat landscape has changed;
- the product has changed;
- new vulnerabilities have emerged;
- other security-relevant inputs have changed.
If they have, the testing strategy should also change and appropriate new testing should be performed.
The depth and frequency of this review should be proportionate to the cybersecurity risk profile of the product.
Why One Penetration Test Is No Longer Enough
Penetration testing remains an important security tool.
But a pentest provides a snapshot of the product at a specific point in time.
The day after the assessment, a critical vulnerability may be disclosed in one of the product's dependencies.
A month later, the development team may change the authentication flow.
Three months later, the product may introduce a new API, cloud integration or AI component.
Six months later, attackers may develop a new exploitation technique that did not exist when the original testing was performed.
This is why the Commission's guidance links testing to newly discovered vulnerabilities, emerging threats, product evolution and changes in the threat landscape – rather than simply to a calendar date.
The traditional model: develop → pentest → release → forget – is increasingly inconsistent with the lifecycle approach of the CRA.
The emerging model is: identify risks → test → release → monitor → receive vulnerability reports → validate → remediate → retest → update → monitor again.
Not Every Vulnerability Must Be Reported to the Regulator
This distinction is critical.
The CRA separates vulnerability handling from mandatory regulatory reporting.
Manufacturers should have processes for receiving and handling potential vulnerabilities from both internal and external sources.
However, Article 14 reporting applies, among other things, to actively exploited vulnerabilities of which the manufacturer becomes aware.
The existence of a CVE in a third-party library does not automatically mean that a notification must be submitted to ENISA.
The Commission's guidance gives the example of a vulnerability in a third-party component where the vulnerable code is not reachable in the specific implementation.
Such a situation may not amount to an actively exploited vulnerability requiring Article 14 reporting.
That does not eliminate the manufacturer's broader vulnerability-handling responsibilities or the need to assess the issue.
This is why technical validation and triage are becoming part not only of the security function, but also of regulatory compliance.
The 24-Hour Deadline Changes Internal Security Operations
From 11 September 2026, where a manufacturer becomes aware of an actively exploited vulnerability or a severe incident, Article 14 reporting timelines become relevant.
The process includes:
- an early warning within 24 hours;
- a more detailed notification within 72 hours;
- for actively exploited vulnerabilities, a final report no later than 14 days after a corrective or mitigating measure becomes available;
- for severe incidents, a final report within one month after the 72-hour notification.
Reporting is conducted through the CRA Single Reporting Platform.
This means regulatory compliance cannot be designed as a purely legal process that begins only after an incident occurs.
When the 24-hour clock starts, an organisation cannot afford to spend that time determining:
- who owns the affected product;
- which versions are vulnerable;
- whether the exploit actually works;
- who should investigate it;
- who decides whether escalation is necessary;
- who is responsible for regulatory reporting.
A functioning vulnerability workflow therefore needs to exist in advance.
Security teams, developers, product teams, legal/compliance functions and management should already understand their respective responsibilities.
The Support Period Defines the Vulnerability Responsibility Horizon
The CRA also changes expectations regarding product support.
Article 13(8) requires manufacturers to define a support period during which vulnerabilities affecting the product and its components must be effectively handled in accordance with Part II of Annex I.
In most cases, the support period cannot be shorter than five years, unless the expected lifetime of the product itself is shorter.
But it would be incorrect to conclude that the CRA simply introduces “five years of support for every product.”
The Commission explains that where a product can reasonably be expected to remain in use for longer than five years, its support period should also be longer.
Five years therefore acts as a minimum safeguard in many cases, not as a universal support period.
Manufacturers must also clearly inform users when the support period ends, including at least the relevant month and year.
Coordinated Vulnerability Disclosure Becomes Part of Product Security
Another significant element of the CRA concerns engagement with independent security researchers and bug hunters.
The Commission's guidance explicitly recognises coordinated disclosure by security researchers as one of the ways in which a manufacturer may become aware of a vulnerability.
The practical consequence is important.
If a company has no clear vulnerability reporting channel, no triage process, no defined responsible team and no mechanism for communicating with researchers, this is not merely an inconvenience for the security department.
It may make it significantly harder for the company to fulfil its CRA responsibilities effectively.
Vulnerability Management Also Becomes an Evidence-Based Process
Finding and fixing a vulnerability is not sufficient by itself.
Manufacturers need to be able to reconstruct what happened.
For example:
- When did the company become aware of the vulnerability?
- Which products and versions were affected?
- How was applicability determined?
- How was the risk assessed?
- What remediation decision was taken?
- When did the fix become available?
- Was the vulnerability retested?
- Were users notified?
The CRA links cybersecurity risk assessment with technical documentation and the broader conformity framework.
The Commission also notes that cybersecurity risk assessment needs to be taken into account throughout planning, design, development, production, delivery and maintenance, while relevant documentation needs to be available to market surveillance authorities.
What Companies Should Be Doing Now
There is still time before the CRA becomes fully applicable.
But an effective vulnerability management capability cannot realistically be built a few weeks before a compliance assessment.
Companies that sell – or plan to sell – digital products in the EU should first perform CRA scoping.
They should determine:
- which products qualify as products with digital elements;
- where the company acts as the manufacturer;
- which cloud components qualify as remote data processing solutions;
- which third-party dependencies are part of the product;
- whether substantially modified versions may constitute a new placing on the market;
- what support period should apply.
The next step is not simply to check whether the company has a recent penetration testing report.
Instead, organisations should assess the maturity of the entire vulnerability lifecycle.
- Can an external security researcher report a vulnerability?
- Who receives the report?
- How quickly is it validated?
- Can affected products, components and versions be identified quickly?
- Who makes the remediation decision?
- How is the security fix delivered to users?
- Is retesting performed?
- How is disclosure handled?
- And if active exploitation is identified, can the organisation initiate its CRA reporting workflow within the required timeframe?
The answers to these questions reveal whether a functioning vulnerability management process actually exists.
From Security Best Practice to Legal Responsibility
The Cyber Resilience Act should not be viewed simply as another cybersecurity standard.
It is EU product legislation. For breaches of key cybersecurity obligations, including relevant requirements under Annex I and Articles 13 and 14, the CRA provides for maximum administrative fines of up to €15 million or 2.5% of the company's total worldwide annual turnover for the preceding financial year, whichever is higher.
This is the maximum potential penalty – not an automatic fine for every cybersecurity issue. The CRA provides for differentiated enforcement and includes specific exceptions for certain categories of entities.
Nevertheless, the question: “Do we have an effective vulnerability management process?” is gradually becoming much more than a question for the CISO.
BugStream's View: Vulnerability Management Should Be Continuous
At BugStream, we believe one of the most important changes introduced by the CRA is the transition from point-in-time security testing to continuous vulnerability management.
Vulnerabilities do not arise only from defects that existed on the day a product was first released.
They emerge as a result of:
- new code;
- new dependencies;
- configuration changes;
- new integrations;
- new attack techniques;
- vulnerabilities discovered only after the product has already entered the market.
This is why vulnerability management should combine internal and independent security testing, vulnerability disclosure, engagement with security researchers, validation and triage, remediation tracking, retesting and management of the complete vulnerability lifecycle.
BugStream does not view bug bounty programmes, Vulnerability Disclosure Programs (VDPs) or independent security testing as replacements for an internal security team or as a formal shortcut to “CRA compliance.”
They are tools that can support one of the most difficult elements of the process: continuously receiving real security findings, validating them, separating confirmed vulnerabilities from noise, coordinating remediation and maintaining an evidence-based history of how each vulnerability was handled.
This material was prepared by BugStream based on Regulation (EU) 2024/2847 and the European Commission's guidance on the application of the Cyber Resilience Act published on 27 July 2026. The Commission guidance is explanatory and non-binding. The final authoritative interpretation of EU law rests with the Court of Justice of the European Union. This material is provided for informational purposes only and does not constitute legal advice.