The Cyber Resilience Act (CRA) does not make five years the automatic support period for every product. Manufacturers must set a support period that reflects how long the product is expected to be in use. Five years is the general minimum, but products expected to remain in use longer need a longer period, while a shorter period is permitted only when the product itself is expected to be used for less than five years.
What the five-year rule actually means
Article 13 of Regulation (EU) 2024/2847 requires manufacturers to determine a support period for each product with digital elements. During that period, vulnerabilities in the product, including its components, must be handled effectively in accordance with the vulnerability-handling requirements in Annex I Part II.
The support period must reflect the time the product is expected to be in use. The Regulation says manufacturers should take into account, in particular:
- reasonable user expectations;
- the nature of the product, including its intended purpose; and
- relevant Union law that determines the lifetime of the product.
Manufacturers may also consider support periods for comparable products, availability of the operating environment, support periods of integrated third-party components that provide core functions, and relevant Commission or market-surveillance guidance. These factors must be applied proportionately.
The legal floor is then applied to that analysis: the support period must be at least five years unless the product is expected to be in use for less than five years. If expected use is shorter, the support period must correspond to that expected use time.
This makes five years a minimum rule, not a default answer that removes the need for product-specific reasoning.
Start with expected use, not an arbitrary date
A defensible support-period decision begins with the product lifecycle. The manufacturer needs evidence for how long users can reasonably be expected to rely on the product, not merely how long the current development team intends to maintain a release branch.
Useful inputs can include:
- the intended purpose and typical deployment model;
- expected replacement cycles for the product category;
- warranty, service, maintenance or subscription arrangements;
- the lifetime of hardware on which the product depends;
- availability of compatible operating systems and runtime environments;
- field experience from earlier product generations;
- reasonable expectations created by sales material and user documentation; and
- applicable sector or product-lifetime legislation.
These are not a mandatory CRA template. They are practical evidence sources for the factors Article 13 requires the manufacturer to consider.
The analysis should be tied to an identifiable product, variant or release family. A single corporate statement such as “all products receive five years of support” may be operationally convenient, but it can be too short for long-lived products and unnecessarily long for a genuinely short-lived product.
When the support period should exceed five years
Recital 60 gives concrete examples of products that are often expected to remain in use for longer than five years. It mentions hardware components such as motherboards and microprocessors, network equipment such as routers, modems and switches, software such as operating systems and video-editing tools, and products intended for industrial environments such as industrial control systems.
The point is not that every product in those categories automatically receives one fixed period. The examples show the direction of the rule: if a product can reasonably be expected to remain in use for substantially longer than five years, the support period should reflect that longer use.
For an engineering organisation, this means product-lifecycle assumptions should be tested against the real deployment environment. A controller designed into machinery expected to operate for 15 years should not be assessed as if it were a short-lived consumer accessory merely because the software team uses a five-year planning horizon.
Long-lived products also need an operational plan for the dependencies behind that commitment. Teams should identify which operating systems, cryptographic libraries, hardware components, build tools and supplier relationships are needed to investigate and remediate vulnerabilities throughout the period. A support-period decision without a feasible vulnerability-handling model creates a governance gap that should be addressed before the product is placed on the market.
When less than five years can be justified
A support period shorter than five years is possible only where the product is expected to be used for less than five years. Recital 60 gives examples that illustrate the narrow logic: a contact-tracing application intended for the duration of a pandemic, or some subscription-based software that becomes unavailable and can no longer be used once the subscription ends.
The key condition is the product's expected use, not the manufacturer's preferred commercial support policy.
A one-year maintenance contract, for example, does not by itself prove that the product will stop being used after one year. Likewise, discontinuing sales does not necessarily end the installed base. If customers can continue to use the product after a contract, subscription or sales channel ends, that continuing use belongs in the support-period analysis.
Shorter periods should therefore be supported by evidence explaining why use itself is expected to end. The reasoning should be specific enough that a later reviewer can distinguish a genuinely short-lived product from a long-lived product with a short commercial maintenance offer.
What must continue during the support period
The support period is a vulnerability-handling commitment, not only a promise to keep a help desk open.
Annex I Part II requires manufacturers to identify and document vulnerabilities and components, address and remediate vulnerabilities without delay, apply effective and regular tests and reviews, publicly disclose information about fixed vulnerabilities subject to the CRA's conditions, share and enforce coordinated vulnerability disclosure policies, securely distribute updates, and provide security updates under the rules set by the Regulation.
Article 13 also requires manufacturers to have policies and procedures for processing and remediating potential vulnerabilities reported from internal or external sources.
Operationally, the organisation should be able to maintain at least:
- a vulnerability intake and triage path;
- product and component records for supported versions;
- access to the engineering capability needed to investigate findings;
- remediation, verification and release processes;
- security-update distribution and user communication;
- retained evidence of decisions and actions; and
- clear ownership through the end of the support period.
The exact implementation can vary by product, but the support period needs to be backed by a functioning vulnerability-handling capability rather than a date printed in documentation.
Do not confuse support duration with update availability
The CRA contains a separate rule for how long an issued security update must remain available.
Article 13(9) requires each security update made available to users during the support period to remain available after it is issued for at least 10 years or for the remainder of the support period, whichever is longer.
That can extend availability beyond the date on which the manufacturer is still actively handling new vulnerabilities for the product. For example, an update released near the end of a five-year support period does not disappear when active support ends; the availability rule continues to apply.
Teams should therefore maintain two distinct lifecycle dates:
- support end: when the defined vulnerability-handling period ends; and
- update-retention end: how long a specific issued security update must remain obtainable.
Keeping those records separate avoids treating the support period as a permission to delete historical security updates.
Communicate the end date clearly to users
The support period is also user-facing information.
The Commission's CRA summary explains that the end date, including month and year, must be specified clearly and understandably at the time of purchase. Annex II requires the information and instructions accompanying the product to state the type of technical security support offered by the manufacturer and the end date of the period during which users can expect vulnerabilities to be handled and security updates to be provided.
Product, legal and commercial teams should therefore agree on one controlled support-period record before product information is published. The same date should not diverge between technical documentation, user instructions, online product pages and internal vulnerability-management systems.
If the support period changes for a future product generation or variant, the affected scope should be explicit. Avoid silently changing a generic website statement in a way that makes it unclear which commitment applied to an earlier product.
Put the rationale in technical documentation
Article 13 requires manufacturers to include in the technical documentation the information that was taken into account when determining the support period.
A useful record should let another reviewer reconstruct the decision. It can include:
- the exact product or variant covered;
- the support-period start and end;
- expected-use assumptions;
- reasonable user expectations considered;
- relevant product-lifetime legislation;
- comparable product data where used;
- operating-environment assumptions;
- third-party core-component support considered;
- sources and evidence;
- decision owner and review date; and
- triggers that require reassessment before a new product or variant is placed on the market.
This is an engineering governance recommendation, not a claim that the CRA prescribes those exact fields. The legal requirement is to retain the information considered in determining the period.
Third-party component support is a factor, not an excuse
Article 13 allows manufacturers to consider the support periods of integrated third-party components that provide core functions. That makes supplier and dependency lifetime a legitimate planning input.
It does not convert an upstream supplier's end-of-support date into the manufacturer's support period automatically.
If a core dependency ends support earlier than the expected use of the product, the manufacturer needs an engineering strategy: migrate to a supported component, maintain an appropriate fork, redesign the dependency, replace the component, provide another effective mitigation path, or change the product plan before market placement. The appropriate choice depends on the product and risk.
The important control is to identify lifecycle mismatches early. A ten-year product plan that depends on an irreplaceable component with two years of security maintenance is not merely a procurement detail; it is a product-security lifecycle risk.
A practical support-period workflow
A repeatable process can turn the legal criteria into an auditable lifecycle decision.
- Define the product boundary. Identify the product, variants, relevant software and hardware, remote processing and manufacturer entity.
- Estimate expected use. Use intended purpose, deployment context, replacement cycles, user expectations and applicable lifetime rules.
- Check the five-year floor. If expected use is five years or longer, the period cannot be shorter than five years; if expected use is shorter, document why.
- Test longer-lived scenarios. For products likely to remain deployed beyond five years, set a period that reflects that longer use.
- Review operating-environment dependencies. Check supported operating systems, runtime platforms and infrastructure needed to maintain the product.
- Review core third-party components. Compare their support horizons with the product commitment and resolve material gaps.
- Record the rationale. Put the evidence and factors considered into the technical documentation.
- Publish the end date consistently. Ensure user information states the support end clearly, including month and year.
- Resource vulnerability handling. Make sure ownership, engineering access, update distribution and evidence retention can continue for the full period.
- Track issued updates separately. Apply the independent 10-year-or-remainder availability rule to each security update.
This workflow should be completed before the product is placed on the market, because the support commitment affects product information, technical documentation, dependency choices and post-market responsibilities.
Common support-period mistakes
Several shortcuts create avoidable risk.
- Treating five years as the standard answer for every product. Long-lived products may require substantially longer support.
- Using a commercial maintenance term as expected-use evidence. Contract duration and actual product use are different questions.
- Ignoring installed products after sales stop. End of sales does not necessarily mean end of use.
- Letting a supplier's support date silently define the product commitment. Third-party support is one factor in the manufacturer's analysis.
- Publishing an end date without retaining the rationale. The technical documentation must contain the information used to determine the period.
- Mixing active support with update retention. Issued security updates have a separate availability rule.
- Using one date for materially different variants without analysis. Product architecture and expected use can differ.
- Promising a long period without preserving engineering capability. Vulnerability handling needs people, product context, build knowledge and distribution mechanisms for the full commitment.
Keep the support decision connected to lifecycle evidence
Support-period decisions become difficult to defend when product scope, expected-use assumptions, dependency lifetimes and vulnerability records are stored in unrelated systems. AA-sec is designed around traceability between exact product or lifecycle context, security evidence and decisions, which can help keep the support-period rationale connected to the records that support it. The manufacturer remains responsible for setting the support period and determining its legal obligations.
A readiness test before 2027
Select one product that is expected to remain in service for several years and reconstruct its support-period decision today.
Ask whether the team can show the expected-use evidence, the factors Article 13 requires it to consider, the third-party dependencies that influence maintainability, the published end date, the technical-documentation record and the operating capability for vulnerability handling through that date. Then identify every core dependency whose support ends earlier than the product commitment.
The gaps should become product-security backlog items: unclear expected-use assumptions, unsupported dependencies, inconsistent user information, missing ownership, unavailable historical build knowledge or no controlled record of why the period was chosen.
The practical standard is simple: the support period should be a product-lifecycle decision backed by evidence and a viable vulnerability-handling capability. Five years is the legal floor for products expected to remain in use at least that long, not a substitute for determining how long the product itself is reasonably expected to be used.
Official sources
- Regulation (EU) 2024/2847 — Cyber Resilience Act — EUR-Lex
- Cyber Resilience Act - Manufacturers — European Commission
- The Cyber Resilience Act - Summary of the legislative text — European Commission
- Commission publishes new guidance to support timely Cyber Resilience Act implementation — European Commission