Article 13(8) of the EU Cyber Resilience Act (Regulation (EU) 2024/2847) sets a five-year floor for vulnerability handling, anchored at the date the product is placed on the EU market. This guide covers the duration mechanics: when the clock starts, how the shorter-lifetime carve-out 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.
Summary
- Five years is the floor. Article 13(8) requires vulnerability handling for at least five years from the date the product is placed on the EU market.
- The shorter-lifetime carve-out is narrow. It must be assessed before market placement, documented in the Annex I Part I risk assessment, and disclosed to users in the Annex II information 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 stack overlapping windows. Each version has its own Article 13(8) clock; manufacturers can owe simultaneous support across three or more active versions.
- Upstream supplier risk is the manufacturer's risk. A component vendor's EOL is not a defence; supply contracts must cover the full Article 13(8) period.
The four numbers that define the CRA support period: the minimum duration, the cost obligation, the documentation retention floor, and the penalty ceiling.
Article 13(8) anchors the five-year period to the date the product is placed on the EU market, the first time it is made available to any distribution or sales channel. A unit that sits in a warehouse for 18 months before a customer buys it has already consumed 18 months of its support period. This creates inventory risk: manufacturers who do not track market placement dates by product version cannot prove compliance with Article 13(8).
What the CRA requires for the support period
Article 13(8) of the Cyber Resilience Act states that the manufacturer "shall ensure that vulnerabilities of the product with digital elements are handled effectively for a period of at least five years from the date the product with digital elements is placed on the market, or for the expected product-in-use period, whichever is the shorter."
The obligation has three components:
At least five years. The "expected product-in-use period if shorter" carve-out is narrow and must be documented and disclosed before purchase. A manufacturer cannot invoke it retrospectively. If the documentation states five years, the manufacturer owes five years.
Vulnerabilities must be handled "effectively" per Annex I Part II: identify and document them, fix without undue delay, disclose once addressed, and operate a coordinated disclosure policy. Not just shipping patches, the whole vulnerability lifecycle.
Security updates must be provided free to users. Feature updates and paid support tiers are separate. Bundling fixes inside a paid subscription does not satisfy Article 13(8). See security updates for delivery mechanics.
When the Five-Year Clock Starts
Article 13(8) anchors the support period to the date the product is "placed on the market." Under EU product law, market placement is the first time the product is made available to any party in the distribution chain, not the retail sale to the end customer.
Clock starts: The date the manufacturer (or an authorised representative) first makes the product available to a distributor, retailer, or importer for the purpose of distribution in the EU.
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 manufacturer's obligation to patch v1.0 ceases. The customer continues using the product at their own risk.
Best practice: Track market placement dates per product version, not per individual unit. A single placement-date record per SKU is sufficient for Article 13(8) purposes.
The Shorter Expected Lifetime Carve-Out
Article 13(8) allows the support period to be shorter than five years if the expected product-in-use period is shorter. This carve-out is narrower than it appears:
- "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 product's risk assessment (Annex I Part I) and disclosed to users in the Annex II product information before purchase.
- 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, each with its own Article 13(8) support period.
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 owes security updates to all three versions simultaneously. 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.
Supplier and Upstream Contract Obligations
Article 13(8) places the support period obligation on the manufacturer. A manufacturer who cannot patch their product because a component vendor has discontinued support is still in breach of Article 13(8). The upstream contract gap is not a defence.
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 who trigger Article 22 role escalation (by rebranding or substantially modifying a product) inherit the full Article 13(8) obligation including the upstream contract risk. See the importer obligations guide for the Article 22 decision flow.
End-of-Life Planning and Responsible Product Transitions
When the Article 13(8) support period ends, the manufacturer's obligation to patch vulnerabilities ceases, but a set of responsibilities remains.
What Article 13(8) and related provisions require at end-of-support:
- The Annex II support period end date, disclosed pre-purchase, stands as the commitment. Users must have received adequate notice in advance.
- The technical file must be retained for at least 10 years from the date the product was placed on the EU market (Article 31), regardless of when support ends.
- The EU Declaration of Conformity must remain accessible to market surveillance authorities.
- If the manufacturer becomes aware of a critical, actively-exploited vulnerability in the unsupported product affecting a significant installed base, there is no mandatory Article 14 reporting duty post-EOL. Responsible disclosure and user notification are strongly recommended. See vulnerability reporting for the Article 14 timeline mechanics that apply during the support period.
Communication obligations at end-of-support:
The CRA does not specify a statutory notice period for end-of-support. The Annex II requirement to disclose the support period end date pre-purchase means that users who purchased the product after the Annex II disclosure was in place were already on notice. For products where the original Annex II disclosure was absent or unclear, 12 months' advance notice is the industry-standard minimum.
Post-EOL: the manufacturer is not required to patch new vulnerabilities but should maintain a security contact for responsible vulnerability disclosure, keep product documentation accessible, and cooperate with any market surveillance authority investigation under Article 58.
For the full end-of-life operational playbook, covering notification templates, migration frameworks, acquired-product scenarios, and the 18-month planning timeline, see CRA End-of-Life Planning: Responsible Product Transitions.
Common Mistakes
Not tracking market placement dates. Without a per-version placement date record, the manufacturer cannot calculate when Article 13(8) obligations start or end, cannot produce the Annex II support period 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 Article 13(8) 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. Article 13(8) requires fixes to be delivered without undue delay. A six-month release cycle is not "without undue delay" for a critical vulnerability.
Frequently Asked Questions
When does the five-year support period start?
Article 13(8) anchors the support period to the date the product is placed on the EU market: the first time the manufacturer makes the product available to any party in the distribution chain for the purpose of EU distribution. It does not start at the customer's purchase date, at activation, or at the date a specific unit ships. A product placed on the market in January 2028 owes security updates until at least January 2033, regardless of when any individual customer buys it.
Can the support period be shorter than five years?
Yes, under the Article 13(8) carve-out, if the expected product-in-use period is shorter than five years. However, the shorter period must be determined before market placement, documented in the risk assessment (Annex I Part I), and disclosed to users in the Annex II product information before they purchase. A manufacturer cannot invoke the carve-out after a vulnerability is discovered, and the assessment must reflect reasonable user expectations, not internal cost preferences. For most IoT devices, connected hardware, and software products, five years is the practical minimum.
Does Article 14 reporting apply after the support period ends?
No. Article 14 reporting obligations (the 24-hour early warning, 72-hour notification, and 14-day final report for actively exploited vulnerabilities) apply to the manufacturer during the support period. Once the Article 13(8) support period lapses, the manufacturer has no mandatory Article 14 reporting duty for vulnerabilities discovered in that product version. Market surveillance authorities retain the power to investigate under Article 58 if an unsupported product presents a significant cybersecurity risk, but the ongoing vulnerability-management and reporting obligations under Articles 13 and 14 have ended.
What if an upstream component vendor ends support before our Article 13(8) period?
Article 13(8) places the obligation on the manufacturer, not on upstream vendors. If a chipset, operating system, or middleware vendor ends support for a component before the manufacturer's five-year period expires, the manufacturer must either maintain patches independently, source an alternative supported component, or withdraw the product from the EU market. An upstream vendor's EOL decision is not a defence against a market surveillance authority's finding of Article 13(8) non-compliance. Supply contracts negotiated at product design time should specify the upstream patch commitment period, access to source code or patch tooling, and notification obligations, verified against the product's expected support period before market placement.