Understanding the 8 Vulnerability Handling Requirements of the Cyber Resilience Act

The Cyber Resilience Act (CRA) introduces a new legal baseline for cybersecurity in connected products across the EU. While much attention has been given to the 13 essential security requirements, a separate set of 8 vulnerability handling requirements will be coming into effect by 11 December 2027.

In addition, the reporting obligations for actively exploited vulnerabilities and severe incidents in products with digital elements will already apply from 11 September 2026. This means manufacturers must have processes in place to detect, assess, and notify authorities of critical security issues in their products already before the full set of vulnerability handling requirements is in force.

These obligations affect all products withdigital elements, and non-compliance carries the same serious consequences: denial of CE marking, potential market bans, and fines of up to €15 million or 2.5% of global annual turnover.

Given their impact, understanding and implementing these vulnerability handling requirements should be a top priority for manufacturers. They don’t just demand technical fixes, they represent a structural shift in how companies must organize product development, incident response, and post-market support across the entire product lifecycle.

At their core, the CRA’s vulnerability handling requirements effectively mandate the implementation of:

• Software Bill of Materials (SBOM)

• Vulnerability Disclosure & Reporting Procedures

• Security Testing Capabilities

• Mechanisms for Timely Security Updates

• Secure Software Development Lifecycle (SDLC)

• Vulnerability scanning

• Risk management

This post breaks down what each of the eight obligations entails, and what they mean for your organization in practice.

For a deeper dive into other areas of the Cyber Resilience Act, explore our CRA Knowledge Hub for more insights.

The 8 CRA Vulnerability Handling Requirements

What Each CRA Vulnerability Handling Requirement Means and How to Address It

🔗 (1) Identify and Document Vulnerabilities

CRA Regulation Text:

“identify and document vulnerabilities and components contained in products with digital elements, including by drawing up a software bill of materials in a commonly used and machine-readable format covering at the very least the top-level dependencies of the products”

To meet this requirement, manufacturers of products with digital elements must know what software components are included in their products. They need to identify and track major dependencies and be aware of known vulnerabilities. To ensure this, they must create a Software Bill of Materials (SBOM), a machine-readable inventory of components that can be analyzed, updated, and shared. The SBOM enables all stakeholders to assess security risks throughout the product lifecycle.

In practice, SBOM generation should be integrated directly into CI/CD pipelines so that every new build automatically produces an up-to-date inventory of components. These pipelines should also include automated vulnerability scanning to compare all software components against databases such as CVE listings, enabling early detection of insecure dependencies. Established formats like CycloneDX, SPDX, and SWID support interoperability and automation. To meet compliance needs, manufacturers should maintain the SBOM and their vulnerability disclosure policy as part of the technical documentation, keep them updated throughout the support period, and provide them to authorities on request.

🔗 (2) Risk Management & Security Updates

CRA Regulation Text:

"in relation to the risks posed to products with digital elements, address and remediate vulnerabilities without delay, including by providing security updates; where technically feasible, new security updates shall be provided separately from functionality updates"

If vulnerabilities are found in a product with digital elements, the manufacturer must fix them quickly and provide timely security updates. Products should be designed so vulnerabilities can be addressed without delay, and, where possible, security patches should be delivered separately from feature updates. This ensures critical fixes can be installed promptly and reliably.

In practice, the update mechanism should enable fast rollout of security fixes, ideally allowing targeted patches without requiring full system updates. Where possible, software and firmware can be structured so critical components are separable and easier to patch. Updates should be delivered through secure channels with integrity checks, and manufacturers should maintain records of update activities to support traceability and demonstrate compliance.

🔗 (3) Security Testing

CRA Regulation Text:

"apply effective and regular tests and reviews of the security of the product with digital elements"

To meet this requirement, manufacturers must regularly test products to ensure they remain secure over time. A one-time check is not enough, security tests must be repeated throughout the lifecycle to address evolving technologies, new threats, and product updates.

The type and frequency of security testing should be guided by the product’s risk assessment. A connected consumer device or an industrial controller all have different attack surfaces and therefore require different testing approaches. Factors such as architecture, interfaces, and deployment context strongly influence which tests are most effective.

In practice, manufacturers can draw from a range of methodologies and tools to implement this requirement. Examples include penetration testing to simulate real-world attacks, static or dynamic code analysis to identify security weaknesses, and fuzz testing to expose input-handling flaws. Secure code reviews and architecture reviews provide additional assurance, especially when repeated after significant design or feature changes. Test processes should be formally scheduled, documented, and updated in line with evolving risks, ensuring that security testing remains both effective and proportionate to the product’s intended use and threat exposure.

🔗 (4) Notification for Security Updates & Vulnerability Disclosure

CRA Regulation Text:

"once a security update has been made available, share and publicly disclose information about fixed vulnerabilities, including a description of the vulnerabilities, information allowing users to identify the product with digital elements affected, the impacts of the vulnerabilities, their severity and clear and accessible information helping users to remediate the vulnerabilities; in duly justified cases, where manufacturers consider the security risks of publication to outweigh the security benefits, they may delay making public information regarding a fixed vulnerability until after users have been given the possibility to apply the relevant patch"

When a manufacturer issues a security update, they must also inform the public about what was fixed. This includes describing the vulnerability, its impact, affected products, severity, and how users can stay protected. Each issue must be tied to specific product versions so users can see if they are affected.

In practice, this requirement can be met by establishing a structured vulnerability disclosure process. Manufacturers should publish advisories for each resolved issue that include identifiers such as CVE numbers, affected product versions, and standardized severity ratings (e.g., CVSS). Advisories should provide actionable remediation steps in language accessible to both technical administrators and non-technical users. A coordinated vulnerability disclosure (CVD) process with timelines for researchers and partners can help ensure consistency. Where immediate publication would create undue risk, temporary delays may be justified, but only until users have had the opportunity to apply the security update.

🔗 (5) Coordinated Vulnerability Disclosure Policy

CRA Regulation Text:

"put in place and enforce a policy on coordinated vulnerability disclosure"

Manufacturers are required to maintain a structured process that lets researchers, customers, or other parties report discovered vulnerabilities. Reports must be handled quickly and responsibly, with cooperation between reporter and manufacturer to resolve issues before public disclosure. Products should provide a secure reporting channel, while manufacturers must follow internal procedures to track, assess, and address reports.

To implement this, manufacturers should publish a vulnerability disclosure policy with clear contact details (e.g., dedicated email or web form) that support secure communication. Internally, reports should be logged in a tracking system, assigned for review, and resolved within defined timelines. Reporters should receive confirmation and updates, with disclosure coordinated to both protect users and recognize the reporter’s role.

🔗 (6) Vulnerability Sharing & Reporting

CRA Regulation Text:

"take measures to facilitate the sharing of information about potential vulnerabilities in their product with digital elements as well as in third-party components contained in that product, including by providing a contact address for the reporting of the vulnerabilities discovered in the product with digital elements"

Manufacturers are required to provide a clear and accessible way for users, researchers, or partners to report security issues in the product or its third-party components. This means offering a visible contact method, such as a dedicated email or form, and encouraging responsible reporting so vulnerabilities can be fixed quickly.

In practice, manufacturers can strengthen this by supporting secure communication (for example, publishing a PGP key), and by ensuring that reports are acknowledged, logged, and triaged internally. Routing issues to the right engineering or security teams helps ensure efficient resolution. The process should cover both direct product vulnerabilities and those arising from integrated third-party components. While CRA sets only the basic requirement of facilitating sharing, implementing structured intake and tracking builds trust with researchers and customers and supports timely remediation.

🔗 (7) Security Update Distribution

CRA Regulation Text:

"provide for mechanisms to securely distribute updates for products with digital elements to ensure that vulnerabilities are fixed or mitigated in a timely manner and, where applicable for security updates, in an automatic manner"

Manufacturers must ensure that security updates can be delivered and applied securely so that vulnerabilities are resolved in a timely way. Where technically feasible and appropriate to the product context, updates should be installed automatically to reduce the window of exposure. In other cases, secure manual update processes must be available to users.

In practice, this means providing a reliable and tamper-resistant update mechanism. Updates should be transmitted over secure channels, verified through digital signatures, and applied in a way that prevents incomplete or corrupted installations. To support accountability, manufacturers may maintain update logs and allow users or administrators to verify update status. For connected devices, differential or modular updates can reduce disruption and ensure that security fixes reach systems more quickly. Embedding such mechanisms helps ensure vulnerabilities are mitigated effectively without introducing new risks.

🔗 (8) Update Distribution and User Guidance

CRA Regulation Text:

"ensure that, where security updates are available to address identified security issues, they are disseminated without delay and, unless otherwise agreed between a manufacturer and a business user in relation to a tailor-made product with digital elements, free of charge, accompanied by advisory messages providing users with the relevant information, including on potential action to be taken"

Manufacturers must deliver security updates to users promptly and without additional cost, except in cases where a separate agreement exists for tailor-made business products. Alongside each update, users must receive clear advisory messages explaining what the update addresses, its importance, and any actions required to ensure the fix is effective.

In practice, this means maintaining a distribution system that can notify users directly or apply updates automatically, depending on the product context. Advisory messages should be written in a way that is understandable to both technical and non-technical users, with severity information included where relevant.

How to build CRA Readiness for vulnerability handling requirements

The Cyber Resilience Act (CRA) marks a turning point in how cybersecurity is approached across the EU’s digital product landscape. What was once best practice is now becoming legally binding: vulnerability handling is no longer optional, it’s a regulatory requirement.

To address the CRA’s 8 vulnerability handling requirements effectively, manufacturers should implement the following core capabilities:

• Secure Software Development Lifecycle (SDLC): Integrating security reviews and controls into each stage of development.

• Software Bill of Materials (SBOM): To track top-level dependencies, identify vulnerabilities in third-party components, and maintain visibility across product lifecycles.

• Automated Vulnerability Scanning: To continuously detect known weaknesses in software, configurations, and dependencies, ideally integrated into CI/CD pipelines.

• Vulnerability Disclosure Policy (CVD): To define how researchers, customers, and partners can report vulnerabilities and how disclosure is coordinated.

• Vulnerability Reporting Channels: To provide accessible and secure contact points for reporting issues in both the product and integrated third-party components.

• Security Testing: To apply regular, risk-based testing and reviews of product security, adapted to architecture, interfaces, and use cases.

• Security Update Distribution: To deliver patches securely and reliably, using mechanisms that prevent tampering and support timely remediation.

• Provision of Security Updates: To ensure updates are made available without delay and free of charge (except in agreed business-to-business cases), with clear advisories for users.

Getting this right is about more than deploying the right security tools, itrequires a mindset shift and organizational change, with technology as the enabler, not the solution in itself. It’s a step toward building trust, resilience, and long-term readiness in a regulatory landscape that’s only getting stricter.

This content piece is one of many unpacking the CRA in detail, find the full overview in our CRA Guide.

Not sure where to begin? We’re working closely with manufacturers to help translate CRA requirements into technical specifications without adding unnecessary complexity.

Let’s talk.