Where the Article 13(10) conditions do not apply or an older version remains a supported branch that users cannot move away from without additional cost or incompatibility, backporting can be one practical way to meet the product's vulnerability-remediation obligations. The CRA does not prescribe backporting as the only method.
The CRA Does Not Require Every Security Fix to Be Backported
The Cyber Resilience Act does not require every security fix to be backported to every historical software version. The manufacturer should first determine which product versions remain supported, which versions are affected and whether users can move to another supported version without creating the problems addressed by Article 13(10). Backporting is an engineering method for providing remediation, not a separately named universal CRA requirement.
- Identify affected versions.
- Identify supported versions.
- Assess available upgrade paths.
- Choose an effective remediation method.
Article 13(10) Creates a Specific Latest-Version Route
Article 13(10) applies where a manufacturer has placed subsequent substantially modified versions of a software product on the market. In that situation, the manufacturer may ensure compliance with the Annex I Part II point 2 vulnerability-remediation requirement only for the version most recently placed on the market if the conditions in Article 13(10) are satisfied.
- Confirm that subsequent substantially modified versions exist.
- Identify the latest version placed on the market.
- Assess every Article 13(10) condition.
- Do not expand the provision beyond Part II point 2.
Previous-Version Users Must Receive the Latest Version Free of Charge
The Article 13(10) route is conditional on users of previously placed software versions having access to the latest version free of charge. A manufacturer cannot rely on the latest-version route if security remediation effectively requires an affected user to purchase a new software licence or paid version merely to regain vulnerability support.
- Provide access free of charge.
- Identify eligible previous-version users.
- Avoid turning security remediation into a paid upgrade.
- Document the upgrade path.
Users Must Not Face Additional Environment-Adjustment Costs
Article 13(10) also requires that users do not incur additional costs to adjust the hardware and software environment in which they use the original product. A supposedly free upgrade may therefore fail the condition if it requires customers to buy new hardware, replace another paid software platform or incur additional environment-adjustment costs merely to obtain the supported version.
- Assess hardware compatibility.
- Assess operating-system compatibility.
- Assess required platform changes.
- Identify additional costs to users.
Article 13(10) Does Not Erase Every Vulnerability-Handling Requirement
Article 13(10) specifically refers to compliance with the essential cybersecurity requirement in Annex I Part II point 2. It should not be read as automatically cancelling every other vulnerability-handling requirement for previous substantially modified versions. Recital 40 expressly explains that other obligations, such as coordinated vulnerability disclosure and measures facilitating vulnerability information sharing, continue for subsequent substantially modified versions during the support period.
- Keep the Article 13(10) scope precise.
- Continue relevant CVD processes.
- Continue vulnerability-reporting contact measures.
- Keep supported-product vulnerability records.
Backporting Can Be Appropriate When Users Cannot Move to the Latest Version
If users cannot move to the latest supported version without additional costs, incompatible hardware or another material barrier, the Article 13(10) conditions may not provide the manufacturer with the latest-version route. Where an older product version remains within its support obligations, backporting the security correction can be one practical remediation strategy. Replacement, mitigation or another effective approach may also be possible depending on the product architecture.
- Check user upgrade feasibility.
- Check support status.
- Assess backport feasibility.
- Assess alternative remediation.
Hardware Compatibility Can Require an Older Software Branch
Recital 40 gives the example of a hardware product such as a smartphone that is not compatible with the latest version of the operating system it originally used. The recital states that the manufacturer should continue to provide security updates at least for the latest compatible version of the operating system during the support period. This reinforces the practical importance of compatibility when deciding whether users can simply be moved to the newest software version.
- Identify hardware compatibility limits.
- Identify the latest compatible version.
- Keep support-period obligations visible.
- Avoid assuming the newest software runs on every supported device.
Backport the Smallest Safe Change Where Practical
Older branches can differ substantially from the current product. A backport should therefore focus on correcting the vulnerable behaviour without importing unnecessary unrelated feature changes. The exact implementation depends on the codebase. In some cases the original fix can be applied directly; in others the security logic needs to be adapted to older APIs or architecture.
- Identify the security-relevant change.
- Avoid unnecessary feature changes.
- Adapt the fix to the older branch.
- Review branch-specific behaviour.
Backports Need Their Own Regression Testing
A fix that passes testing on the newest release is not automatically safe on an older branch. Dependencies, APIs, configuration and surrounding code can differ. Each backport should receive regression testing appropriate to the affected branch, including retesting the original vulnerability, checking important bypasses and verifying that update installation works correctly.
- Retest the vulnerability.
- Test branch-specific behaviour.
- Check important bypasses.
- Test update installation.
Track Security Fixes Across Product Versions
The vulnerability case should identify which versions are affected, which versions receive a backport, which versions are remediated through upgrade and which versions are outside support. This version matrix is particularly important where one vulnerability affects several branches with different code. Users and security advisories should receive accurate version-specific remediation information.
- Affected-version matrix.
- Backported versions.
- Upgrade-remediated versions.
- Unsupported versions.
- Corrected release identifiers.
Security-Only Release Paths Can Help Backporting
Annex I Part II point 2 states that where technically feasible, new security updates should be provided separately from functionality updates. A maintained security-only release path can make backporting easier because the older supported branch does not need to absorb unrelated functionality merely to receive a correction. This can reduce regression risk and shorten remediation time.
- Maintain security-only release capability.
- Separate unrelated features.
- Reduce regression surface.
- Preserve update traceability.
Issued Backports Remain Subject to Security-Update Availability Rules
When a backported security update is made available during the support period, Article 13(9)'s availability rule applies in the same way as for other security updates. The manufacturer should therefore preserve the released package for the required period and keep enough version information for users to identify the correct historical update.
- Preserve the backport package.
- Record the release date.
- Identify the supported branch.
- Maintain required availability.
Document Why Each Version Was Backported, Upgraded or Retired
A defensible version-level record should identify support status, affected versions, the Article 13(10) analysis where relevant, compatibility constraints, remediation method, test results and release identifiers. This makes it possible to explain why one branch received a backport while another was remediated through a free upgrade to the latest version.
- Support status.
- Article 13(10) analysis.
- Compatibility evidence.
- Remediation method.
- Test evidence.
- Release identifier.
Official sources
Read the full legal text and Commission material for precise wording, qualifications and updates.