Of all the duties in the Cyber Resilience Act, the support period is the one with the largest commercial consequence and the shortest summary. "Five years of security updates", almost every summary says. That is half the rule. The other half says the period must reflect the time the product is expected to be in use, that it may be shorter for short-lived products and should be longer for long-lived ones. A manufacturer that writes the half rule into a contract or a product plan commits either to more than the law asks or to less than it will later demand.
This text takes apart Article 13(8) of Regulation (EU) 2024/2847: what the period is, how it is set, which other duties hang on it, where it has to be documented and stated, and which decisions a manufacturer is making with it today. If the CRA as a whole is still unfamiliar, start with What is the Cyber Resilience Act?
What the support period is
The support period is the time during which the manufacturer must ensure that the product's vulnerabilities are handled effectively and in accordance with Annex I Part II. In practice: find vulnerabilities, fix them, ship security updates, disclose what was fixed. The eight duties in detail are in SBOM under the Cyber Resilience Act, because the software bill of materials is their common starting point.
The period is not a warranty in the contract-law sense and not a promise of feature updates. It is the duration of the public-law duty to keep a product secure. It starts when the product is placed on the market and ends on a date the manufacturer sets and must state.
How the period is set
Article 13(8) contains four rules, and all four apply together.
1. The period reflects the expected time in use. The manufacturer sets it so that it reflects the time the product is expected to be in use, taking into account reasonable user expectations, the nature and intended purpose of the product, and relevant Union law that sets a lifetime for it. It may also take into account the support periods of comparable products from other manufacturers.
2. At least five years. That is the floor for the normal case. The Regulation's words: "the support period shall be at least five years."
3. Unless the product is used for less. "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." A product that is replaced by a successor after three years and no longer used may have a three-year period. The reasoning has to hold, and it has to be documented, on which more below.
4. The Commission may set minimum periods for product categories. Where manufacturers in a category systematically choose periods that are too short, the Commission may prescribe a minimum period for that category by delegated act. Anyone planning at the floor today should budget for that.
So the rule is not "five years". The rule is "as long as the product is in use, at least five years, unless it is demonstrably used for less". For industrial controllers, building technology or devices near medical use that stay in service for ten or fifteen years, five years is therefore too short. For a mobile app with a clear successor cycle, it may be too long.
What hangs on the period
The support period is a dial that several other duties are wired to. Whoever sets it sets them too.
Two consequences matter in practice. First, an eight-year period does not extend the ten-year retention duties; a twelve-year period does. Second, the reasoning is part of the documentation. A date without the thinking that led to it is an incomplete technical file, and that is exactly what a market surveillance authority checks when it asks for Annex VII.
Where the period has to be stated
In three places.
In the technical documentation, as the reasoning: expected time in use, user expectations considered, comparable products, relevant law (Annex VII(4)). The full list: content of the technical documentation.
In the user information, as the end date and a description of the type of support, accompanying the product (Annex II(7)). The text: information and instructions to the user.
At the time of purchase, in an easily accessible manner, so that a buyer knows the end date before deciding, and, where applicable, on the product, its packaging or by digital means. An end date that lives only on page forty of a PDF does not meet that requirement.
The decision a manufacturer is making now
The support period is not a compliance formality. It is a product decision with a price. Four cases come up again and again.
Long-lived hardware. A device that experience says stays in the field for twelve years has a support period that reflects it. A manufacturer that states five years has to explain why the device is no longer in use after that, and for industrial controllers that explanation rarely holds. The alternative is to set the period honestly and price the maintenance in.
Software with a successor cycle. An application replaced by a new major version every three years has a shorter period if the old version really is no longer used afterwards. The observation that customers keep running old versions is then the counter-argument, and it belongs in the reasoning.
Products with purchased components. A product cannot have a longer period than its components are maintained for, unless the manufacturer takes over the maintenance itself. A chip whose firmware the supplier stops updating after four years caps the end product's period, or forces the manufacturer to carry the risk. That is a question for the supply contracts, today.
Products with remote processing. If a product cannot function without a cloud service, the service is part of the product, and the support period applies to it as well. A service switched off after three years ends the product's period early.
What goes wrong
- "Five years for everything." Too short for long-lived products, needlessly long for short-lived ones, and in both cases without the reasoning Annex VII requires.
- Confusing support with feature updates. The period covers security updates and vulnerability handling. New features are not owed, and security updates should, where technically feasible, be provided separately from feature updates.
- Not stating the end date anywhere. Annex II requires it in the user information, and it must be accessible at the time of purchase.
- Treating the period as the end of all duties. Retention duties run for at least ten years, and the reporting obligations in Article 14 are not tied to the support period in the text. A manufacturer that learns of an actively exploited vulnerability after the end date should not dismiss the reporting question by pointing at the date.
What to do now
- Determine the expected time in use per product, from field experience, comparable products and customer behaviour, not from the wish for a short period.
- Set the period and write down why. The date plus the thinking behind it, in the technical documentation. If the period is under five years, the reasoning twice as careful.
- Put the end date in the user information and at the point of purchase: product page, shop, quote.
- Review supply contracts: which components are maintained for how long, and who carries the risk afterwards.
- Adjust retention periods: for periods over ten years, the retention of documentation and the declaration of conformity extends with them.
- Record the period in the evidence register, with end date and reasoning, so it is at hand for every check.
For the last point there is a way to do it without your own tooling: the Legalithm command cra support takes the end date and the reasoning onto the record and refuses a period without a reason, because a date alone does not satisfy Annex VII. Open source, no account: developer tools.
Frequently asked questions
Are five years mandatory? Five years is the floor for the normal case. If the product is expected to be used for less, the period may be shorter. If it is used for longer, the period must reflect that.
May I extend or shorten the period later? Extend, yes; that is a new promise to users. Shortening contradicts the stated end date buyers relied on and the reasoning in the technical documentation. A manufacturer that wants to shorten needs a reason that overtakes the original one, and must inform users.
Is the period per product or per version? Per product with digital elements as placed on the market. A substantially modified version is a new placing on the market with its own period.
What about products already on the market? The Annex I requirements, and with them the support period, apply to products placed on the market before 11 December 2027 only if they are substantially modified after that date (Article 69(2)). The reporting obligations in Article 14 apply regardless from 11 September 2026.
Do I have to provide security updates after the end date? They are owed only during the period. Updates once issued must remain available afterwards, for at least ten years after placing on the market. A manufacturer that keeps shipping updates voluntarily does so outside the duty.
Sources
- Regulation (EU) 2024/2847, Article 13(8) and (9), Article 18, Annex II(7), Annex VII(4), Annex VIII: eur-lex.europa.eu/eli/reg/2024/2847/oj
- Every CRA obligation with its wording: Cyber Resilience Act obligations, in particular obligations of manufacturers
This text is a cited starting point, not legal advice. The text of the Regulation prevails.
