Under the Cyber Resilience Act (CRA), security updates are part of the manufacturer’s vulnerability-handling obligations: identified vulnerabilities must be addressed and remediated without delay, fixes must be distributed securely, users need usable update information, and automatic installation is required where the CRA makes it applicable. A reliable update process therefore has to connect the vulnerability decision, the affected product and release, the fix, verification evidence, distribution, and user communication.
What the CRA requires from a security-update process
The legal starting point is Annex I of Regulation (EU) 2024/2847. Part II requires manufacturers to address and remediate vulnerabilities without delay, including by providing security updates. It also requires mechanisms for secure distribution so that vulnerabilities can be fixed or mitigated in a timely manner.
When a security update is made available to address an identified security issue, the CRA requires it to be disseminated without delay and, as a rule, free of charge. The text contains a narrow exception where a manufacturer and a business user have agreed otherwise for a tailor-made product with digital elements. The update must be accompanied by advisory information that helps users understand the issue and any action they need to take.
These duties sit within the support period for the product. The Commission’s manufacturer guidance summarises the same lifecycle model: manufacturers must handle vulnerabilities for the indicated support period, while the CRA’s main obligations apply from 11 December 2027.
Treat remediation, release and distribution as separate controls
A vulnerability can be technically fixed but still leave users exposed if the corrected version is not released, cannot be obtained securely, or is not connected to the right affected product. Product teams should therefore separate at least four decisions:
- Remediation: what change addresses or mitigates the vulnerability?
- Release: which product variants and supported versions need a corrected release?
- Distribution: how will users obtain the authentic update securely?
- Communication: what must users know about the vulnerability, the affected versions and the action required?
This separation is useful because each stage can fail independently. A patch may pass engineering verification but be packaged for the wrong branch. A correct package may be published without an advisory. A valid advisory may point users to an update that cannot be authenticated or installed in their environment.
For each stage, retain evidence that lets another reviewer reconstruct what happened. Useful records include the vulnerability or issue identifier, affected product and release, remediation decision, change or artefact identifier, verification results, approval, release timestamp, distribution channel, advisory version and any rollout constraints. These are practical evidence recommendations rather than a universal metadata template prescribed by the CRA.
Security updates should be separable from feature updates
Annex I requires manufacturers, where technically feasible, to provide new security updates separately from functionality updates. Recital 57 explains the rationale: users should not have to install new functionality merely to receive the latest security fix.
This should influence release architecture before an incident occurs. If security fixes can only be delivered through a large feature upgrade, the manufacturer may face avoidable compatibility, qualification and deployment friction. Product teams should know which parts of the release pipeline can produce a security-only update, how that update is tested, and whether it can be applied without unrelated behaviour changes.
“Where technically feasible” is important. The Regulation does not say that every product must always support a perfectly isolated patch mechanism. The engineering task is to document the chosen update architecture, its constraints and the evidence supporting the release decision.
Automatic updates are important, but not universal
Annex I Part I includes automatic security updates where applicable. Recital 56 gives useful context: automatic notification, distribution, download and installation are especially relevant for consumer products, while users should be able to deactivate automatic updates through a clear mechanism and receive instructions on how to opt out.
The same recital also describes cases where the automatic-update requirement does not apply. These include products primarily intended to be integrated as components into other products and products for which users would not reasonably expect automatic updates, including professional ICT networks and critical or industrial environments where an automatic change could interfere with operations.
That means “CRA requires automatic updates for every product” is too broad. The safer implementation question is whether automatic installation is applicable to the specific product and use context. If it is, teams should test the default behaviour, opt-out path, notification flow and any temporary postponement mechanism that the product implements.
User instructions are part of the update design
Annex II requires information and instructions that enable secure installation, operation and use. For updates, that includes how security-relevant updates can be installed and, where the default automatic-install setting applies, how it can be turned off. The product information also has to identify the type of technical security support and the end date of the support period.
Operationally, update instructions should be version-controlled with the release process rather than maintained as an unrelated document. A release should have a known advisory, installation path, applicable product versions and any prerequisites or compatibility constraints.
Annex I Part II also requires public disclosure of information about fixed vulnerabilities once a security update has been made available. The disclosure should include a description of the vulnerability, information allowing users to identify the affected product, the impacts and severity, and clear remediation information. In justified cases, the manufacturer may delay disclosure until users have had an opportunity to apply the patch.
Keep issued security updates available
Article 13(9) adds an availability obligation that is easy to overlook after the immediate incident is closed. A security update made available to users during the support period must remain available after it is issued for at least 10 years or for the remainder of the support period, whichever is longer.
This is not the same question as how the support period itself is determined, which deserves its own product-lifecycle analysis. For the update process, the practical consequence is simpler: do not treat the patch repository as disposable release infrastructure.
Teams should define where historical security updates are retained, how users can still obtain them, how integrity can be verified, and how the update remains associated with the correct product and version. If distribution infrastructure changes, the organisation still needs a controlled migration path for required historical updates.
Free security updates have a narrow contractual exception
The CRA’s default rule for security updates that address identified security issues is that they are made available free of charge. The exception is not a general B2B carve-out: the text refers to a different agreement between the manufacturer and a business user for a tailor-made product with digital elements.
Commercial packaging should therefore not be allowed to silently redefine a security fix as a paid feature. Product, legal and commercial teams should identify in advance how the organisation distinguishes security remediation from optional functionality, and how exceptional tailor-made arrangements are documented.
The distinction also helps engineering. When a fix is bundled with a feature release, the team should still be able to identify which change is necessary to remediate the security issue and what users must receive to address it.
A practical security-update workflow
A repeatable workflow can turn the legal requirements into release controls:
- Confirm scope and impact. Identify the vulnerability, affected products, variants and supported releases.
- Record the remediation decision. Capture what will be fixed or mitigated and why.
- Implement and verify the change. Retain test results and evidence that the security objective was met.
- Determine the release form. Decide whether a security-only update is technically feasible and appropriate.
- Prepare secure distribution. Define the authentic package, integrity checks, delivery channel and rollback or recovery approach where relevant.
- Prepare user communication. State affected versions, impact, severity, remediation steps and installation guidance.
- Apply the automatic-update policy. Where automatic installation is applicable, verify the default behaviour, user control and notifications.
- Release without avoidable delay. Keep the remediation, release and communication timestamps connected.
- Monitor deployment issues. Capture material compatibility or installation failures and the actions taken.
- Retain the update and evidence. Preserve the issued update for the required availability period and keep the decision history traceable to the product lifecycle.
This workflow should integrate with existing engineering and delivery systems rather than create a parallel manual process. The important control is traceability: the organisation should be able to move from a vulnerability finding to the affected release, the implemented fix, the verification result, the update made available to users and the associated advisory.
Common implementation mistakes
Several patterns weaken a security-update process even when the patch itself is technically correct.
- Closing the vulnerability when code is merged. Users are not protected until an appropriate update is released and can be installed.
- Bundling every security fix into a feature upgrade. This can create unnecessary deployment barriers where a separate security update is technically feasible.
- Assuming automatic installation is always mandatory or never appropriate. Applicability depends on the product and use context.
- Publishing a patch without clear product scope. Users need to know which product and versions are affected.
- Treating advisories as marketing copy. Update communication should support accurate security decisions and installation.
- Overwriting historical update evidence. Later investigations may need to establish exactly what was available to a particular product version at a particular time.
- Letting download infrastructure expire with the release pipeline. Article 13(9) creates a much longer availability requirement for issued security updates.
- Treating “free of charge” as a consumer-only rule. The CRA’s stated exception is narrower and tied to an agreed tailor-made business product.
Keep update evidence connected to the release
The update file is only one part of the evidence chain. Teams also need the vulnerability decision, affected releases, verification evidence, advisory and distribution record to remain associated as the product evolves.
AA-sec is designed around traceability between vulnerability work, security evidence, release decisions and exact product or lifecycle context. It is intended to complement existing engineering and delivery systems; the manufacturer remains responsible for the engineering decisions and for determining its legal obligations.
A readiness test before 2027
Choose one supported product and simulate a realistic security update from start to finish. Start with a known vulnerability, identify the affected release, prepare the remediation, verify it, build the update package, draft the advisory and walk through the real distribution path.
Then ask whether the team can prove, without reconstructing the story from chat messages and individual laptops:
- which product versions were affected;
- what decision was made and by whom;
- which change addressed the issue;
- what verification evidence supported the release;
- when the update became available;
- how users were informed;
- whether automatic installation was applicable and how user control worked; and
- where the issued update and advisory will remain available.
The gaps become concrete backlog items: missing release ownership, unclear product scope, untested update channels, weak advisory procedures, lost historical artefacts or evidence that is not linked to the product version it supports.
The practical standard to aim for
CRA security updates should be managed as a lifecycle process: identify the affected product, remediate without delay, verify the fix, release it through a secure distribution mechanism, give users clear instructions and preserve the update and evidence for later use.
The strongest process is not the one with the most paperwork. It is the one in which product, security and release teams can reconstruct what was known, what was changed, which users and releases were affected, what was made available and what evidence supports the decision.
Official sources
- Regulation (EU) 2024/2847 — Cyber Resilience Act — EUR-Lex
- Cyber Resilience Act - Manufacturers — European Commission
- The Cyber Resilience Act - Summary of the legislative text — European Commission
- Commission publishes new guidance to support timely Cyber Resilience Act implementation — European Commission