CRA vulnerability handling begins when a potential vulnerability is discovered or reported and continues through triage, affected-version analysis, remediation, testing, update release, disclosure and support. Article 14 notification is a separate regulatory branch for actively exploited vulnerabilities and severe incidents and should not be confused with the broader vulnerability-management obligations.
Vulnerability Handling Is a Lifecycle Obligation
The Cyber Resilience Act treats vulnerability handling as an ongoing manufacturer responsibility rather than a one-time pre-market assessment. Article 13(7) requires manufacturers to systematically document relevant cybersecurity aspects, including vulnerabilities of which they become aware and relevant information provided by third parties. Where applicable, the cybersecurity risk assessment must also be updated. Article 13(8) then requires vulnerabilities of the product, including its components, to be handled effectively for the support period in accordance with Annex I Part II.
- Document vulnerabilities that become known.
- Capture relevant information from third parties.
- Update the cybersecurity risk assessment where appropriate.
- Maintain vulnerability handling throughout the support period.
Annex I Part II Defines the Core Vulnerability-Handling System
Annex I Part II sets out a connected set of vulnerability-handling requirements. Manufacturers must identify and document vulnerabilities and components, address and remediate vulnerabilities without delay, apply effective and regular security tests and reviews, disclose information about fixed vulnerabilities, maintain a coordinated vulnerability disclosure policy, provide a contact address for vulnerability reports, securely distribute updates and disseminate available security updates without delay. These requirements work together as an operational system rather than as isolated compliance statements.
- Identify and document.
- Assess and remediate.
- Test and review.
- Coordinate disclosure.
- Receive reports.
- Distribute updates securely.
- Communicate fixes.
The Support Period Defines How Long Effective Handling Must Continue
Article 13(8) requires manufacturers to determine a support period reflecting how long the product is expected to be in use. Relevant considerations include reasonable user expectations, the nature and intended purpose of the product and relevant Union law determining product lifetime. Manufacturers may also consider comparable products, availability of the operating environment, support periods of third-party components providing core functions and relevant guidance. The support period is generally at least five years. Where the product is expected to be used for less than five years, it corresponds to that expected use time.
- Consider expected product use.
- Consider reasonable user expectations.
- Consider product nature and intended purpose.
- Consider relevant product-lifetime law.
- Document the support-period rationale.
Support-Period Decisions Belong in Technical Documentation
The manufacturer must include in the technical documentation the information taken into account when determining the support period. This means the end date should not be an unexplained commercial choice. Product teams should be able to show which lifecycle assumptions, user expectations, component dependencies and legal requirements informed the decision. Annex II also requires the end date of the support period and the type of technical security support to be communicated to users.
- Record support-period factors.
- Identify important component dependencies.
- Record the resulting end date.
- Keep user-facing support information consistent.
Security Update Availability Can Extend Beyond the Support Period
Article 13(9) creates an additional availability rule for security updates already made available during the support period. Each such update must remain available after issuance for a minimum of 10 years or for the remainder of the support period, whichever is longer. This is different from saying that the manufacturer must continue creating new security updates for 10 years after every product. The rule concerns continued availability of updates that were already issued.
- Distinguish support duration from update-file availability.
- Keep issued security updates accessible for the required period.
- Maintain version and package traceability.
- Avoid removing historical security fixes too early.
Vulnerability Handling Includes Third-Party Components
Article 13(8) expressly refers to vulnerabilities of the product including its components. Annex I Part II also requires manufacturers to identify and document components and vulnerabilities, including through a software bill of materials covering at least top-level dependencies. A manufacturer therefore needs visibility into third-party components that influence product security and a process for receiving and assessing vulnerability information about those components.
- Maintain component visibility.
- Track relevant dependency versions.
- Monitor vulnerability information.
- Assess whether component vulnerabilities affect supported products.
Internal and External Vulnerability Reports Both Matter
Article 13(8) requires appropriate policies and procedures to process and remediate potential vulnerabilities reported from internal or external sources. This means the operational process should not depend solely on public vulnerability databases. Findings can originate from internal testing, developers, researchers, customers, suppliers, incident investigations, threat intelligence or automated tools. The manufacturer needs a consistent way to record, assess and route those findings.
- Internal security testing.
- Developer findings.
- Security researcher reports.
- Customer reports.
- Supplier and dependency advisories.
- Threat intelligence.
Coordinated Vulnerability Disclosure Is a Separate Requirement
Annex I Part II requires manufacturers to put in place and enforce a policy on coordinated vulnerability disclosure. It also requires measures that facilitate sharing information about potential vulnerabilities, including a contact address for reporting discovered vulnerabilities. A CVD policy gives researchers and other reporters a defined path for submitting findings and allows the manufacturer to coordinate assessment, remediation and eventual disclosure.
- Publish a vulnerability-reporting route.
- Define what information reporters should provide.
- Acknowledge and track reports.
- Coordinate remediation and disclosure.
Article 14 Reporting Is Not the Same as Vulnerability Handling
Article 14 creates mandatory regulatory reporting for actively exploited vulnerabilities and severe incidents having an impact on product security. Those reporting obligations have applied since 11 September 2026. The broader vulnerability-handling obligations are different. A vulnerability can require investigation and remediation even when it does not meet the Article 14 actively exploited vulnerability threshold. The manufacturer should therefore run the vulnerability-management workflow and the Article 14 reporting decision as connected but distinct processes.
- Handle potential vulnerabilities whether or not Article 14 applies.
- Assess Article 14 triggers separately.
- Preserve the awareness timeline where reporting may be required.
- Do not treat the SRP as the vulnerability-management system.
Remediation Should Flow Into Secure Update Distribution
Annex I Part II requires manufacturers to address and remediate vulnerabilities without delay in relation to the risks posed to the product. Where remediation requires a security update, the update must move through testing, release and secure distribution. Part II also requires mechanisms to securely distribute updates and requires available security updates addressing identified security issues to be disseminated without delay, subject to the Regulation's specific tailor-made business-product exception concerning free-of-charge provision.
- Develop the remediation.
- Test the fix.
- Identify affected versions.
- Distribute the update securely.
- Provide relevant user information.
Vulnerability Handling Needs Version-Specific Evidence
A defensible vulnerability record should identify the affected product, versions and components, source of the report, assessment, remediation decision, security update where applicable, verification results and disclosure status. It should also record whether Article 14 reporting was assessed. This evidence allows the manufacturer to demonstrate that vulnerabilities were not simply received but were processed through a controlled lifecycle during the support period.
- Vulnerability identifier.
- Affected product and versions.
- Affected component.
- Assessment and risk decision.
- Remediation and test evidence.
- Disclosure status.
- Article 14 assessment where relevant.
Official sources
Read the full legal text and Commission material for precise wording, qualifications and updates.