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.
| Criterion | Must or may | Typical evidence |
|---|---|---|
| Reasonable user expectations | Must | Customer requirements, tenders, feedback from sales |
| Nature of the product and intended purpose | Must | Field of use, operating environment, typical replacement cycle |
| Union law on the lifetime of products | Must | Check whether such rules exist for the product type |
| Support periods of similar products from other manufacturers | May | Published support policies of comparable products |
| Availability of the operating environment | May | Life cycle of the operating system, runtime or platform |
| Support periods of third-party components that provide core functions | May | Supplier commitments, vendor data on chipset, firmware and libraries |
| Commission guidance (since July 2026) and ADCO guidance | May | Guidance 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
- 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.
- Check the mandatory criteria. Record user expectations, intended purpose and any requirements from Union law in writing.
- 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.
- 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.
- Decide and justify. Set start and end, with month and year. Record who decided and why.
- 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.

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
- Guide "Does the CRA apply to me? Checking products with digital elements"
- Guide "Technical documentation under the CRA: content and upkeep"
- Guide "Vulnerability handling under the CRA: requirements and CSAF"
- Guide "CRA conformity assessment and CE marking"
- Whitepaper on the CRA for manufacturers
- The CRA in Complass
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.
