CRA Firmware Security Update: Do You Really Need a Security Branch for Every Old Version?

A Question Every Firmware Team Will Eventually Face

Firmware rarely gets updated for just one reason. A single Maintenance Release (MR) often bundles bug fixes, new features, and vulnerability fixes together. But the EU Cyber Resilience Act (CRA) adds a twist: where technically feasible, security updates should be provided separately from feature updates. This raises a real-world question many manufacturers now face: if a customer is still on an old firmware version and only wants the security fix — not the new feature that came with a later release — does the manufacturer have to build a security-only branch for every historical version?

CRA Firmware Security Update Rules: Two Separate Questions

To answer this, it helps to separate two different CRA requirements. The first, under Article 13(10) and Recital 40, addresses which software version must keep receiving vulnerability fixes. The second, under Annex I, Part II, Point (2) and Recital 57, addresses how a security update should be packaged. These are not the same question, and mixing them up leads to the wrong conclusion — that every old version must be maintained forever.

Does a New Feature Mean You Owe a Security Patch to Old Users?

Not automatically. The key test is whether the new release counts as a “substantial modification” under the CRA.

When Manufacturers Can Focus on the Latest Version

If the newer version is a substantial modification, Article 13(10) allows the manufacturer to concentrate vulnerability remediation on the most recently released version — as long as two conditions are met: users can get the new version for free, and upgrading does not force them to pay for new hardware or software changes. In that case, the manufacturer is not required to build a separate security-only branch for the older version. The upgrade path itself satisfies the obligation.

When the Update Isn’t “Substantial” at All

Not every new feature qualifies as substantial. Small changes like new icons, added languages, or minor UI tweaks usually don’t count. A change becomes substantial when it alters the product’s intended function, expands the attack surface, or introduces new risk. Manufacturers should run this assessment before deciding how to structure their release strategy.

What “Separate Security Updates” Actually Means

The real goal behind Annex I Part II(2) is to stop a bad practice: forcing users to accept unrelated new features just to get a security fix. If a fix can technically be released on its own, bundling it with unrelated feature changes may conflict with this requirement. The better approach is a clear split — a security-only release for the current supported baseline, with new features handled in a separate maintenance release.

When Bundling Is Still Acceptable

The rule includes an important condition: “where technically feasible.” Some embedded products use monolithic firmware images where components are signed together, making a clean split impractical or even risky. In these cases, bundling may be justified — but manufacturers should document the technical reasoning clearly, covering architecture, dependencies, and compatibility risk.

A Practical Release Structure

Rather than maintaining endless historical branches, manufacturers can define a supported security baseline — the current version that receives ongoing security updates — while older versions are retired through free, low-friction upgrades. New features go into a separate release track, keeping the security update channel clean and predictable.

Key Takeaways

• Run a substantial modification assessment before deciding on branch strategy. Don’t assume every new feature release requires legacy version support — check whether it meets the CRA’s substantial modification criteria first.
• Confirm your upgrade path meets Article 13(10) conditions. Make sure the free upgrade doesn’t require customers to buy new hardware or pay for software changes, or the exemption won’t apply.
• Separate security and feature updates whenever technically possible. Build your release pipeline so a security-only patch doesn’t force customers into unrelated new functionality.
• Document technical infeasibility clearly if you must bundle updates. “Too costly to maintain multiple branches” is not a valid justification on its own — base your case on firmware architecture and dependency risk.
• Define a supported security baseline now. Set up a clear current-version policy so your team isn’t stuck debating branch strategy every time a new CVE appears.

Source of Article

CRA Q&A Case Study: Security Update — Does This Mean Every Legacy Firmware Requires a Security Branch? Based on Regulation (EU) 2024/2847 (Cyber Resilience Act), Article 13(8)–(11), Annex I Part II Point (2), Recitals 39, 40, and 57, and the European Commission Guidance on the application of the Cyber Resilience Act (July 2026).