How is the support period determined?
Art. 13(8) determines the support period in two layers, and the order decides. The rule is in the second subparagraph: the manufacturer sets the period so that it reflects the length of time the product is expected to be in use, taking into account reasonable user expectations and the nature of the product. Only the third subparagraph names a figure, and it begins with “without prejudice to the second subparagraph”: at least five years; where the expected period of use is shorter, the period must correspond to it. The considerations underlying the period belong in the technical documentation under the fifth subparagraph; the end date must be indicated at the time of purchase (Art. 13(19)).
A product reasonably expected to be in use for ten years does not satisfy the provision merely by being supported for five. Conversely, whoever sets a generous period to look good in the market extends the time during which an omitted security update breaches a legal duty. The right number is the reasoned one. For a banking app the period of use of a version is short, that of the product long – switching off old versions does not replace the support decision, it is part of it.
How must security updates be provided?
Annex I Part II points 2 and 8 require addressing vulnerabilities without delay and distributing security updates without delay and free of charge – over the entire support period. Where technically feasible, security updates are to be provided separately from functionality updates; users must not have to buy security updates with new features or conditions. For legacy versions this means: whoever leaves an old app version in the field must either update it or communicate its end of support clearly.
When is an update a substantial modification?
Art. 3(30) defines a substantial modification as a change after placing on the market that affects compliance with the essential requirements or results in a modification of the intended purpose. The Commission guidance specifies: a modification is substantial if it affects compliance with the cybersecurity requirements, changes the risk level or changes the purpose. Examples: adding remote connectivity opens new attack vectors and is substantial; changing an encryption protocol can be. A security fix meeting none of the three conditions is not substantial. Every substantially modified version needs a newly declared conformity and a newly determined support period.
| Release situation | To clarify | Typical consequence |
|---|---|---|
| Targeted security fix | Do purpose, functions and risk level remain unchanged? | normally no substantial modification; test evidence in the product file |
| New business function (e.g. push approval, new interface) | Do data flows, attack surface or purpose change? | update the risk assessment; with new risk or new purpose: substantial modification, renewed conformity assessment |
| Replacement of a core component (authentication, crypto library) | Does the replacement touch Annex I Part I requirements? | often substantial; renew evidence per affected requirement |
| Supplier discontinues a component | Who detects end of support, who assesses, who replaces? | replacement or mitigation within the institution's own support period; check the supplier contract |
Are legacy products exempt from the CRA?
From the substantive requirements, yes, until their first substantial modification. Art. 69(2) exempts products placed on the market before 11 December 2027 from the substantive requirements – but only as long as they are not substantially modified from that date. The first substantial modification after the cut-off brings the legacy product fully into the CRA. The reporting obligations under Art. 14 have applied to legacy products since 11 September 2026 anyway (paragraph 3). Therefore document the product version considered and every change, rather than referring to the date of the original project start.
Does the support period become a liability boundary from 9 December 2026?
The Product Liability Directive (EU) 2024/2853 itself establishes no update duty – recital 51 says so expressly. But it attaches two legal consequences to the absence of security updates: software is a product (Art. 4(1)), and a product can be defective because it does not meet safety-relevant cybersecurity requirements (Art. 7(2)(f)). The defence that the defect arose only after placing on the market is barred where it results from missing updates within the manufacturer's control (Art. 11(2)(c)) – and control exists already where the manufacturer is able to provide updates (Art. 4(5)(b)). The update duty comes from the CRA; the strict liability comes from the directive.
The directive applies to products placed on the market after 9 December 2026 – one year before full application of the CRA. For older products the 1985 directive continues to apply; they are covered by the CRA as installed base (reporting duty) but not by the new liability. The liability requires a national transposition act: in Austria not even a draft existed at the time of our check on 8 October 2026. Details on the page CRA in Austria.
What do substantial modifications look like in practice?
Two cases: a banking app with new push approval and an insurance app whose upload component the supplier discontinues.
The app receives push approval for transfers and replaces the authentication module in the process. New data flows, new attack surface, core component replaced: substantial modification. Result: updated risk assessment, evidence per affected Annex I requirement, newly declared support period – and from December 2027 a renewed conformity assessment for the new version.
The claims-app partner discontinues the upload component; the replacement changes the workflow. Result: the replacement must happen within the app's committed support period; the new workflow must be checked for a change of purpose or risk; the supplier contract needs advance-notice periods for discontinuations in future.
Frequently asked questions
Is five years always the right support period?
No. Five years is the floor. The period must reflect the expected period of use and must be justified in the technical documentation; with a shorter period of use it may be shorter.
Is every security fix a substantial modification?
No. A modification is substantial only if it affects compliance with the essential requirements, changes the risk level or changes the purpose. Pure security fixes normally do not.
May security updates be bundled with new features?
Security updates are to be provided separately from functionality updates where technically feasible, and free of charge (Annex I Part II points 2 and 8).
Does the new product liability also apply to the app that is in the store today?
No, for products placed on the market before 9 December 2026 the previous law continues to apply. A substantially modified new version after that date is, however, a newly placed product.
Ing. Mag. Patrick Eiler
Patrick Eiler advises banks and insurers in Vienna on regulatory reporting, data architecture and AI compliance. More than twenty years in banking, insurance and financial services; speaker at the Hypo-Verband (expert session of 23 September 2026).