Governance DocsGovernance Docs
Browse Toolkits

CART

No products in the cart.

ISO Compliance Insights & Best Practices

CRA support period: five-year minimum, security updates and end-of-support date under Article 13 of the Cyber Resilience Act

CRA Support Period: The Essential 2026 Guide to Five Years, Updates and End-of-Support Dates

The CRA support period is the length of time during which a manufacturer must handle vulnerabilities in a product with digital elements and provide security updates under the EU Cyber Resilience Act. Article 13 of Regulation (EU) 2024/2847 says it must reflect how long the product is expected to be in use and, in most cases, must not be shorter than five years. Setting it too short creates compliance risk, and setting it too long creates a cost you must be able to carry, so it is one of the more consequential decisions a manufacturer takes.

This guide explains what the regulation says about the CRA support period, how to work out the right length for a product, what you must do about security update availability and end-of-support communication, and how to document the decision. It reflects the regulation text and the Commission’s guidance published in July 2026, and it is not legal advice.

Free gap assessment

Where do you stand on the Article 21 measures?

Score scope, all ten measures, the management-body duties and the reporting clocks, free.

Run the free NIS2 gap assessment →  or  View premium report sample

What the CRA says about the support period

Under Article 13, manufacturers must determine the support period so that it reflects the time the product is expected to be in use. The minimum is five years, unless the product is expected to be in use for less than five years, in which case the support period corresponds to that shorter expected use time. During the support period the manufacturer must handle vulnerabilities effectively and in line with the essential requirements. You can read the regulation on EUR-Lex.

ElementRequirement
Support period lengthReflects expected use time, minimum five years unless the product is expected to be used for less
Security update availabilityEach update stays available for at least 10 years after issue, or for the rest of the support period if that is longer
CommunicationEnd date of support stated clearly, with month and year, at the point of purchase
DocumentationReasoning for the chosen period recorded in the technical documentation

The Commission published non-binding guidance on the CRA on 27 July 2026. Its treatment of support periods makes the same point: five years is a floor and not a default. For longer-lived products, the period should extend in line with reasonable user expectations and the nature of the product. Market surveillance authorities are likely to look at the guidance, so follow it and record where you depart from it.

How to set the CRA support period for a product

The regulation lists factors to consider when deciding how long a product is expected to be in use. In summary, they include:

  • User expectations and the nature of the product. A thermostat installed in a wall has a different life from a phone accessory.
  • Applicable EU law on product lifetimes. Rules in other laws may point to a longer expected life.
  • Support periods of comparable products. If competitors support similar products for eight years, five may look short.
  • The operating environment. A device embedded in industrial plant is not replaced every few years.
  • Support of integrated components. If a third-party library or chipset loses support in four years, plan for what that means to you.
  • Guidance from the administrative cooperation group and the Commission. Both may issue recommendations, and the Commission may set minimum periods for product categories by delegated act.

A useful method is to write a short support period decision record per product: the expected use time, the evidence, the factors considered, the chosen period and the person who approved it. That single page becomes part of your technical documentation, which we cover in our guides to CRA conformity assessment and CRA product classification.

A worked CRA support period example

The following is a hypothetical illustration. A manufacturer sells a connected smart lock with a hardware life of about eight years, a wireless module supplied by a third party that the supplier supports for six years, and a mobile app. It considers the factors above: customers expect a lock to last as long as a door fitting, competitors publish support of seven to eight years, and the module supplier’s six-year commitment is the weak link. The team sets the support period at eight years, negotiates an extension of the module supplier’s commitment, and records both the decision and the risk if the supplier declines. It tells customers the end-of-support month and year on the box and in the app. Had the product been a promotional gadget expected to last two years, the record would explain why a shorter period matches the expected use time.

Security update availability across the CRA support period

The regulation also deals with how long updates remain available. Each security update issued during the support period must stay available for at least 10 years after it is issued or for the remainder of the support period, whichever is longer. Updates must be provided free of charge. In practice, plan your update hosting and signing infrastructure for the long term, since an update server that disappears after five years undercuts the promise. Keep old releases and their signing keys secure, and document how a user can obtain a required update after the product stops receiving new ones.

For software released in versions, the Commission’s guidance says a manufacturer may stop remediation for earlier versions once users can upgrade at no additional cost, and it describes that as avoiding mandatory purchases of new hardware, infrastructure replacement or fundamental changes to the operating environment. Check the guidance text for the details before you retire a version.

Communicating the end of the CRA support period

Users must be told when support ends. The regulation expects the end date, including month and year, to be made clear at purchase through accessible channels, and, where technically feasible, users should be notified when a product reaches the end of its support period. Put the date in the product information, on packaging or product pages, and in the user documentation. Build a notification step into your product so that a device or application can tell users when support is ending, and decide in advance what you will advise them to do.

Vulnerability handling throughout the period

The support period is when your vulnerability handling process has to work. That means having a process for receiving reports, assessing them, developing and releasing fixes and communicating with users. Our guides to coordinated vulnerability disclosure and SBOM requirements cover two building blocks, and the timing rules for notifying authorities are in our note on the CRA reporting deadline. Track your open vulnerabilities and time to fix, and use a maintained inventory of components so you can see quickly which products are affected when a library is compromised.

Common mistakes with the CRA support period

  • Defaulting to five years. The minimum is a floor. Products that last longer need a longer period.
  • No evidence for the decision. Without a record of the factors, you cannot show why the period is reasonable.
  • Ignoring supplier lifecycles. Your promise cannot outlast the components you depend on unless you have a plan.
  • No end-of-support message. A date buried in a manual does not meet the intention of clear communication at purchase.
  • Underfunding. A long support period needs engineers, test devices and infrastructure. Cost it before you promise it.

Budgeting and ownership

A support period is a commitment to spend money and engineering time in future years, so treat it as part of the product business case. Estimate the annual cost of maintaining a release line: developer time, test equipment, build and signing infrastructure, and staff to triage reports. Assign a named owner for each product’s support commitment, usually the product manager working with security. Review the decision record whenever the product, its components or its market changes, and at least once a year for products with long lives.

Documenting the support period

You will need a support policy, a decision record for each product, a vulnerability handling procedure, user information text and a process for end-of-support notices. The EU CRA Toolkit supplies templates for the technical documentation and processes that support this, which you can adapt to your products. For the wider picture, see our overview of the EU Cyber Resilience Act.

CRA support period FAQ

What is the minimum CRA support period?

Five years, unless the product is expected to be used for less than five years, in which case the support period matches the expected use time.

Can we choose a shorter period for a low-cost product?

Only if the expected use time is genuinely shorter. Price alone is not a reason, and you need evidence for the expected life.

How long must security updates stay available?

Each update stays available for at least 10 years after it is issued or for the remainder of the support period, whichever is longer, and it must be free of charge.

Do we have to publish the end-of-support date?

Yes. The regulation expects the end date, including month and year, to be communicated clearly at purchase, and users should be notified where technically feasible.

Could the Commission set longer minimums?

Yes. The Commission may specify minimum support periods for particular product categories by delegated act, so watch for those.

When a standard changes, know first

One email a month: edition changes, new deadlines, and what they mean for documentation you already have. No sales sequence.

We don’t spam! Read our privacy policy for more info.