A CRA security-update process therefore covers more than creating a patch. The manufacturer needs to develop and verify the correction, distribute it securely, provide relevant advisory information, apply the free-of-charge rule subject to the specific tailor-made business-product exception, and keep issued security updates available for the period required by Article 13(9).
Security Updates Are Part of Vulnerability Remediation
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. A security update is therefore one remediation mechanism within the broader vulnerability-handling process. Not every finding necessarily requires the same type of patch, but where a software or firmware correction is needed, the manufacturer should connect the vulnerability case to the update development and release process.
- Connect the vulnerability case to remediation.
- Identify affected product versions.
- Develop the appropriate correction.
- Verify the correction before release.
Security Updates Should Be Separate From Functionality Updates Where Technically Feasible
Annex I Part II point 2 states that where technically feasible, new security updates shall be provided separately from functionality updates. This reduces the risk that an important security correction is delayed because unrelated features are not ready. It can also allow users to obtain a security fix without adopting unrelated functional changes. The requirement is qualified by technical feasibility, so manufacturers should understand whether their packaging and release architecture can support security-only releases.
- Support security-only releases where technically feasible.
- Avoid unnecessary dependency on feature-release schedules.
- Document technical constraints where separation is not feasible.
- Test the security-only release path.
Updates Need a Secure Distribution Mechanism
Annex I Part II point 7 requires mechanisms to securely distribute updates so vulnerabilities are fixed or mitigated in a timely manner and, where applicable for security updates, in an automatic manner. Secure distribution should protect the user from unauthorised or corrupted update packages. Depending on the product architecture, this can involve package signatures, integrity verification, protected metadata, trusted update sources and controls preventing installation of an update intended for a different product or version.
- Protect update authenticity.
- Protect update integrity.
- Target the correct product and version.
- Reject unauthorised or corrupted update packages.
Automatic Updating Is One Part of the Wider Update Framework
The CRA contains specific automatic security-update requirements, but automatic updating is not the whole security-update framework. Part II point 7 refers to automatic mechanisms where applicable for security updates, while Annex I Part I point 2(c) contains the detailed secure-by-default automatic-update requirements. The existing automatic-security-updates guide addresses those mechanics separately. This article focuses on the broader manufacturer obligations that apply from remediation through distribution and continued availability.
- Separate the broader update process from automatic-installation mechanics.
- Apply automatic updating where required and applicable.
- Maintain secure manual update paths where relevant.
- Keep user controls consistent with the Regulation.
Available Security Updates Must Be Disseminated Without Delay
Annex I Part II point 8 requires manufacturers to ensure that where security updates are available to address identified security issues, they are disseminated without delay. This obligation concerns getting an available correction to users rather than leaving an already completed security update unpublished or inaccessible. It works alongside point 2, which requires the underlying vulnerability to be addressed and remediated without delay in relation to the risks posed.
- Release available security corrections promptly.
- Avoid unnecessary publication delay.
- Make the update reachable by affected users.
- Track the release date.
Security Updates Are Generally Free of Charge
Part II point 8 states that available security updates addressing identified security issues are to be disseminated free of charge, unless otherwise agreed between a manufacturer and a business user in relation to a tailor-made product with digital elements. This is a specific exception and should not be expanded into a general ability to charge ordinary users for vulnerability remediation. Product and commercial teams should keep security-support terms consistent with the CRA requirement.
- Apply the free-of-charge rule.
- Treat the tailor-made business-product wording as a specific exception.
- Keep commercial terms aligned with security obligations.
- Avoid placing ordinary security remediation behind an unrelated paid feature upgrade.
Updates Need Advisory Messages
Part II point 8 also requires security updates to be accompanied by advisory messages providing users with relevant information, including potential action to be taken. The advisory should help users understand that a security correction exists, which products or versions are affected and whether any installation, configuration or operational action is required. Point 4 separately requires public information about fixed vulnerabilities once a security update has been made available.
- Identify the affected product.
- Explain relevant user action.
- Coordinate the advisory with the available update.
- Keep fixed-vulnerability information accurate.
The Update Should Be Verified Before Distribution
The CRA does not require manufacturers to trade security testing for speed. A security update should be tested sufficiently to demonstrate that it addresses the vulnerability and does not create an obvious security regression. The verification should cover the original vulnerable condition, important bypasses and the update installation path. High-risk vulnerabilities can justify expedited testing and release processes, but the update should still have traceable evidence connecting the vulnerability, fix, build and affected versions.
- Retest the vulnerable condition.
- Check important bypasses.
- Test update installation.
- Record the released build or package.
Issued Security Updates Have a Long Availability Requirement
Article 13(9) requires each security update made available to users during the support period to remain available after issuance for a minimum of 10 years or for the remainder of the support period, whichever is longer. This is an availability requirement for updates already issued. It should not be misread as a rule requiring every manufacturer to create new security updates for 10 years after the support period has ended.
- Preserve issued security-update packages.
- Maintain download or distribution availability.
- Keep version information understandable.
- Distinguish update availability from creation of new fixes.
Maintain Version-Specific Update Evidence
A security-update record should identify the vulnerability addressed, affected versions, corrected versions, relevant test evidence, release date, update package, advisory and distribution status. This information supports vulnerability case management and technical documentation and helps the manufacturer demonstrate that an identified issue progressed from assessment through remediation to user availability.
- Vulnerability identifier.
- Affected versions.
- Corrected versions.
- Verification evidence.
- Release date.
- Advisory reference.
Official sources
Read the full legal text and Commission material for precise wording, qualifications and updates.