The EU Cyber Resilience Act makes support-period planning a product-launch decision, not an afterthought. A manufacturer must decide how long users can expect vulnerabilities to be handled, publish the support end date at purchase, and keep security updates available for the required period. This guide covers the duration mechanics: when the clock starts, how the shorter expected-use exception works, how multi-version portfolios stack, and what upstream supply contracts must cover. For delivery cadence see CRA security updates. For the user-facing support period end date see end-of-support disclosure. For the parent overview see CRA support period.
Summary
- Five years is the floor. The CRA requires vulnerability handling for at least five years unless the product is expected to be used for a shorter time.
- The shorter expected-use exception is narrow. It must be assessed before market placement, documented in the technical documentation, and disclosed to users before purchase.
- The clock starts at market placement, not at customer purchase. Inventory that sits in a warehouse before sale has already consumed part of the support window.
- Multi-version portfolios can stack overlapping windows. A limited software route allows latest-version-only remediation, but only if previous-version users can move free of charge and without environment costs.
- Upstream supplier risk is the manufacturer's risk. A component vendor's EOL is not a defence; supply contracts must cover the full support period.
The four signals that define support-period planning: minimum duration, update cost, documentation retention, and penalty exposure.
What the CRA requires for the support period
A support period is the window during which the manufacturer must keep the product's vulnerability-handling process alive. It covers the product and its components, starts from EU market placement, and must be long enough to match how users can reasonably expect the product to be used. The manufacturer should set it from practical evidence: product type, intended purpose, comparable products, relevant Union lifetime rules, operating-environment availability, core third-party component support, and ADCO or Commission guidance. The practical result is simple: support planning has to be set before launch and kept alive across the declared support window.
The obligation has three components:
| Component | Operational rule | Evidence to keep |
|---|---|---|
| DurationHow long support lasts | Use at least five years unless the expected product-in-use period is shorter. | Support-period rationale in the technical documentation and a clear support end date at purchase. |
| HandlingWhat must stay active | Keep the vulnerability lifecycle running: document findings, remediate without delay, disclose fixed issues, operate CVD, and distribute updates securely. | Vulnerability records, remediation timestamps, CVD policy, update-distribution evidence, and user advisories. |
| Security updatesCost and availability | Disseminate available security updates without delay and free of charge, except for the narrow tailor-made business-product exception. | Release records showing when fixes were made available and that basic security fixes were not placed behind paid tiers. |
When the five-year clock starts
The support clock starts when the product enters the EU market, not when the end customer buys it. In EU product-law terms, that is the first making available of the product on the Union market for distribution or use. For support planning, the market-placement date is the date that matters.
Clock starts: The date the product is first made available to a distributor, retailer, importer, or user for distribution or use on the EU market.
Clock does not start at: customer purchase, customer activation, shipment of a specific unit, or the date a customer installs the product.
Practical example:
- January 2028. Product v1.0 placed on the EU market. The five-year support period begins. The manufacturer owes security updates until at least January 2033.
- June 2029. A customer purchases v1.0 from a retailer. The customer has approximately 3.5 years of support remaining, not five years from purchase.
- January 2033. Support period ends. The baseline vulnerability-handling commitment for v1.0 ends. Further user notifications or regulatory engagement depend on the facts.
Best practice: Track market placement dates per product version, not per individual unit. A single placement-date record per SKU is usually the practical evidence base for calculating support end dates.
The shorter expected-use exception
The five-year floor can be shortened only when the product is genuinely expected to be used for less than five years. That exception is narrower than it appears and comes from the support-period rule:
- "Expected product-in-use period" is assessed from the perspective of reasonable user expectations based on the nature of the product, how similar products are typically used, and what the manufacturer communicates.
- The shorter period must be documented in the technical documentation and disclosed to users at purchase, including at least the month and year of the support end date.
- A manufacturer cannot invoke the carve-out after a vulnerability is discovered. The assessment must be made before market placement and recorded in the technical file.
- For most software products, IoT devices, and connected hardware, five years is the practical minimum. The carve-out applies to products with an objectively short useful life, such as single-use or limited-cycle hardware, rather than products where the manufacturer simply prefers a shorter obligation.
Multi-version support
Most manufacturers have multiple product versions on the market simultaneously. Hardware products and independently maintained software versions can create overlapping support windows. Software products also have a limited latest-version-only route for later substantially modified versions, but only if users of previous versions can move to the latest version free of charge and without additional hardware or software-environment costs.
Staggered support periods create overlapping obligations:
| Version | Market placement | Support ends (5y) |
|---|---|---|
| v1.0 | Jan 2028 | Jan 2033 |
| v1.1 | Jul 2028 | Jul 2033 |
| v2.0 | Jan 2029 | Jan 2034 |
From January 2029 to January 2033 (four years), the manufacturer may owe security updates to all three versions simultaneously unless an eligible latest-version-only software route applies. Each version has its own CVE exposure, its own dependency tree, and potentially its own customer base. Patch backporting across major versions is technically complex and expensive.
Strategies for reducing multi-version burden:
- Shared codebase. Where possible, maintain a single security-patched core that all versions build on. Security fixes applied once propagate to all versions.
- Aggressive migration incentives. Shorter gaps between customers on old versions reduce the active support matrix. Upgrade pricing, free migration tooling, and support credits accelerate version consolidation.
- Explicit version EOL schedule. Publish the support end date for each version at market placement. Customers who know v1.0 ends in January 2033 have time to plan migration without emergency pressure.
- Latest-version-only route for eligible software. If using the latest-version-only route, document how previous-version users receive the latest version free of charge and without environment adjustment costs.
Supplier and upstream contract obligations
The manufacturer owns the support-period obligation even when a vulnerability comes from an upstream component. If the product cannot be patched because a component vendor has discontinued support, the manufacturer still needs a remediation path. The upstream contract gap is not a defence under the support-period rule.
What this means in practice:
- If a product includes a third-party operating system, middleware, or chipset firmware, the manufacturer must secure a supply agreement that covers the full support period. An upstream vendor who provides security patches for three years forces the manufacturer to either maintain the patches themselves after year three or stop placing the product on the EU market after the upstream EOL.
- SBOM-based dependency tracking (see the SBOM cluster guide) is the operational mechanism: the manufacturer cannot monitor upstream vulnerabilities without knowing what is in the product.
- Supply contracts should specify: upstream patch commitment duration, notification obligations for newly discovered vulnerabilities, access to source code or patch tooling if the upstream vendor discontinues the component, and indemnification terms for vulnerabilities originating in upstream components.
Importers and distributors who place a product on the market under their own name or trademark, or substantially modify a product already placed on the market, are treated as manufacturers and inherit the manufacturer obligations, including upstream contract risk. See the importer obligations guide for the role-escalation decision flow.
End-of-life planning and responsible product transitions
When the support period ends, the baseline vulnerability-handling commitment for that product version ends, but a set of responsibilities remains.
What remains at end-of-support:
- The support period end date disclosed at purchase stands as the user-facing commitment.
- The technical documentation and EU Declaration of Conformity must be retained for at least 10 years from market placement or for the support period, whichever is longer.
- Information and instructions to users must remain available to users and market surveillance authorities on the same 10-year-or-support-period basis, whatever the delivery channel; where they are provided online, they must also stay accessible online for that period.
- Where it is technically feasible for the product, the manufacturer should display a notification telling users that the product has reached the end of its support period.
- Unsupported-product vulnerabilities still require careful handling. The CRA does not give a blanket safe-harbour sentence for every incident-reporting question at EOL, and market surveillance authorities can still act where a product presents significant cybersecurity risk. Penalty exposure is covered in the penalties and enforcement guide; support expiry is not a blanket shield if the product presents significant cybersecurity risk.
Communication obligations at end-of-support:
The CRA does not specify a statutory notice period for end-of-support. The purchase-time disclosure of the support period end date means that users who purchased the product after the disclosure was in place were already on notice. For products where the original disclosure was absent or unclear, advance notice is an operational risk control rather than a CRA-numbered deadline.
Post-EOL: the manufacturer should maintain a security contact for responsible vulnerability disclosure, keep product documentation accessible, and cooperate with any market surveillance authority investigation.
Common mistakes
-
Not tracking market placement dates. Without a per-version placement date record, the manufacturer cannot calculate when support obligations start or end, cannot produce the user-facing support end date, and cannot demonstrate compliance to market surveillance authorities.
-
Failing to plan for upstream EOL. If a chipset, OS, or middleware vendor ends support before the manufacturer's support period expires, the manufacturer must have a plan. Reactive discovery of upstream EOL with no supply agreement in place is a common and expensive failure mode.
-
Coupling security patches to feature releases. Bundling security fixes into major version upgrades forces customers to accept new features and new risk surface to receive a security fix. Security fixes should be delivered as security fixes, without forcing paid tiers or major feature upgrades.
Frequently asked questions
When does the five-year support period start?
It starts when the product is placed on the EU market, not when a customer buys or activates it. Market placement is the first making available of the product on the Union market, so warehouse or distributor time can consume part of the support window. A product placed on the market in January 2028 normally needs vulnerability handling until at least January 2033, even if an individual customer buys it later.
Can the support period be shorter than five years?
Yes, but only where the product is expected to be in use for less than five years. The support period must reflect reasonable user expectations, product nature and intended purpose, relevant Union law, comparable products, operating-environment availability, core third-party component support, and ADCO or Commission guidance. The information used to determine it belongs in the technical documentation, and the end date must be clear at purchase.
Does reporting apply after the support period ends?
Do not treat support expiry as a blanket safe harbour for incident reporting. The support-period rule defines the vulnerability-handling window, while the incident-reporting duty separately requires notification of actively exploited vulnerabilities and severe incidents that the manufacturer becomes aware of. For an unsupported product, document the legal determination before deciding not to report, and still consider user notice where risk is material.
What if an upstream component vendor ends support early?
The manufacturer still owns the support-period obligation. The support-period rule covers vulnerabilities in the product and its components, and the component due-diligence rule requires care when integrating third-party components. If a chipset, operating system, middleware, or library vendor exits early, the manufacturer needs another route: maintain patches, replace the component, or stop placing the affected configuration on the EU market.