Cyber Resilience Act Support Period Requirements

Julian Meroi · Published 13 November 2026 · Last reviewed 13 November 2026

Under the Cyber Resilience Act, every manufacturer must decide how long it will handle the vulnerabilities of its product. That period is the support period. It must reflect how long the product is expected to be in use, it must be at least five years unless the product is expected to be in use for less time, and its end date must be clear to the buyer at the time of purchase.

This guide shows how to reach that decision, record the evidence for it, apply it to the units you place on the market and plan for the obligations that continue after support ends.

What the support period covers

The support period is the time during which the manufacturer must make sure that the product’s vulnerabilities, including those in its components, are handled effectively and in line with the vulnerability handling requirements of Annex I Part II. The duty applies from the moment the product is placed on the market and for the whole support period. Article 13(8).

Those requirements cover knowing what the product contains, remediating vulnerabilities without delay, testing the product’s security, disclosing fixed vulnerabilities, a coordinated vulnerability disclosure policy, a contact address for reports and the secure distribution of security updates. Our CRA vulnerability handling guide explains how to run that process.

The support period is about vulnerability handling. Helpdesk service, new features, repairs and warranty are set by your contracts and by other law, and they can last for a different time. The user information must state the type of technical security support you offer and the end date of the support period, so keep the security support clearly separate from other service commitments in what you publish.

The requirements apply to products placed on the market from December 11, 2027. A product placed on the market before that date is covered only if it is substantially modified on or after December 11, 2027. Reporting under Article 14 is different: it has applied since September 11, 2026, including to products placed on the market earlier. Article 69.

How long the support period must be

Article 13(8) sets three rules that work together:

1. The period must reflect how long the product is expected to be in use. In particular, take into account reasonable user expectations, the nature of the product, including its intended purpose, and any Union law that determines the lifetime of products with digital elements.
2. The period must be at least five years.
3. If the product is expected to be in use for less than five years, the period corresponds to that expected use time.

Five years is a minimum. The Commission’s guidance states that it is not a default for all products. The recitals say that products expected to be in use for longer should have longer support periods, and they name motherboards, microprocessors, routers, modems, switches, operating systems and video-editing tools as examples. Products for industrial settings, such as industrial control systems, are often in use for significantly longer. Commission guidance, paragraph 126.

A period shorter than five years needs a product that is genuinely expected to be in use for less time. The reason must come from the nature of the product. The recitals give the example of a contact tracing app intended for use during a pandemic. A one-year warranty or a one-year maintenance contract does not show that the product will be used for only one year.

The period reflects expected use, but it is not always equal to it. The FAQ points out that the criteria are applied in a proportionate way, so manufacturers are not expected simply to set the support period equal to the expected use time, unless that time is under five years. Whatever period you choose, your records must show how the criteria led to it. FAQ section 4.5.1.

Close

Check for category rules. The Commission may adopt delegated acts that set a minimum support period for specific product categories, where market surveillance data suggests that support periods are too short. Market surveillance authorities monitor how manufacturers apply the criteria, and their administrative cooperation group (ADCO) will publish average support periods and guidance with indicative periods for product categories. Averages and indicative periods are inputs to your assessment and do not set a legal minimum. Article 52(16).

Build the evidence for the decision

You must include the information you took into account to determine the support period in the technical documentation. Annex VII lists it as part of the file. The CRA does not prescribe a format or a scoring method. For most products the evidence falls into a few groups:

• Expected use: how long customers keep and use this kind of product, from field data, replacement cycles, service records or customer contracts, and what buyers can reasonably expect from the product and from the way it is sold.
• Nature and intended purpose: what the product does, where it is installed and how hard it is to replace. For hardware, physical durability and wear matter.
• Union law on product lifetime: whether other EU rules that apply to the product set or affect its lifetime.
• Optional factors: the support periods of similar products from other manufacturers, how long the operating environment will be available, the support periods of third-party components that provide core functions, and guidance from ADCO and the Commission.
• Assumptions and open points: what you could not confirm, and when you will check it again.

Apply these in proportion to the product. A simple consumer product needs less analysis than an industrial controller expected to run for decades. A sales target or a product roadmap on its own does not establish how long the product will be in use. Record the reasoning that links the evidence to the period, together with the evidence itself, so that someone outside the team can follow it.

The same expected use time also feeds the cybersecurity risk assessment, which must take into account how long the product is expected to be in use. Our CRA technical documentation guide shows where the support period evidence fits in the file.

Apply the period to the units you place on the market

Placing on the market means the first making available of a product on the Union market. Under EU product rules, this applies to each individual unit, not to a model as a whole. The date a model is launched, the date a unit is made, the date it first enters EU supply and the date a customer buys it can all differ. Establish from your sales and logistics records when each unit, or each batch, is first made available in the EU. Blue Guide, section 2.3.

According to the FAQ, units that are already on the market can still be sold after their support period ends. Units of the same model that you place on the market later need their own support period, set under Article 13(8). FAQ section 4.5.3.

Two consequences follow:

• A resale does not start a new period. When a distributor or a user sells on a unit that is already on the market, that is not a new placing on the market, so the unit keeps its end date.
• A single end date for the whole model needs checking. If you keep placing units of a model on the market for several years, one end date for all of them meets Article 13(8) only if it is long enough for the last units you place. Otherwise, assess each new batch and give it its own end date.

Check supplier and platform coverage

The support periods of third-party components that provide core functions are one of the factors you may take into account. They do not limit your duty. During your support period you must handle vulnerabilities in the whole product, including in components whose own support has ended. If a component’s vulnerability cannot be addressed adequately through mitigation, the FAQ expects you to remediate it by other means, for example by replacing the component or developing a fix yourself. FAQ section 4.3.7.

Plan for this when you set the period:

• List the components that provide core functions and their announced end of support. Your SBOM is the starting point; our CRA SBOM requirements guide covers how to build it.
• For each component whose support ends before yours, record how you will cover the gap: an extended support agreement, a planned migration, a replacement or your own maintenance.
• Record what still needs confirming, such as a supplier offer that has not been signed or a migration that has not been tested.

A supplier’s end of support does not by itself shorten your support period, and the CRA sets no rule that the period follows the shortest or the longest component. Where a component is itself a CRA product, its manufacturer has its own vulnerability handling duties, which makes your work easier, but you remain responsible for your product as a whole. If you develop a fix for a component, you must share it with the person or entity that maintains the component.

Software versions and substantial modifications

Each substantially modified software version needs its own declared support period. Software is often released as a series of substantially modified versions. The Commission’s guidance states that each one placed on the market needs a support period that meets Article 13(8), including the five-year minimum unless that version’s expected use time is demonstrably shorter.

You may limit remediation to the latest version on two conditions. Once you have placed a later substantially modified version on the market, you may address and remediate vulnerabilities only in the version you placed last, provided that:

1. users of the earlier versions can get the latest version free of charge; and
2. they do not incur additional costs to adjust the hardware and software environment in which they use the original version.

Article 13(10).

The Commission’s guidance reads “additional costs” in a practical way. It treats reasonable operational effort that is inherent to applying updates or maintaining a secure operating environment as normal, including personnel time, routine testing, configuration adjustments and upgrades of underlying software dependencies needed to deal with end-of-life components or known vulnerabilities. Mandatory purchases of new hardware, infrastructure replacement and fundamental changes to the operating environment count as additional costs. Check this against what your customers would actually have to do to upgrade. Commission guidance, paragraph 130.

The flexibility covers remediation only. For the support period, the other vulnerability handling requirements still apply, such as the coordinated vulnerability disclosure policy and the measures for sharing information about potential vulnerabilities, and so does reporting under Article 14. Where you stop remediating an earlier version, the guidance expects you to inform users who have not upgraded, if this is technically feasible. Where hardware such as a smartphone cannot run the latest version of the operating system it was delivered with, the recitals expect security updates for the latest compatible version for the support period.

The guidance confirms that you may still choose to keep fixing earlier versions, including on a paid basis or under other commercial terms, as long as users can upgrade to the latest version free of charge and without additional costs.

Substantial modification of a product already on the market

A substantial modification is a change after placing on the market that affects the product’s compliance with the Annex I Part I requirements, or that changes the intended purpose for which the product was assessed. When the modified product is made available on the market, it is treated as a new product, so its support period must be determined again. Not every update is a substantial modification, and the guidance generally does not treat refurbishment, maintenance or repair as one. Classify the change first, and record the reasoning either way. Article 3(30).

According to the Commission’s guidance, a substantial modification calls for a reassessment against the Article 13(8) criteria, but it does not automatically reset or extend the support period. What matters is whether the modification changes the factors that set the original expected use time:

• If it does not, the period follows the remaining expected use time as originally determined, even if less than five years remain. This is typical where the physical durability of the hardware set the original period and the modification concerns only software functions or back-end services.
• If it does, recalculate the period from the new expected use time. The guidance gives the example of a programmable logic controller whose computing platform is replaced with components designed for a significantly longer life.

Commission guidance, paragraphs 133 to 135.

This is a different question from placing new units of an unchanged model, which the previous sections cover.

Subscription software

The recitals recognize that some software can by nature only be made available on a subscription basis, in particular where it becomes unavailable to the user, and so stops being used, once the subscription ends. Its expected use time can then be shorter than five years. The FAQ gives the example of enterprise antivirus software that works only with an active subscription, because it depends on current definitions, and that is no longer accessible after the subscription expires. FAQ section 4.5.2.

A billing model alone does not show a shorter expected use. If customers can keep using the software after they stop paying, the software is still in use.

The FAQ also describes a separate case: free and open-source software placed on the market by a manufacturer that can monetize it only by selling paid support services on a subscription basis. The FAQ accepts that such software may stay in use after the user stops paying, and states that the support period then equals the duration of the active subscription. This interpretation is not in the Regulation. Article 13(8) allows a period shorter than five years only where the product is expected to be in use for less than five years, and the FAQ is not legally binding. If you plan to rely on it, check that your facts match the FAQ’s case closely and record your reasoning in the technical documentation.

Example: support decision for Example Edge Gateway

Example Edge Gateway is a fictional industrial gateway that connects machines on a factory floor to a monitoring platform. Assume it is within the CRA’s scope and that all units are placed on the market after December 11, 2027. The figures below are part of the example. They are not a default or a sector minimum.

The manufacturer’s service records for earlier gateway models show that customers usually replace them after nine to eleven years, when production lines are refitted. Customers buy the gateway for long-term installation and expect long support. The gateway runs on a third-party embedded operating system whose vendor has announced security support until December 2035. The team finds no EU rule or delegated act that sets a lifetime or a minimum support period for this category. Considering all of this, the manufacturer sets a support period of ten years.

• Batch A is first placed on the EU market in January 2028. Its end date is January 2038.
• Batch B of the same model is placed on the market in January 2030. The team reassesses the period before placing it. The evidence has not changed, so Batch B gets ten years and an end date of January 2040.
• A resold Batch A unit keeps the January 2038 end date. A later sale does not turn it into a Batch B unit.
• The operating system loses vendor support in December 2035. The gateway’s support period does not shorten. The team must cover the gap until January 2040, either by migrating the gateway to a newer release of the operating system through a firmware update or by agreeing extended support with the vendor.
• A security update issued in January 2037 must remain available until at least January 2047. That does not create a duty to develop new updates until 2047.

The team’s record, as reviewed in January 2030, looks like this:

This is an example of implementation based on CRA Article 13(8)-(19), Annex II and Annex VII and on the Commission’s guidance and FAQ. These record fields, statuses, owners and workflow choices are not mandated by the CRA, and the rows are a sample. The duties to determine and justify the support period, handle vulnerabilities for its whole length and inform users remain binding.

The open row matters most. Until the migration is tested or the extended support is signed, the team cannot show how it will handle vulnerabilities in the operating system between December 2035 and January 2040.

Tell users the end date

At the time of purchase, state the end date of the support period, with at least the month and year, clearly and in an easily accessible way. Where applicable, show it on the product, on its packaging or by digital means. The user information must also state the type of technical security support you offer. Article 13(19).

If units of the same model have different end dates, make sure the date a buyer sees matches the unit they buy, for example by printing it per batch and showing it in the product’s interface.

When the period ends, display a notification to users that the product has reached the end of its support period, where this is technically feasible given the nature of the product. That condition applies to the notification only. The end date at the time of purchase is always required.

What continues after the support period ends

When the support period ends, so do the vulnerability handling requirements of Annex I Part II for that product. Several other obligations have their own periods:

• Reporting: Article 14 still applies. If you become aware of an actively exploited vulnerability in the product or a severe incident affecting its security, you must report it. Our CRA reporting requirements guide explains the triggers and deadlines.
• Issued security updates: each security update made available during the support period must remain available for at least ten years after it was issued, or for the rest of the support period if that is longer. This keeps issued updates available. It does not require new ones. Article 13(9).
• Technical documentation and declaration of conformity: keep them at the disposal of market surveillance authorities for at least ten years after the product was placed on the market, or for the support period if that is longer.
• User information and instructions: keep them available to users and authorities for the same period. If they are online, they must stay accessible, user-friendly and online for that time.
• Software archives: you may keep public archives of historical versions. If you do, inform users clearly and in an easily accessible way about the risks of using unsupported software.

The recitals also ask manufacturers to consider releasing the source code at the end of the support period, to other companies that commit to continue handling vulnerabilities or to the public. This is a recommendation, not a requirement, and releasing code needs its own licensing and security review.

Review the decision before release

Before you place a product or a new batch on the market, check that:

• the technical documentation records the evidence, the reasoning and what you could not confirm;
• the period is at least five years, or the file shows why the product is expected to be in use for less;
• each batch and each substantially modified version has an assessed end date;
• every core component is covered until your end date, or the gap is an open item with an owner and a plan;
• the end date and the type of support appear wherever the buyer sees them at purchase;
• for software, the conditions of Article 13(10) are met before you stop remediating earlier versions;
• the end-of-support notice, the availability of issued updates and the retention of documents and user information are planned.

This checklist is an example of implementation based on CRA Article 13 and Annex VII. The CRA does not mandate this checklist; the rules on determining, documenting and communicating the support period remain mandatory.

How Meroi Security can help

Meroi Security can review how you determine support periods against the CRA, organize the evidence for the technical documentation, check component and platform coverage against your end dates, and set up the end-date information and end-of-support planning for each product. Explore our Cyber Resilience Act compliance services.