EU Cyber Resilience Act FAQ Update Availability and Archives
Understand how long issued CRA security updates must remain available, how support-period information must be given to users, and when public software archives are optional.
For release, product, engineering, and compliance teams maintaining update channels, historical-version access, and vulnerability-remediation evidence under the CRA.
The Cyber Resilience Act separates three related duties: manufacturers must handle vulnerabilities during the support period, keep each security update issued during that period available after release, and may choose to maintain public archives for historical software versions. This FAQ explains those boundaries without inventing extra archive-retention periods.
Search this module
Find a question or answer quickly
25 of 25 questions
Question 1
Must each CRA security update remain available after it is issued?
Yes.
The CRA requires each security update that was made available during the support period to remain available after issuance for at least 10 years or for the remainder of the support period, whichever is longer.
Is CRA update availability the same thing as the support period?
No.
The support period is the period during which the manufacturer must handle vulnerabilities effectively. Update availability is a separate rule that keeps already-issued security updates accessible for a minimum period after issuance.
Can CRA update availability last longer than the support period itself?
Yes.
A product might have a shorter support period, but a security update issued during that period may still need to remain available for at least 10 years after issuance if that is longer.
Does keeping old updates available mean the manufacturer must keep issuing new security updates after the support period ends?
Not necessarily.
The obligation to handle vulnerabilities runs through the support period. Article 13(9) separately preserves access to security updates that were already issued during that period.
The CRA allows archives that enhance user access to historical versions. The Commission FAQ explains this as historical versions of products with digital elements that are no longer made available on the market.
Must the manufacturer disclose the end date of the support period at the time of purchase?
Yes.
The end date of the support period, at least month and year, must be clearly and understandably specified at the time of purchase in an easily accessible manner.
Must CRA user instructions and support information remain available after placement on the market?
Yes.
The CRA requires the information and instructions to the user to remain at users' and authorities' disposal for at least 10 years after placing on the market or for the support period, whichever is longer. If they are provided online, they must stay accessible and available online for the same period.
Must CRA technical documentation and declaration of conformity also be retained after placement on the market?
Yes.
The technical documentation and EU declaration of conformity must be kept at the disposal of market surveillance authorities for at least 10 years after placing on the market or for the support period, whichever is longer.
Once a CRA security update has been made available, must the manufacturer disclose information about the fixed vulnerability?
Yes.
Annex I Part II point (4) requires the manufacturer, once a security update has been made available, to share and publicly disclose information about fixed vulnerabilities, including the affected product, impacts, severity, and information helping users remediate the issue. In duly justified cases, publication may be delayed until users have had the possibility to apply the patch.
If the manufacturer relies on CRA Article 13(10), what should users of earlier versions be able to do?
They must be able to access the latest placed version free of charge and without additional hardware or software-environment adjustment costs.
Article 13(10) is narrow: it applies where the manufacturer has placed subsequent substantially modified versions of a software product on the market and wants to comply with the vulnerability-remediation requirement only for the latest placed version. If users of earlier versions cannot actually move to that latest version on those terms, Article 13(10) is not a supported basis for ending remediation of the earlier versions.
Does keeping an unsupported version in a public software archive mean it is still supported under the CRA?
No.
Article 13(11) treats public software archives as a way to enhance access to historical versions. It does not convert unsupported software back into supported software, and it requires users to be warned about the risks of using unsupported software.
Can a manufacturer rely on CRA Article 13(10) only if users of older versions can move to the latest version free of charge?
Yes.
Article 13(10) allows a manufacturer of a software product with subsequent substantially modified versions to comply with the remediation obligation only for the latest placed version, but only if users of the earlier versions can access that latest version free of charge.
That means the CRA does not let the manufacturer stop remediating older versions while putting the fix path behind a paid upgrade.
Can the manufacturer rely on CRA Article 13(10) if users need new hardware or fundamental environment changes to get the latest version?
No.
Recital 40 says the manufacturer may shift remediation to the latest placed software version only if users of the previous versions can access that latest version free of charge and do not incur additional costs to adjust the hardware and software environment in which they use the original version.
The recital gives the example of a desktop operating-system upgrade that does not require new hardware such as a faster CPU or more memory.
If the manufacturer relies on CRA Article 13(10) and stops remediating earlier versions, do the other vulnerability-handling duties disappear too?
No.
Recital 40 says Article 13(10) gives flexibility for security updates on the latest placed software version only when the free-access and no-additional-cost conditions are met. The manufacturer still has to comply, for the support period, with other vulnerability-handling requirements for all subsequent substantially modified versions placed on the market, including coordinated vulnerability disclosure and measures that facilitate sharing information about potential vulnerabilities.
Article 13(10), Annex I Part II point (2), recital 40
Question 20
Is the mandatory update-retention rule the same thing as keeping a public software archive?
No.
Article 13(9) creates a mandatory duty to keep each security update made available during the support period available after issuance. Article 13(11) is a separate, optional rule that allows manufacturers to maintain public software archives to enhance access to historical versions. The Commission FAQ describes those archives as a way to provide access to historical versions of products that are no longer made available on the market.
Does the Cyber Resilience Act require every historical software version to remain downloadable?
No.
The mandatory rule in Article 13(9) applies to each security update made available during the support period. By contrast, Article 13(11) says manufacturers may maintain public software archives for historical versions. So the CRA imposes a mandatory retention rule for issued security updates, but it does not impose a general duty to keep every historical software version downloadable as such.
If a manufacturer relies on CRA Article 13(10) and stops remediating older versions, do earlier security updates already issued for those versions still need to remain available?
Yes.
Article 13(10) gives flexibility only for the obligation in Annex I Part II point (2) to address and remediate vulnerabilities for earlier versions. Article 13(9) separately requires each security update that was made available during the support period to remain available after issuance. Nothing in Article 13(10) cancels that separate update-availability rule.
Article 13(9), Article 13(10), Annex I Part II point (2)
Question 23
Under the CRA, if a hardware product cannot run the latest software version, can the manufacturer stop offering any supported security-update path for that product?
No.
Recital 40 says that where a hardware product, such as a smartphone, is not compatible with the latest version of the operating system it was originally delivered with, the manufacturer should continue to provide security updates at least for the latest compatible version for the support period. So Article 13(10) does not let the manufacturer point users to an upgrade path that the hardware cannot actually use and then stop supporting the compatible branch.
What evidence helps show CRA update availability and vulnerability remediation were handled?
Keep evidence that proves the specific CRA duties on this page, without inventing a separate archive-retention period.
Useful records include the declared support-period end date shown at purchase, release notes and advisory messages for each security update, the update-channel or download record showing the issued update remains available, the fixed-vulnerability disclosure content required by Annex I Part II point (4), and the Article 13(10) analysis showing whether earlier-version users had free access to the latest placed version without additional hardware or software-environment costs.
Article 13(9), Article 13(10), Article 13(19), Annex I Part II point (4), Annex I Part II point (8)
Question 25
Must retained CRA security updates be published in a public archive open to anyone?
Not necessarily.
Inference from Articles 13(9) and 13(11): the mandatory rule is to keep security updates available to users, while public software archives are only an optional way to enhance access to historical versions. The CRA therefore does not state that every retained security update must be published in a public archive open to anyone, even though a manufacturer may choose to make updates available that way.