CRA vulnerability remediation is a risk-based operational obligation. Manufacturers should rapidly assess confirmed vulnerabilities, determine affected products and versions, develop and verify an appropriate fix or mitigation, distribute security updates securely and without unnecessary delay, communicate useful remediation information and retain evidence explaining the timing and technical decisions made throughout the process.
Annex I Requires Vulnerabilities to Be Addressed Without Delay
Annex I Part II point 2 requires manufacturers, in relation to the risks posed to products with digital elements, to address and remediate vulnerabilities without delay, including by providing security updates. The wording combines urgency with a risk-based approach. It does not establish one identical numerical deadline for every ordinary vulnerability, but manufacturers should not allow confirmed security weaknesses to remain unresolved because they are waiting for a convenient feature-release schedule. The remediation workflow should move from technical assessment to corrective action with timing proportionate to the vulnerability's risk and product exposure.
- Confirm the vulnerability.
- Determine affected products and versions.
- Assess the cybersecurity risk.
- Select an appropriate remediation or mitigation.
- Avoid unnecessary remediation delay.
Risk Should Drive Remediation Priority
Part II point 2 expressly connects remediation to the risks posed to the product. Severity scores can help prioritisation, but they should not be the only factor. Manufacturers can also consider exploitability, attack preconditions, privileges required, exposed interfaces, affected assets, deployment scale, existing mitigations and consequences of successful exploitation. A vulnerability with a moderate generic score can be urgent in a product where the affected function is remotely reachable and highly privileged. Conversely, a high generic score may require product-specific analysis where the vulnerable function is absent or inaccessible.
- Assess exploitability.
- Assess reachability.
- Assess privileges and attack preconditions.
- Assess product-specific consequences.
- Document the prioritisation rationale.
Remediation Can Require More Than a Code Patch
A permanent software or firmware correction is often the preferred remediation, but vulnerability handling can involve several technical approaches. Depending on the vulnerability and product, manufacturers can change configuration, remove an exposed feature, replace a component, rotate credentials, update a dependency, modify access controls or provide another corrective measure. Temporary mitigations can reduce risk while a permanent fix is developed. The distinction should be clear in customer communication and internal records so that a workaround is not mistakenly treated as complete remediation when the underlying weakness remains.
- Develop a permanent fix where feasible.
- Use risk-reducing mitigations where necessary.
- Distinguish temporary mitigation from permanent remediation.
- Retest the affected security property.
- Track residual risk.
Security Updates Are a Core Remediation Mechanism
Part II point 2 expressly includes providing security updates as part of vulnerability remediation. Manufacturers should therefore maintain the engineering and distribution capability needed to correct supported products after they have been placed on the market. The update should address the identified vulnerability without introducing unacceptable new security or reliability problems. Regression testing should focus not only on whether the vulnerable behaviour changed but also on whether authentication, access control, integrity, availability or other relevant security properties still function correctly after the update.
- Develop updates for affected supported versions.
- Test the vulnerability fix.
- Perform relevant security regression testing.
- Verify installation and rollback behaviour.
- Track release status.
Security Updates Should Be Separate From Feature Updates Where Technically Feasible
Annex I Part II point 2 states that, where technically feasible, new security updates should be provided separately from functionality updates. This helps prevent remediation from being delayed until a larger feature release is ready and avoids requiring users to adopt unrelated functionality simply to obtain a security correction. Manufacturers should structure release processes so security fixes can move independently where the architecture permits. Where separation is not technically feasible, the technical constraint and resulting remediation timing should be understood and documented.
- Support security-only releases where technically feasible.
- Avoid tying urgent fixes to unrelated feature schedules.
- Document technical constraints.
- Test the security update independently where possible.
Fixed Vulnerabilities Need Clear Remediation Information
Annex I Part II point 4 requires manufacturers, once a security update has been made available, to share and publicly disclose information about fixed vulnerabilities. The required information includes a description, information allowing users to identify the affected product, impacts, severity and clear accessible information helping users remediate the vulnerability. In duly justified cases, publication can be delayed where the manufacturer considers the security risks of publication to outweigh the security benefits, until users have had the possibility to apply the relevant patch. Security advisory processes should therefore be connected to the update-release workflow.
- Describe the fixed vulnerability.
- Identify affected products.
- Explain impact and severity.
- Provide clear remediation information.
- Document justified disclosure delays where applicable.
Security Updates Need Secure and Timely Distribution
Part II point 7 requires mechanisms for secure update distribution so that vulnerabilities can be fixed or mitigated in a timely manner. Part II point 8 requires available security updates addressing identified security issues to be disseminated without delay. A correct patch that cannot reach users securely does not complete the remediation process. Manufacturers should protect update authenticity, integrity and delivery infrastructure, monitor release availability and ensure supported products can identify or receive the appropriate update. Where automatic security updating is applicable, that capability should integrate with the same secure distribution architecture.
- Protect update authenticity.
- Protect update integrity.
- Disseminate security updates without unnecessary delay.
- Confirm affected versions can obtain the correction.
- Monitor update-distribution failures.
Security Updates Are Generally to Be Provided Free of Charge
Annex I Part II point 8 provides that security updates addressing identified security issues should, unless otherwise agreed between a manufacturer and a business user in relation to a tailor-made product with digital elements, be disseminated free of charge. The purpose is to avoid placing a routine payment barrier between users and the correction of supported product security weaknesses. Manufacturers should distinguish security remediation from optional new functionality in commercial packaging and customer communication. The specific tailor-made business-product qualification should not be treated as a general exemption for ordinary business customers.
- Do not charge ordinary users for required security remediation.
- Separate optional paid features from security fixes.
- Document any qualifying tailor-made business agreement.
- Keep security-update entitlement clear.
Remediation and Article 14 Reporting Are Separate Workstreams
A manufacturer may need to remediate a vulnerability even when Article 14 reporting is not triggered. Conversely, an actively exploited vulnerability can trigger Article 14 deadlines while remediation work is still underway. Engineering teams should therefore avoid treating regulatory notification as a substitute for fixing the weakness or treating remediation as a reason to ignore reporting obligations. The two workflows should exchange information but maintain their own triggers, deadlines and evidence. A vulnerability record can link the technical remediation timeline with any separate reporting decisions.
- Remediate vulnerabilities regardless of whether Article 14 applies.
- Assess reporting triggers separately.
- Coordinate technical and regulatory teams.
- Preserve both remediation and reporting timelines.
Remediation Should Be Verified Before Closure
A vulnerability should not be closed merely because a code change has been merged. Manufacturers should verify that the correction reaches the affected product, prevents or mitigates the vulnerable behaviour and does not create significant new security problems. Testing can reproduce the original issue, validate negative cases, inspect package authenticity and verify installation. Where only a mitigation is available, teams should document residual risk and conditions under which a permanent remediation will still be required. Closure criteria should be consistent enough that remediation status has a clear meaning across product teams.
- Retest the original vulnerability.
- Verify supported affected versions.
- Perform security regression testing.
- Verify update installation.
- Record residual risk.
- Define clear closure criteria.
Evidence for CRA Vulnerability Remediation
Evidence can include vulnerability assessments, affected-version records, risk-prioritisation decisions, fix commits, patch-development records, security-test results, update packages, distribution evidence, user advisories and closure decisions. The remediation timeline should make it possible to understand when the vulnerability became known, when risk was assessed, when a corrective measure became available and how users were informed. Manufacturers should preserve enough information to demonstrate that remediation timing was proportionate to product risk and that the security correction was delivered through a trustworthy mechanism.
- Vulnerability assessment.
- Affected-product mapping.
- Risk-prioritisation rationale.
- Fix and test evidence.
- Security-update release record.
- Secure distribution evidence.
- Security advisory.
- Remediation closure record.
Official sources
Read the full legal text and Commission material for precise wording, qualifications and updates.