The CRA Support Period: It's Not a Flat Five Years
Ask most product teams what the CRA says about security updates and you'll hear some version of "five years." That's not wrong - but it's incomplete in a way that could leave you under-committed, over-committed, or simply unable to justify your number to a market surveillance authority.
The actual rule is more nuanced, and getting it right matters: the support period you declare shapes your update infrastructure, your end-of-life planning, your point-of-sale disclosures, and your conformity assessment. Here's what the regulation actually says, what the draft Commission guidance adds, and what you should do before December 2027.
This article is general guidance on the Cyber Resilience Act, not legal advice. Confirm specifics against the official sources below or with a qualified adviser.
Key points
- Five years is a floor, not a default. The support period must match the expected product lifetime - five years is the minimum unless the product is genuinely expected to be used for less.
- The clock starts at market placement, not at the customer's purchase date.
- Security updates must be free of charge and delivered without undue delay for the entire support period.
- Each update you issue must remain available for at least 10 years from the date it was issued, or for the remainder of the support period - whichever is longer.
- You must declare the support period at the point of sale. It is part of your Article 13 risk assessment, not a marketing decision.
- Draft Commission guidance published 3 March 2026 addresses support periods specifically. The consultation closed 31 March 2026; the final version is still pending. Some details may firm up.
What the regulation actually says
Regulation (EU) 2024/2847 - the Cyber Resilience Act - applies in full from 11 December 2027. Article 13 is where the support period obligation lives.
The core rule, in plain English: manufacturers must provide security updates for a period commensurate with the expected product lifetime, and that period must be at least five years - unless the product is expected to be in use for a shorter time, in which case the support period matches that shorter expected lifetime.
Article 13(8) requires you to issue security updates for a minimum of five years from the date of placing the product on the market, or the expected product lifetime if shorter. Five years is the floor, not the default - a product with a 10-year expected lifetime needs a 10-year support commitment.
The five-year exception is narrow. 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.
Recital 60 of the regulation gives concrete examples of when a shorter period might apply - a contact-tracing app tied to a specific public-health emergency, or software sold on a subscription basis where the support period ends when the subscription ends. In most cases, the support period will be longer than five years. Recital 60 explicitly lists PCBs, microprocessors, modems, routers, switches, operating systems and video editors as product types where longer lifetimes are the norm.
Recital 60 also emphasises that "products used in industrial settings" have lifetimes much longer than five years - agricultural machines, for example, are often in use for 15-20 years.
When does the clock start?
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. Track placement dates per product version, not per individual unit.
The 10-year update availability rule
There are two separate obligations here, and conflating them is a common mistake.
The CRA imposes two distinct obligations on security updates. Article 13(8) governs how long you must issue updates. Article 13(9) governs how long each issued update must remain available for download - a minimum of 10 years from the issuance date, or the remainder of the support period, whichever is longer. These are independent obligations: an update issued in year four of a five-year support period must remain downloadable until year 14 from issuance.
Plan your update hosting now. A security patch you ship in 2029 may need to remain downloadable until 2039 or beyond. That means durable, versioned storage — not a CDN path that gets cleaned up when you ship the next major release. Factor this into your infrastructure design before December 2027.
What "free of charge" and "without undue delay" actually require
Annex I, Part II, point (8) of the CRA requires that where security updates are available to address identified security issues, they are disseminated without delay and, unless otherwise agreed between a manufacturer and a business user in relation to a tailor-made product, free of charge, accompanied by advisory messages providing users with the relevant information, including on potential action to be taken.
On timing: the CRA text doesn't specify a hard SLA, but ENISA guidance suggests that "without undue delay" for critical and actively exploited vulnerabilities means days to weeks, not months. Market surveillance authorities will look at your patch timeline relative to the vulnerability severity.
On separating security from feature updates: Annex I, Part II, point (2) requires that where technically feasible, new security updates shall be provided separately from functionality updates. The intent is to ensure that users are not required to install new functionality updates for the sole purpose of receiving the latest security updates.
This has real engineering implications. If your update pipeline bundles security fixes into feature releases, you may need to rearchitect it before full application in December 2027.
The multi-version question
What if you ship v2.0 and want to stop patching v1.0? The draft Commission guidance clarifies the Article 13(10) path: manufacturers can stop patching older versions if users can upgrade free of charge to a supported version. "Additional costs" in this context means mandatory hardware purchases; routine testing, reconfiguration, or deployment effort on the user's part does not qualify.
In other words, "free upgrade" means genuinely free - not just free of licence cost if the user still has to buy new hardware to run it.
What the draft Commission guidance adds (and what's still unsettled)
As the first operational milestones under the CRA draw closer, the European Commission issued draft guidance to support economic operators and market surveillance authorities in applying the Regulation. Published on 3 March 2026, the draft is meant to clarify how some of the CRA's most consequential provisions should work in practice.
The draft guidance focuses specifically on remote data processing solutions and free and open-source software, the notion of "support periods," as well as the interplay between the CRA and other EU legislation.
The Commission opened the draft for public consultation on 3 March 2026 and invited feedback until 31 March 2026. The consultation closed on 31 March 2026. The European Commission will now review stakeholder feedback and is expected to publish the final version of the guidance in due course.
Even once finalised, the document will remain non-binding; only the CJEU can provide an authoritative interpretation of the CRA.
What this means for you: The five-year floor, the lifetime rule, the free-and-prompt requirement, and the 10-year availability obligation are all settled law - they are in the regulation text itself. The draft guidance adds practical context and examples, but some specifics may shift before the final version is published. Plan against the regulation text; watch the guidance for clarification.
How to determine and justify your support period
The support period is not a marketing decision. It is part of the Article 13 risk assessment - a documented, reasoned conclusion about how long your product will realistically be in use.
Look at your product category, your customer base, and comparable products on the market. Ask: how long do users typically keep and run this type of product? Consider third-party component lifetimes (SoCs, operating systems, libraries) — your support period cannot meaningfully exceed the support windows of the components you depend on.
Record the factors you considered and the conclusion you reached in your technical documentation. If you are claiming a period shorter than five years, the justification must be robust — the exception is narrow. If you are claiming longer than five years, document why (industrial use, long replacement cycles, regulatory requirements in your sector).
The CRA requires the support period to be clearly communicated to users before purchase. This means it must appear in product listings, packaging, or accompanying documentation — not buried in a EULA. Treat it like a product specification.
Set up a pipeline that can deliver security-only updates separately from feature releases, free of charge, for the full support period. Plan durable, versioned storage for issued updates — each one must remain available for at least 10 years from issuance.
The draft guidance published 3 March 2026 addresses support periods directly. The final version will likely become a key reference for market surveillance authorities. Track it at /deadlines or /checklist.
A support period decision tool
Use this tool to estimate the right support period for your product and check what your update availability obligations look like over time.
Common misconceptions, corrected
| Misconception | What the CRA actually says |
|---|---|
| "Five years from purchase" | Five years (minimum) from market placement |
| "Five years is the standard" | Five years is the floor - lifetime governs if longer |
| "We can charge for security updates" | Updates must be free of charge (except agreed B2B tailor-made products) |
| "We can bundle security fixes into feature releases" | Where technically feasible, security updates must be separable |
| "Once we ship a patch, we're done" | Each patch must remain available for download for 10 years from issuance |
| "We can stop patching v1.0 when v2.0 ships" | Only if users can upgrade to v2.0 free of charge and without hardware costs |
Where to go next on CRA Facts
- Read Security by Design Under the CRA: What Annex I, Part I Actually Requires for the broader vulnerability-handling picture.
- Use the SBOM starter guide - your SBOM is the foundation for tracking which components constrain your support period.
- See every confirmed date on the CRA deadlines & timeline page.
- Check the CRA compliance checklist and watch it for updates as the final Commission guidance is published.
The final Commission guidance on support periods is still pending. Subscribe to The CRA Brief to get a plain-English summary the week it drops — along with updates on harmonised standards and other CRA developments.
Sources: Regulation (EU) 2024/2847 (EUR-Lex) · European Commission - CRA legislative summary · European Commission - draft guidance for feedback, 3 March 2026
Related reading
CRA vs NIS2: Which EU Cyber Rule Applies to Your Software - and Is SaaS in or Out?
The CRA covers products placed on the market; NIS2 covers organisations operating essential services. Pure SaaS is generally out of CRA scope - but the line is not always clean.
Article 13 CRA Risk Assessment: The Document That Holds Everything Together
Article 13 of the Cyber Resilience Act requires a documented cybersecurity risk assessment before CE marking. Here's what it must cover, why it's load-bearing, and how to build one.
How to Build a CRA-Compliant Coordinated Vulnerability Disclosure Policy
The CRA requires a CVD policy and a reachable contact point. Here's exactly what to put in it - and how it differs from the mandatory 24h/72h ENISA reporting clock.