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.
Structured answer sets in this page tree.
Cited legal and guidance references.
The EU Cyber Resilience Act separates three related duties: manufacturers must handle vulnerabilities during the , keep each issued during that period available to users after release, and may choose to maintain for . The mandatory update-retention rule does not require a public archive and does not extend the duty to issue new updates beyond the support period. The Regulation is binding; the Commission CRA FAQ cited below provides non-binding interpretation.
Yes.
The CRA requires each that was made available during the to remain available after issuance for at least 10 years or for the remainder of the support period, whichever is longer.
Article 13(9)
No.
The 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.
Article 3(20), Article 13(8), Article 13(9)
Yes.
Article 13(9) applies to each that has been made available to users during the .
Article 13(9)
No.
Article 13(9) is framed at the level of each made available during the , not only the latest one.
Article 13(9)
Yes.
A product might have a shorter , but a issued during that period may still need to remain available for at least 10 years after issuance if that is longer.
Article 13(8), Article 13(9)
Not necessarily.
The obligation to handle vulnerabilities runs through the . Article 13(9) separately preserves access to security updates that were already issued during that period.
Article 13(8), Article 13(9)
No.
The CRA says manufacturers may maintain . That means archives are allowed, not required.
Article 13(11)
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.
Article 13(11)
section 1.7
Users must be clearly informed, in an easily accessible manner, about the risks associated with using unsupported software.
Article 13(11)
section 1.7
Yes.
The end date of the , at least month and year, must be clearly and understandably specified at the time of purchase in an easily accessible manner.
Article 13(19)
Yes, where technically feasible in light of the nature of the product.
The CRA requires a notification informing users that the product has reached the end of its where that is technically feasible.
Article 13(19), recital 56
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 , whichever is longer. If they are provided online, they must stay accessible and available online for the same period.
Article 13(18)
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 , whichever is longer.
Article 13(13)
Yes.
Annex I Part II point (4) requires the manufacturer, once a 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.
Annex I Part II point (4)
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.
Article 13(10), recital 40
No.
Article 13(11) treats 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.
Article 13(11)
section 1.7
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.
Article 13(10), recital 40
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.
Article 13(10), recital 40
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 , with other vulnerability-handling requirements for all subsequent substantially modified versions placed on the market, including coordinated vulnerability disclosure and measures that support sharing information about potential vulnerabilities.
Article 13(10), Annex I Part II point (2), recital 40
No.
Article 13(9) creates a mandatory duty to keep each made available during the available after issuance. Article 13(11) is a separate, optional rule that allows manufacturers to maintain 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.
Article 13(9), Article 13(11)
section 1.7
No.
The mandatory rule in Article 13(9) applies to each made available during the . By contrast, Article 13(11) says manufacturers may maintain 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.
Article 13(9), Article 13(11)
section 1.7
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 that was made available during the 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)
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 . 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.
recital 40
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 , 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)
Not necessarily.
Inference from Articles 13(9) and 13(11): the mandatory rule is to keep security updates available to users, while are only an optional way to enhance access to historical versions. The CRA therefore does not state that every retained must be published in a public archive open to anyone, even though a manufacturer may choose to make updates available that way.
Article 13(9), Article 13(11)
section 1.7
No. Article 13(9) requires security updates issued during the to remain available to users for the required period, but it does not prescribe a public repository, anonymous download, account model, file format, or archive interface.
The manufacturer should choose an access method that lets the relevant users obtain the retained update and verify that it is the correct, authentic update for the affected product and version. A public archive under Article 13(11) is optional and serves a different purpose: improving access to , including unsupported versions that must carry a clear risk warning.
Article 13(9) requires issued security updates to remain available to users; Article 13(11) separately permits optional public software archives and requires warnings for unsupported software.
Section 1.7 explains the optional public-archive provision and the required warning for unsupported software.
Turn support-period dates, update-channel records, advisory messages, and archive notices into a traceable CRA evidence set.
Convert CRA update-availability requirements into cited release, archive, and support-period evidence tasks.
Review update access, historical-version notices, and vulnerability-remediation records with Sorena.
"Manufacturers are allowed to maintain public software archives for historical versions"