EU Cyber Resilience Act FAQ Update Availability and Archives

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.

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.

Yes.

Article 13(9) applies to each security update that has been made available to users during the support period.

No.

Article 13(9) is framed at the level of each security update made available during the support period, not only the latest one.

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.

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.

No.

The CRA says manufacturers may maintain public software archives. That means archives are allowed, not required.

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.

Users must be clearly informed, in an easily accessible manner, about the risks associated with using unsupported software.

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.

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 support period where that is technically feasible.

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.

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.

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.

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.

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.

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.

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.

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 support sharing information about potential vulnerabilities.

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.

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.

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.

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.

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.

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.

No. Article 13(9) requires security updates issued during the support period 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 historical software versions, including unsupported versions that must carry a clear risk warning.