Programma pilota: 30 % di sconto nel primo anno.Vedi le condizioni

Complass – Navigate compliance Complass – Navigate compliance

Setting and justifying the CRA support period

The support period under the Cyber Resilience Act is at least five years. If a product is expected to be in use for a shorter time, the period matches that shorter use time (Art. 13(8) CRA). What counts, though, is not the floor but how long your product is expected to be used. You state the end date at the time of purchase with month and year, and your reasoning goes into the technical documentation.

Complass: gap analysis with a maturity scale across the booked frameworks, including the CRA
Contenuto
  1. What the support period means
  2. The rule in Art. 13(8) CRA
  3. Six steps to an end date
  4. What users must be told
  5. Security updates during and after the period
  6. How to record the decision in the documentation
  7. Example from industry
  8. Checklist
  9. The support period in Complass
  10. Frequently asked questions
  11. Read more

Stato:

This guide shows which criteria the regulation names, how you reach a sound end date in six steps and what applies during and after the period.

What the support period means

The support period is the time during which you as the manufacturer must ensure that vulnerabilities of your product are handled effectively and in line with Annex I, Part II CRA (Art. 3(20) CRA). Further duties depend on it:

  • Handle vulnerabilities: From placing on the market and throughout the period, including components (Art. 13(8), first subparagraph, CRA).
  • Keep the risk assessment current: It is documented and updated where needed during the period (Art. 13(3) CRA).
  • Keep the technical documentation current: Continuously where needed, at least during the period (Art. 31(2) CRA).
  • Corrective action: From placing on the market and during the period you act when the product or your processes are not in conformity (Art. 13(21) CRA).
  • Retention: Technical documentation and the EU declaration of conformity for at least ten years after placing on the market or for the support period, whichever is longer (Art. 13(13) CRA).

These duties apply from 11 December 2027 (Art. 71(2) CRA). Products placed on the market before then are covered only after a substantial modification. The reporting obligations under Art. 14 have applied since 11 September 2026 to all products in scope (Art. 69(3), Art. 71(2) CRA).

The rule in Art. 13(8) CRA

You set the support period so that it reflects the time the product is expected to be in use. The regulation names criteria you must take into account and criteria you may take into account. You apply all of them in a proportionate way.

CriterionMust or mayTypical evidence
Reasonable user expectationsMustCustomer requirements, tenders, feedback from sales
Nature of the product and intended purposeMustField of use, operating environment, typical replacement cycle
Union law on the lifetime of productsMustCheck whether such rules exist for the product type
Support periods of similar products from other manufacturersMayPublished support policies of comparable products
Availability of the operating environmentMayLife cycle of the operating system, runtime or platform
Support periods of third-party components that provide core functionsMaySupplier commitments, vendor data on chipset, firmware and libraries
Commission guidance (since July 2026) and ADCO guidanceMayGuidance published when you set the period

Two fixed limits apply on top. First, the period is at least five years. Second, where the product is expected to be in use for less than five years, the period matches that shorter time. The Commission may set a minimum support period for certain product categories by delegated act where market surveillance data point to inadequate periods.

In addition, on 27 July 2026 the European Commission published non-binding guidance on applying the CRA (Art. 26 CRA, Communication C(2026) 5252, section 5). It makes two things clear: five years is a floor, not a default, and every substantially modified software version placed on the market needs its own declared support period. Also check whether the ADCO group has since published guidance for your product category (as of November 2026).

Six steps to an end date

  1. Establish the use time. How long do customers actually use the product? Service data, spare-part requests and customer conversations are better sources than estimates.
  2. Check the mandatory criteria. Record user expectations, intended purpose and any requirements from Union law in writing.
  3. Clarify dependencies. Ask suppliers of key components about their support. If it ends earlier, plan how to close the gap: moving to a newer version, maintaining it yourself or replacing the component.
  4. Check your capability. Can you handle vulnerabilities for the whole period? That includes the team, build environment, signing keys and test setups, which must still work many years from now.
  5. Decide and justify. Set start and end, with month and year. Record who decided and why.
  6. Publish and monitor. State the end date at purchase and in the user information. Review the reasoning when assumptions change, for example because a supplier shortens its support.

What users must be told

  • At purchase: The end date, with at least month and year, is stated clearly, understandably and in an easily accessible manner, where applicable on the product, its packaging or by digital means (Art. 13(19), first subparagraph, CRA).
  • In the user information: State the type of technical security support and the end date of the period during which users can expect vulnerabilities to be handled and to receive security updates (Annex II(7) CRA).
  • At the end: Where technically feasible, the product displays a notification that its support period has ended (Art. 13(19), second subparagraph, CRA).

Security updates during and after the period

  • Without delay and free of charge: Security updates are disseminated without delay and free of charge, with advisory messages on possible action. A different agreement is possible only with a business user for a tailor-made product (Annex I, Part II(8) CRA).
  • Separate from features: Where technically feasible, new security updates are provided separately from functionality updates (Annex I, Part II(2) CRA).
  • Keep them available: Every security update issued during the support period remains available for at least ten years after it was issued or for the remainder of the support period, whichever is longer (Art. 13(9) CRA). A download archive therefore often has to outlast the support itself.
  • New software versions: If you have placed substantially modified later versions of a software product on the market, you may limit the fixing of vulnerabilities to the latest version. The condition: users of earlier versions get it free of charge and incur no extra cost to adjust their hardware and software environment (Art. 13(10) CRA).
  • Archives of old versions: If you offer historical versions publicly, inform users clearly about the risks of unsupported software (Art. 13(11) CRA).

How to record the decision in the documentation

The information you took into account when setting the period goes into the technical documentation (Art. 13(8), fifth subparagraph, and Annex VII(4) CRA). A short section with these details works well:

  • product, version and the period with start and end
  • expected use time and its sources
  • assessment of each mandatory criterion and of the optional criteria you used
  • support commitments for key components and the plan for gaps
  • justification if the period is shorter than five years
  • decision with name, role and date, plus triggers for a new review

Make sure the documentation, user information, website and contracts all state the same end date.

Example from industry

The example is invented. A maker of industrial gateways places a new product line on the market in January 2028.

  • Use time: Service data show that customers run gateways of the previous line for twelve years on average.
  • Component: The embedded operating system has a shorter vendor support. The plan provides for a move to the next long-term support version, delivered as a free update.
  • Decision: Support period January 2028 to December 2039, approved by product management and the managing director.
  • Statements: "Security updates until 12/2039" on the data sheet, in the user information and on the product page.
  • Next: The operating system move is scheduled as a task with a due date, not left as an open question.

Checklist

  • The expected use time is backed by sources.
  • All mandatory criteria under Art. 13(8) CRA are assessed.
  • Support commitments for key components are on file.
  • There is a plan for gaps in component support.
  • A period shorter than five years is justified by the shorter use time.
  • The end date with month and year is stated at purchase and in the user information.
  • Security updates are free of charge and, where feasible, separate from functionality updates.
  • Updates stay available for at least ten years after they are issued.
  • The reasoning is in the technical documentation.
  • Triggers for a new review are set.

The support period in Complass

An end date in a spreadsheet, the reasoning in an email and the user information in a third document: that is how the connection gets lost. In Complass everything sits on the product version:

  • Per version: You record placing on the market and the start and end of the support period. A version on the market needs a support end.
  • Justification: If the period is shorter than five years, Complass asks for a justification before you save.
  • Documents: The technical documentation and the user information take the period and end date from the product file. Sentences that carry a commitment are marked for review.
  • Reminders: The people responsible get a notification 180, 90 and 30 days before the support end and once it has passed.
  • Suppliers: The CRA questionnaire for component suppliers asks about their support period and security updates.
List of the demo company's vulnerability findings with CVSS, priority, status and due date
During the support period: findings in your own products with priority, status and due date.

Frequently asked questions

Are five years always enough?

No. Five years is the floor. If your product is usually in use for longer, the period has to reflect that. You explain how you weighed the criteria in the technical documentation.

When may the period be shorter than five years?

Only if the product is expected to be in use for less than five years. The period then matches that use time. Keep the evidence for it.

Who sets the support period?

The manufacturer. If you build in third-party components, you may take their support into account. The duty to handle vulnerabilities in your own product still stays with you.

What applies after the support period ends?

Security updates already issued remain available under Art. 13(9) CRA. You keep the documentation and the declaration of conformity for at least ten years after placing on the market or until the end of the support period, whichever is longer (Art. 13(13) CRA). Where technically feasible, the product tells users that support has ended.

Do we need a separate period for each version?

The regulation ties the period to the product. Under the Commission guidance (July 2026), every substantially modified software version you place on the market needs its own declared support period. If the modification does not change the factors behind the expected use time, the remaining period stays, even if it is shorter than five years. Art. 13(10) CRA lets you limit fixes to the latest version. Recording it per version makes clear which end date applies to which release.

In a demo we use the demo company to show you how support period, reasoning and user information come together in one product file.

Request a demo Try it for 14 days

Read more

Not legal advice. This guide gives a general overview and does not replace an assessment of the individual case. The wording of Regulation (EU) 2024/2847 in the Official Journal, including its corrigenda, is authoritative. As of November 2026.