Choosing and changing your CRA support period: shorter than five years, extending, variants, and the end-of-support notice

Our guide "What the support period means" explains the concept: under the Cyber Resilience Act (CRA, Regulation (EU) 2024/2847) you handle a product's vulnerabilities until a date you choose and publish, with five years as the floor. This guide covers the decisions after that: a period under five years, changing a published period, hardware variants, long sales lives, and the end-of-support notice. It is a documentation aid, not legal advice.

Besides the Regulation, this guide draws on the Commission's guidance on applying the CRA, published on 27 July 2026 as C(2026) 5252. The Commission calls it non-binding and says it applies only once formally adopted. We cite it as the Commission's reading, not as law.

A period shorter than five years

Article 13(8) sets the floor: "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."

Recital 60 narrows the exception: a manufacturer "should be able to define a support period of less than five years only where this is justified by the nature of the product with digital elements concerned and where that product is expected to be in use for less than five years". Its examples are a contact-tracing app limited to a pandemic, and software available only by subscription. The Commission guidance, for each substantially modified software version, keeps the five-year minimum unless that version's expected use time is "demonstrably shorter".

Five years is a floor, and the same recital also points upwards from it: where a product "is reasonably expected to be in use" for longer than five years, "manufacturers should accordingly ensure longer support periods". Its examples include routers, modems and switches, operating systems, and industrial control systems. That is the sentence the Commission guidance builds on when it says (point 126, not binding) that five years "is therefore not to be considered as the default for all products with digital elements". The Commission says it to push the period above five years for long-lived products. It is not a reason to go below five.

So a shorter period needs evidence about the product, not about your budget. Cost is not one of the factors Article 13(8) lists; the Article asks that the factors be weighed "in a manner that ensures proportionality". Evidence that can carry a shorter period (argument: our reading of what "demonstrably" asks for):

• A physical end of life. A sealed battery that cannot be replaced, a consumable sensor element, a device built for a single event or season.
• Field data. How long units actually stay in use or online, from your own telemetry or returns.
• An intended purpose with an end. A device sold for a time-limited trial or a project with a fixed close.

Evidence that does not carry it on its own (argument): "our competitors offer less", or "the chip vendor's SDK support ends sooner". Both are factors Article 13(8) lets you weigh, but they speak to what is usual and what your foundations allow, not to how long customers will use the product.

Write the reasoning into the technical documentation; Annex VII point 4 asks for "relevant information that was taken into account to determine the support period". Recital 59 expects you to share it with market surveillance authorities on request.

Extending a published period

Nothing in the CRA stops you from giving more. If you extend:

1. Change the date everywhere: the point of sale (Article 13(19)), the user information (Annex II point 7) and the technical documentation (Annex VII point 4).
2. Remember what comes with it. Every security update you release during the period must stay available for at least 10 years after release, or for the rest of the support period if that is longer (Article 13(9)). A longer period stretches your archive too.

The Commission guidance also describes when a recalculation is expected rather than optional: where a substantial modification changes the factors that set the expected use time, such as hardware changes that extend the product's working life, "the manufacturer should recalculate the support period to reflect the new expected use time".

Shortening a published period

The CRA has no procedure for shortening a support period you have published, and nothing in it says you may. The duty in Article 13(8) runs "for the support period", and the end date is what Article 13(19) required you to state at the time of purchase. Our reading (argument): treat the date shown to a buyer as fixed for the units they bought. You can choose a different period for units you place on the market later, shown at their purchase.

Two situations look like shortening but are in the text:

• Software versions. Article 13(10) lets a manufacturer of a software product that has placed "subsequent substantially modified versions" on the market fix vulnerabilities (Annex I, Part II(2)) only in the latest version, provided users of earlier versions can move to it "free of charge" and without "additional costs to adjust the hardware and software environment". The Commission guidance accepts that this may result "in a shorter effective support period for those earlier versions", and its examples include a smartphone operating system. For device firmware, this works only if every unit still in its support period can take the newest firmware (argument).
• Closing down. A manufacturer that ceases operations and can no longer meet the Regulation must tell the market surveillance authorities and, as far as possible, the users before the closure takes effect (Article 13(23)).

In the Commission's guidance (not binding), a substantial modification does not reset the clock either way: it says a substantial modification "does not automatically result in the support period being reset, or even extended"; where the change does not affect the expected use time, the period follows the product's remaining expected use time.

Several hardware variants

A product line often has variants: a Wi-Fi and a cellular model, a 2025 board and a 2027 board revision. The Commission guidance (points 174 to 177, not binding) accepts one risk assessment, one set of technical documentation, one conformity assessment and one declaration for variants that "share the same architecture, security-relevant design and intended purpose" and are exposed to the same cybersecurity risks. It attaches two conditions: all the variants are "adequately covered in terms of relevant risks and essential requirements", and the declaration identifies the variants it covers.

The same passage sets the limit. What decides, in the guidance's words, is "whether the differences between the variants are relevant to cybersecurity". Colour, form factor and memory size are not, and need no separate assessment. Differences such as "communication interfaces, software stacks, update mechanisms or remote connectivity" must be reflected in the risk assessment "and, where necessary, in the conformity assessment and technical documentation". And the guidance ends: "Reliance on a single conformity assessment is only possible to the extent that the products with digital elements do not present differences with regards to their cybersecurity properties."

What that means for the example above (argument): a Wi-Fi and a cellular model differ in a communication interface, and usually in the modem firmware and network stack behind it. That is the kind of difference the guidance names, so the different radio puts the single assessment in question. The two models share one conformity assessment only if their cybersecurity properties do not differ, and that is something you have to show. A line about the second radio in the risk assessment does not by itself keep one assessment and one declaration for both. A board revision raises the same question whenever it changes a chip, the software stack or the update mechanism.

Support periods follow the same logic (argument). Variants whose expected use time is the same can share one end date. A variant whose expected use time differs, or whose core components lose vendor support sooner, can have its own; Article 13(8) lets you weigh "the support periods of integrated components that provide core functions". In practice:

• Keep a table of every variant and hardware revision with its own end date, and show the right one at each point of sale.
• Plan firmware branches by the latest end date among the variants a branch serves: one firmware line that runs on three boards is maintained until the last of them leaves support.

Selling one model for years

Placing on the market applies to each individual unit, not to the model; the Commission guidance quotes the Blue Guide that it refers "to each individual product, not to a type of product". A unit sold in the model's fifth year is placed on the market then. If the model has one fixed end date, that unit's remaining support may fall below the period its expected use time calls for (argument).

Two workable patterns: move the end date out for units placed later (for example per production year, printed on the box), or set the model's date far enough out to cover the last units you expect to sell.

The end-of-support notice

Article 13(19) has a second rule beside the date at purchase: "Where technically feasible in light of the nature of the product with digital elements, manufacturers shall display a notification to users informing them that their product with digital elements has reached the end of its support period." Recital 56 asks you to use the product's own interface for it where there is one. The guidance expects the same notice when you stop fixing earlier software versions under Article 13(10).

A notice that helps users (argument: good practice beyond the minimum) says:

• the date and the product, variants and versions it covers;
• what stops: vulnerability handling and security updates;
• the last update and where it stays available, at least 10 years from its release (Article 13(9));
• what users can do: keep using it with the risk stated, replace it, or decommission it securely, which Annex II point 8(d) asks the user information to explain;
• what happens to the source, if anything: recital 61 asks manufacturers to consider releasing the source code, publicly or to a company that commits to continuing vulnerability handling.

Send it ahead of the date, so users can plan, and again on the date, on the device where it can show one.

What is settled and what is not

Settled (evidence): the five-year floor and its exception, the 10-year availability of updates, the date at purchase and the end-of-support notification in Article 13(19), Article 13(10) for software versions and Article 13(23) on closing down.

Not settled (as of 8 October 2026): the Commission guidance is published but not yet formally adopted. The Commission may also set minimum support periods for specific product categories by delegated act, where market surveillance data shows periods are inadequate (Article 13(8)). We update this guide when either happens.