Operational guidance, not legal advice. This page distills named public sources (regulator guidance and industry practice). It is not a legal determination, not a notification decision, and not a substitute for your counsel, insurer, or a retained DFIR firm. Verify applicability and current deadlines for your facts and jurisdiction.
What does the CRA require for security updates and the support period?
Last verifiedThe EU Cyber Resilience Act (Regulation (EU) 2024/2847) requires manufacturers, where it applies, to remediate vulnerabilities without delay, including by security updates, during a support period of at least five years unless expected use is shorter. This page is not legal advice and does not start a clock.
CRA security-update guide, last verified 9 September 2026 against Regulation (EU) 2024/2847 Articles 13 and 71, Annex I Parts I and II, Annex II, and Recitals 56–57, 59–60 and 64, the European Commission's CRA pages (last updated 7 September 2026), CRA implementation FAQs (last updated 4 September 2026), and 27 July 2026 guidance (C(2026) 5252) — those Commission materials are guidance, not the regulation — and ENISA product-security materials (agency guidance, not the regulation). It is not legal advice, not a filing, not a determination that the CRA applies, not YOUR support period, not a security update this product ships, and not a substitute for counsel.
This is security-update duty, not YOUR support period
Audience: a product owner, eng leader, or compliance owner at an organisation that might manufacture products with digital elements under Regulation (EU) 2024/2847. This page is not legal advice. It does not start a clock. Reading it does not start a clock. Mapping a row is not a determination that the CRA applies, that you are a manufacturer, that a product with digital elements has been made available on the Union market, that YOUR support period is five years, or that a security update is due.
The CRA is Regulation (EU) 2024/2847 of 23 October 2024, OJ L 2024/2847, 20.11.2024. ELI: http://data.europa.eu/eli/reg/2024/2847/2024-11-20. Security-update and support-period duties sit in Article 13 and Annex I. They apply from 11 December 2027 (Article 71(2)), except that Article 14 reporting already applies from 11 September 2026. This page does not start that clock. Last verified 9 September 2026. Not legal advice.
- Statute versus guidance: Articles 13(8), 13(9), 13(10) and 13(19), Annex I Part I point (2)(c), and Annex I Part II points (2), (4), (7) and (8) are legal requirements only if they apply. Recitals 56–57, 59–60 and 64 aid interpretation; they are not operative articles. Commission CRA pages, CRA implementation FAQs (last updated 4 September 2026), and the 27 July 2026 Commission guidance (C(2026) 5252) are Commission materials — guidance, not the regulation. ENISA product-security materials are agency guidance, not the regulation. This page quotes which kind of text it is relying on.
- The CRA overview on this site is the pillar page. The who-is-covered guide on this site is the economic-operator roles page. The SaaS-scope guide on this site is the remote-processing versus service page. The CRA-cluster Article 14 overview on this site is how Article 14 sits in the cluster. The statute-clock Article 14 guide on this site is the ladder under breach reporting. The where-to-submit guide on this site is the Article 14 channel page. The CSIRT guide on this site is the coordinator-interaction page.
- The vulnerability-disclosure guide on this site is the coordinated-disclosure policy page. The evidence-retention guide on this site is the technical-documentation retention page. The readiness-checklist guide on this site is the end-to-end CRA readiness page. A dedicated vulnerability-management and final-report guide is not on this site yet. Naming them is not a link.
- This product does not ship security updates, does not set YOUR support period, does not file with a CSIRT or ENISA, and does not start a clock. A named human still ships the update.
What Annex I requires of security updates — not a determination
Annex I splits product properties (Part I) from vulnerability handling (Part II). Security updates sit in both. The table is an aid. It is not a determination that YOU owe an update, that a charge exception is met, or that automatic installation applies. Last verified 9 September 2026. Not legal advice.
| Duty | What the cited text says | Kind of text | Last verified |
|---|---|---|---|
| Address vulnerabilities through updates — Annex I Part I point (2)(c) | On the basis of the Article 13(2) cybersecurity risk assessment and where applicable, products with digital elements shall ensure that vulnerabilities can be addressed through security updates, including, where applicable, through automatic security updates that are installed within an appropriate timeframe enabled as a default setting, with a clear and easy-to-use opt-out mechanism, through the notification of available updates to users, and the option to temporarily postpone them. | Legal requirement — Annex I Part I point (2)(c). Only if it applies. Recital 56 (a recital, not an operative article) discusses when automatic updates would not reasonably be expected. | 9 September 2026 |
| Remediate without delay, separately from feature updates — Annex I Part II point (2) | Manufacturers shall, in relation to the risks posed to products with digital elements, address and remediate vulnerabilities without delay, including by providing security updates; where technically feasible, new security updates shall be provided separately from functionality updates. | Legal requirement — Annex I Part II point (2). Recital 57 is a recital: users should not be required to install new functionality updates for the sole purpose of receiving the latest security updates. A recital is not an operative article. | 9 September 2026 |
| Disclose after an update is available — Annex I Part II point (4) | Once a security update has been made available, share and publicly disclose information about fixed vulnerabilities, including a description, information allowing users to identify the affected product, impacts, severity, and clear and accessible information helping users to remediate; in duly justified cases, where manufacturers consider the security risks of publication to outweigh the security benefits, they may delay making public information until after users have been given the possibility to apply the relevant patch. | Legal requirement — Annex I Part II point (4). This page does not find that YOUR disclosure is due or that a delay ground is met. | 9 September 2026 |
| Distribute securely, automatically where applicable — Annex I Part II point (7) | Provide for mechanisms to securely distribute updates for products with digital elements to ensure that vulnerabilities are fixed or mitigated in a timely manner and, where applicable for security updates, in an automatic manner. | Legal requirement — Annex I Part II point (7). Integrity of distribution is this point. This page does not certify YOUR channel. | 9 September 2026 |
| Disseminate without delay and without charge, with advisory messages — Annex I Part II point (8) | Where security updates are available to address identified security issues, they are disseminated without delay and, unless otherwise agreed between a manufacturer and a business user in relation to a tailor-made product with digital elements, without charge, accompanied by advisory messages providing users with the relevant information, including on potential action to be taken. | Legal requirement — Annex I Part II point (8). Recital 64 is a recital on the same charge rule. The tailor-made exception is in the annex, not a maintenance-contract carve-out this page invents. | 9 September 2026 |
Support period — Article 13(8), not a number this page invents
Article 13(8) is the legal requirement for how long vulnerability handling, including security updates, runs. This page does not invent a number, does not set YOUR support period, and does not treat five years as typical. Last verified 9 September 2026. Not legal advice.
Article 13(8), first subparagraph: manufacturers shall ensure, when placing a product with digital elements on the market, and for the support period, that vulnerabilities of that product, including its components, are handled effectively and in accordance with Annex I Part II.
Article 13(8), second subparagraph: manufacturers 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, as well as relevant Union law determining the lifetime of products with digital elements. Manufacturers may also take into account support periods of similar products, availability of the operating environment, support periods of integrated components that provide core functions, and relevant ADCO and Commission guidance. The matters to be taken into account shall be considered in a manner that ensures proportionality.
Article 13(8), third subparagraph: without prejudice to the second subparagraph, 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. That is the regulation. It is not a number this page invents.
| Clock | What the cited text says | Kind of text | Last verified |
|---|---|---|---|
| How long new security updates have to be produced — Article 13(8) | At least five years, unless the product is expected to be in use for less than five years, in which case the support period shall correspond to the expected use time. The period shall reflect expected use, taking into account reasonable user expectations, the nature of the product including intended purpose, and relevant Union law determining lifetime. | Legal requirement — Article 13(8). Recital 60 is a recital (industrial control systems, operating systems, and similar often used longer than five years). A recital is not an operative article. | 9 September 2026 |
| How long an issued update remains retrievable — Article 13(9) | Each security update, as referred to in Annex I Part II point (8), which has been made available to users during the support period, remains available after it has been issued for a minimum of 10 years or for the remainder of the support period, whichever is longer. | Legal requirement — Article 13(9). This is not the support period. Clearing a download directory when support ends is a different question from whether new updates still have to be produced. | 9 September 2026 |
| Latest software version only — Article 13(10) | Where a manufacturer has placed subsequent substantially modified versions of a software product on the market, that manufacturer may ensure compliance with Annex I Part II point (2) only for the version last placed on the market, provided that the users of the versions previously placed on the market have access to the version last placed on the market without charge and do not incur additional costs to adjust the hardware and software environment in which they use the original version. | Legal requirement — Article 13(10). Recital 40 is a recital (desktop OS upgrade that does not require new hardware; smartphone remaining on the latest compatible OS). A recital is not an operative article. | 9 September 2026 |
| Tell users the end date — Article 13(19) and Annex II point (7) | Article 13(19): the end date of the support period, including at least the month and the year, is clearly and understandably specified at the time of purchase in an easily accessible manner and, where applicable, on the product, its packaging, or by digital means. Where technically feasible, display a notification that the product has reached the end of its support period. Annex II point (7): the type of technical security support offered and the end-date of the support period during which users can expect vulnerabilities to be handled and to receive security updates. | Legal requirement — Article 13(19) and Annex II point (7). This page does not print YOUR end date. | 9 September 2026 |
Statute versus Commission guidance on the support period
Article 13(8) is the legal requirement. Commission materials interpret it. This page quotes both and labels which. It does not treat guidance as rewriting the article. Last verified 9 September 2026. Not legal advice.
| Claim | Source as labelled | Kind of text | What this page does not do |
|---|---|---|---|
| Support period at least five years, or expected use time if shorter | Article 13(8), third subparagraph. | Legal requirement — only if the CRA applies. | Does not set YOUR support period at five years. Does not invent a typical figure. |
| Five years is a minimum safeguard; the period should proportionately reflect realistic expected use time | Commission guidance of 27 July 2026 (C(2026) 5252) on how support periods should be understood and applied. The Commission page itself calls that guidance non-binding. | Guidance, not the regulation. Commission materials. | Does not treat C(2026) 5252 as amending Article 13(8). Does not convert 'minimum safeguard' into a ceiling. |
| Each software version placed on the market should have a declared support period, also at least five years unless that version's expected use time is demonstrably shorter | Commission guidance of 27 July 2026 (C(2026) 5252) on iterative software. | Guidance, not the regulation. | Does not declare YOUR version's support period. Does not treat a version tag as a placing-on-the-market date. |
| 'Additional costs' under Article 13(10) go beyond what can normally be expected in software updates, such as mandatory new hardware, infrastructure replacement, or fundamental changes to the operating environment | Commission guidance of 27 July 2026 (C(2026) 5252) interpreting Article 13(10). | Guidance, not the regulation. Article 13(10) is the legal requirement. | Does not find that YOUR upgrade path meets Article 13(10). Does not run the additional-cost test. |
| A substantial modification should trigger a reassessment of the support period against Article 13(8); it does not automatically reset or extend it | Commission guidance of 27 July 2026 (C(2026) 5252). | Guidance, not the regulation. | Does not find that YOUR change is a substantial modification. Does not reset YOUR clock. |
| Manufacturers are not required to provide a patch for every vulnerability discovered during the support period; remedies follow the manufacturer's risk assessment and may include workarounds, configuration guidance, or documentation | Commission CRA implementation FAQs (last updated 4 September 2026), quoting Annex I Part II point (2). | FAQ is guidance, not the regulation. Annex I Part II point (2) is the legal requirement (address and remediate vulnerabilities without delay, in relation to the risks posed). | Does not decide that YOUR vulnerability needs a patch, a workaround, or no change. Does not run YOUR risk assessment. |
Separation, integrity, and notification — statutory minimum versus recital
Annex I Part II point (2) is the operative separation rule: where technically feasible, new security updates shall be provided separately from functionality updates. Recital 57 states the reason — users should not be required to install new functionality updates for the sole purpose of receiving the latest security updates. Recital 57 is a recital, not an operative article. 'Where technically feasible' is in the annex; this page does not decide when it bites.
Integrity and notification are Annex I Part II points (7) and (8) plus Annex I Part I point (2)(c): secure distribution; timely, and where applicable automatic, installation; dissemination without delay and without charge (tailor-made exception as the annex states it); advisory messages; notification of available updates; opt-out and postpone. Annex II point (8)(e) requires instructions on how to turn off a default that allows automatic installation of security updates. Last verified 9 September 2026. Not legal advice.
- Shipping a security fix only inside the next feature release is the fact pattern Recital 57 discusses. The operative rule is Annex I Part II point (2). This page does not find that YOUR release train fails it.
- A maintenance agreement that turns security updates into a paid deliverable is the fact pattern Recital 64 and Annex I Part II point (8) discuss. The annex states the tailor-made exception. This page does not rewrite YOUR contract.
- Article 13(9) retrievability (10 years or remainder of the support period, whichever is longer) is a different clock from Article 13(8) production of new updates. This page does not start either clock.
What to do now
As of last verification on 9 September 2026, Article 14 reporting applies from 11 September 2026. Essential-requirement and support-period application remains 11 December 2027 (Article 71(2)). The list below is operational preparation. It is not a determination that the CRA applies to YOU, that you are a manufacturer, that YOUR support period is five years, or that a reporting clock has started. Walk it with counsel.
- Ask counsel whether YOU are a manufacturer of a product with digital elements made available on the Union market. This page does not run that test. Marking CRA in an obligation map is not that determination.
- If counsel says Article 13 and Annex I may apply, determine a support period under Article 13(8) and record the information taken into account in technical documentation (Annex VII). This page does not set that period. The 27 July 2026 Commission guidance is guidance, not the regulation.
- If counsel says Annex I Part II point (2) may apply, plan a path that remediates without delay and, where technically feasible, separates security updates from functionality updates. This page does not ship that update.
- If counsel says Article 14 may apply, open the statute-clock Article 14 guide on this site for the 24-hour / 72-hour / 14-day ladder. A security update being available is a mark on that ladder's vulnerability-final-report track. This page does not start that clock.
- The vulnerability-disclosure guide on this site is the coordinated-disclosure policy page. The evidence-retention guide on this site is the technical-documentation retention page. The readiness-checklist guide on this site is the end-to-end CRA readiness page. A dedicated vulnerability-management and final-report guide is not on this site yet. Naming them is not a link.
Checklist
This is a question list, not a filing, and not YOUR support-period determination. Walk it with counsel. The CRA overview on this site is the pillar page. The live Article 14 reporting guide on this site is the ladder.
- Does the CRA apply? Product with digital elements made available on the Union market — Articles 2 and 3. This page does not run that test.
- Support period under Article 13(8): at least five years, or expected use time if shorter, reflecting expected use. This page does not invent that number and does not set YOUR period.
- Article 13(9) retrievability of each issued update: 10 years or remainder of the support period, whichever is longer. Distinct from Article 13(8).
- Article 13(10) latest-version limit: only if users of earlier versions can move to the last-placed version without charge and without additional costs. This page does not run that test.
- Annex I Part II point (2): remediate without delay, including by security updates; separate from functionality updates where technically feasible.
- Annex I Part II points (7) and (8): secure distribution; disseminate without delay and without charge (tailor-made exception as stated); advisory messages.
- Annex I Part I point (2)(c) and Annex II: notification, opt-out, postpone, and the end date of the support period at purchase.
- Article 14 from 11 September 2026 if the CRA applies. This page does not start that clock.
- Document the assessment, including a not-in-scope decision. This page does not keep YOUR file.
Where this shows up in ShipReady Metrics
The signed-in app does not decide that the CRA applies, does not decide that you are a manufacturer, does not set YOUR support period, does not ship a security update to YOUR users, does not start an Article 14 clock, and does not file with a CSIRT or ENISA. None of the surfaces below is 'CRA applies', 'this support period is yours', 'this update has been disseminated', or CE marking.
If you already have a session: signed-in app → Security → Findings tracks remediation of security findings the organisation has ingested, including KEV, EPSS, and CVSS signals. That tracker is vulnerability-management remediation tracking. It is not a security-update delivery mechanism, not evidence that an update was disseminated without charge, not a support-period clock, and not CE marking. A named human still ships the update.
The same signed-in app → Compliance → CRA reporting tracks the Article 14 24-hour and 72-hour stages from recorded awareness, and the 14-day final-report mark from recorded measure availability, for findings the organisation has classified as CRA-in-scope. That tracker does not start an Article 14 clock, does not decide that a security update is available, and does not file. A named human still submits.
The obligation map lists frameworks the organisation has marked in-scope, including CRA if that mark is set. That mark is not a determination that the CRA applies, not a determination that you are a manufacturer, and not a finding that YOU owe security updates. The bundled framework key cra is customer-visible. Its version label is Regulation (EU) 2024/2847 (starter subset). The control-set is a starter subset, illustrative readiness mapping, to be tailored by a compliance owner; not legal advice; not full conformity-assessment detail. Readiness is not compliance, not CE marking, and not a market-surveillance determination.
This page does not document a public demo URL. There is no public CRA demo path. This product does not ship security updates.
Primary sources (last verified 9 September 2026)
Every regulatory or guidance claim on this page is taken from one of these. If a later revision of a source changes the rule, the date above is how you can see we have not re-checked yet.
Regulation (EU) 2024/2847 of 23 October 2024 (Cyber Resilience Act), Articles 13(8), 13(9), 13(10) and 13(19), Annex I Parts I and II, and Annex II, is a legal requirement only if it applies. Recitals 56–57, 59–60 and 64 are recitals, not operative articles. Article 14 applies from 11 September 2026; the rest, including these essential-requirement and support-period duties, from 11 December 2027 (Article 71(2)). The European Commission's CRA policy page (updated 7 September 2026), CRA implementation FAQs (last updated 4 September 2026), and 27 July 2026 guidance (C(2026) 5252) are Commission materials, not the regulation. ENISA product-security materials are agency guidance, not the regulation. These are not a complete world list. Not legal advice.
The CRA overview on this site is the pillar page. The statute-clock Article 14 guide on this site is the live ladder under breach reporting. The CRA-cluster Article 14 overview on this site is how Article 14 sits in the cluster. The who-is-covered guide on this site is the economic-operator roles page. The SaaS-scope guide on this site is the remote-processing versus service page. The where-to-submit guide on this site is the Article 14 channel page. The CSIRT guide on this site is the coordinator-interaction page. The vulnerability-disclosure guide on this site is the coordinated-disclosure policy page. The evidence-retention guide on this site is the technical-documentation retention page. The readiness-checklist guide on this site is the end-to-end CRA readiness page. A dedicated vulnerability-management and final-report guide is not on this site yet. Naming them is not a link.