How long must you support an app under the CRA? The support period explained
Short answer: at least five years, unless you can show that the app is expected to be in use for less. You decide the period yourself, per version, write down how you decided, and tell users the end date.
- Article 13(8) sets a floor of five years. If an app is expected to be in use for less than five years, the support period corresponds to that expected use time.
- During the support period you must handle vulnerabilities effectively and make security updates available free of charge (Annex I, Part II points (2) and (8)).
- Three different clocks run: the support period, the 10 years a security update must stay available (Article 13(9)), and the 10 years the technical documentation must be kept (Article 13(13)). Two of them are “10 years or the support period, whichever is longer”.
- The information you used to set the period belongs in the technical documentation (Annex VII, point 4), and the end date belongs in the user information (Annex II, point 7).
What Article 13(8) says
Article 13(8) of the Cyber Resilience Act says that manufacturers must ensure, when placing a product on the market and for the support period, that vulnerabilities of the product, including its components, are handled effectively and in accordance with Part II of Annex I.
The same paragraph tells you how long that period is:
You “shall determine the support period so that it reflects the length of time during which the product is expected to be in use”, taking into account in particular reasonable user expectations, the nature of the product including its intended purpose, and relevant Union law determining the lifetime of products with digital elements.
“The support period shall be at least five years.”
“Where the product with digital elements is expected to be in use for less than five years, the support period shall correspond to the expected use time.”
The paragraph also lists things you may take into account: the support periods of similar products from other manufacturers, the availability of the operating environment, the support periods of integrated third-party components that provide core functions, and guidance from the administrative cooperation group (ADCO) and the Commission. All of this must be weighed “in a manner that ensures proportionality”.
The Commission may also adopt delegated acts that set a minimum support period for specific product categories where market surveillance data suggests inadequate periods. As far as we have been able to verify, none has been adopted for apps.
Our topic note for this guide mentioned Article 13(8) to (10). That range is right: paragraph (8) is the support period, paragraph (9) is how long security updates stay available, and paragraph (10) is about substantially modified versions of software. Retention of the technical documentation is a separate paragraph, Article 13(13).
Five years is a floor, not a default
Read together, the sentences above do not say “declare five years”. They say the period must reflect expected use, and that it is never below five years unless expected use itself is shorter.
A summary of the Commission guidance by Schutzwerk reports the same reading: five years is a floor, a shorter period is acceptable only if expected use is demonstrably shorter, and longer expected use calls for a longer period. We have only read the guidance through summaries, so check the original before relying on a paragraph number.
For an app team this means the question is “how long will people realistically keep using this app?”. A banking or health companion app that users keep for many years is a different case from an app built for a single event. Write the answer down with the reasons; you will need them for the technical documentation.
What you owe during the support period
| Duty | Where | In short |
|---|---|---|
| Handle vulnerabilities effectively | Article 13(8), Annex I Part II | Have policies and procedures, including a coordinated vulnerability disclosure policy, to process and remediate vulnerabilities reported from internal or external sources. |
| Fix without delay | Annex I Part II point (2) | Address and remediate vulnerabilities without delay, including by providing security updates. Where technically feasible, new security updates are provided separately from functionality updates. |
| Disseminate updates free of charge | Annex I Part II point (8) | Where security updates are available, disseminate them without delay and, unless otherwise agreed with a business user for a tailor-made product, free of charge, with advisory messages that tell users what to do. |
| Update mechanism | Annex I Part I point (2)(c) | Security updates, with automatic updates enabled by default where applicable, a clear opt-out, and notification of available updates to users. |
“Free of charge” is the point app businesses ask about most. It is about the security updates, not about the app: you can still sell the app or a subscription, but you cannot put the fix for a vulnerability behind a paid tier. See our guide on Annex I as concrete checks for an app for the update requirement in Part I.
Three clocks, not one
These periods are easy to mix up. They are separate rules in the regulation:
| What | How long | Where |
|---|---|---|
| Support period: you handle vulnerabilities and issue updates | At least five years, unless expected use is shorter | Article 13(8) |
| Each security update made available during the support period stays available | 10 years after it was issued, or the remainder of the support period, whichever is longer | Article 13(9) |
| Technical documentation and EU declaration of conformity kept for market surveillance authorities | 10 years after the product was placed on the market, or the support period, whichever is longer | Article 13(13) |
An illustration with our own numbers. Suppose version 3.0 of an app is first made available in March 2028 and you declare a support period that ends in March 2033. You issue a security update in January 2033. Under Article 13(9) that update must remain available until January 2043.
The technical documentation for 3.0 must be kept until at least March 2038 (10 years after placing on the market), or for the support period if that were longer. We count from the date the version is first made available; that is a working assumption, so confirm how you count with your own advisers. The free CRA support period calculator does this arithmetic per app version.
Per version: substantial modification and Article 13(10)
Apps ship constantly, so the practical question is whether every release has its own support period. The regulation answers this through substantial modification.
Article 13(10) says that where a manufacturer has placed subsequent substantially modified versions of a software product on the market, it may ensure compliance with Annex I Part II point (2) (remediating vulnerabilities) “only for the version that it has last placed on the market”, provided two conditions hold. Users of the earlier versions must have access to the latest version free of charge, and must not incur additional costs to adjust the hardware and software environment in which they use the original version.
The guidance summaries we read say the following. A substantially modified version needs its own declared support period. A change is substantial based on its effect, not on its version number: whether it affects conformity with the Annex I Part I requirements, changes the risk level or changes the intended purpose. An ordinary security update that reduces risk and leaves the intended purpose unchanged is generally not a substantial modification.
According to the Schutzwerk summary, new hardware, replacing infrastructure or a fundamental change to the operating environment count as “additional costs”, while ordinary testing and configuration effort does not. Treat these as secondary reports of the guidance and check them against the Commission document.
In practice, keep a register: for each app version, the date it was first made available, the declared end of support, and whether it is a substantially modified version of an earlier one. If you drop support for version 3 because users can move to version 5 at no cost, the register is the evidence. Who counts as the manufacturer when an agency maintains the app is covered in Agency or client: who is the manufacturer?.
Write it down, and tell users
Technical documentation. Article 13(8) requires you to include the information that was taken into account to determine the support period in the technical documentation set out in Annex VII. Annex VII point 4 lists “relevant information that was taken into account to determine the support period”. Keep the reasoning: expected use, user expectations, the support periods of third-party components that provide core functions, and similar products.
User information. Annex II point 7 requires the type of technical security support you offer and the end date of the support period during which users can expect vulnerabilities to be handled and to receive security updates. The Schutzwerk summary reports that the guidance wants the end date stated at purchase, at least by month and year, and users notified when it arrives where technically feasible.
Unsupported versions. Article 13(11) allows public software archives of historical versions. If you keep them, users must be clearly informed, in an easily accessible way, about the risks of using unsupported software.
Apps already on the market
The requirements apply from 11 December 2027. Under Article 69(2), products placed on the market before that date are covered only if they undergo a substantial modification from that date. The reporting duties of Article 14 are the exception: Article 69(3) applies them to all in-scope products, including those placed on the market earlier. See CRA vulnerability reporting for app teams.
A short procedure for an app team
- Estimate realistic expected use for the app, in years, and write down why.
- Check the support periods of your core third-party components, such as the framework, the backend platform and key SDKs. You cannot promise longer than you can maintain.
- Set the end date per version, never below five years unless expected use is shorter, and store it in the version register.
- Put the reasoning in the technical documentation (Annex VII point 4) and the end date in the user information (Annex II point 7).
- Plan the budget: security updates are free for users, and they have to be issued, tested and kept available for the whole period.
- Decide how users on old versions are moved to the latest one, and what you tell users who stay behind.
Some of this is our reading of the text. For borderline cases, such as whether a major redesign is a substantial modification, take advice.
Frequently asked questions
Is five years always enough?
No. It is the minimum. If the app is expected to be in use longer, the period should reflect that.
Can we declare less than five years?
Only if the app is expected to be in use for less than five years. Then the support period corresponds to the expected use time (Article 13(8)).
Do we have to support every old version?
Not necessarily. For substantially modified versions of software, Article 13(10) lets you remediate vulnerabilities only in the latest version, if users of earlier versions can get it free of charge and without extra costs to adjust their environment.
Can we charge for security updates?
No, not for ordinary products. Annex I Part II point (8) says security updates are disseminated free of charge, with an exception for tailor-made products agreed with a business user.
Try it on your own app: the free Shipmark scanner builds a CycloneDX SBOM from a lockfile in the browser and checks it against OSV.dev. Not sure the CRA applies? Use the six-question CRA check.
Sources
Regulation (EU) 2024/2847 (Cyber Resilience Act), EUR-Lex: the official text. The wording of Article 13(8) to (13) was read through the copies at StreamLex and Prighter, which matched each other. SpringLex: Annex I (Part II points (2) and (8)), Annex II (point 7), Annex VII (point 4) and Article 69. Schutzwerk: The new CRA guidance in practice, a summary of Commission guidance C(2026) 5252 (support period, substantial modification, end date at purchase). noze: Cyber Resilience Act, a practical guide after the Commission's clarifications, a second summary of the same guidance.
This guide summarises EU law for practical use. Statements about the Commission guidance come from secondary summaries, not from the guidance itself, and the worked example uses our own numbers. It is not legal advice.
Related: Support period calculator · Annex I checklist for apps · Agency or client · Does the CRA apply to apps?.
Originally published on shipmark.eu, where the guide is kept up to date. More guides for app teams: shipmark.eu/guides.
Comments
No comments yet. Start the discussion.