The CRA support period: how long, how to decide and what to publish
The support period is the time during which a manufacturer must handle vulnerabilities and provide security updates for a product with digital elements. Under Article 13(8) it must reflect the expected time in use and be at least five years, unless the product is expected to be in use for less; it is documented with rationale and stated to users.
By the Vellaci teamPublished Updated 4 min readOperational guidance, not legal advice
Key facts
- Legal basis
- Art. 13(8)–(9); Annex II user information; Annex VII documentation
- Minimum
- 5 years, unless the product is expected to be in use for less
- Determined by
- Expected use time, user expectations, nature of the product, relevant Union law, similar products, authority guidance
- Security updates
- Available for at least 10 years after issue, or the remainder of the support period, whichever is longer
- Communication
- Support period end date in the user information at purchase
What the regulation asks
Article 13(8) requires manufacturers to ensure that vulnerabilities are handled effectively and in accordance with Annex I Part II during a support period that reflects the length of time the product is expected to be in use. In determining it, manufacturers take into account user expectations, the nature of the product and its intended purpose, relevant Union law, support periods of similar products, and guidance from the ADCO group of market surveillance authorities. The support period must be at least five years; where the product is expected to be in use for less than five years, it corresponds to the expected use time. Article 13(9) adds that each security update, once issued, remains available for at least ten years after placing on the market or for the remainder of the support period, whichever is longer.
Deciding the period
Start from how long customers actually keep the product in service, not from how long you would like to sell updates. Evidence: warranty terms, fleet telemetry, replacement cycles in the sector, contractual maintenance commitments, and what competitors publish. Then check the floor (five years) and any sector expectation (industrial equipment and network infrastructure routinely run for ten to fifteen years; consumer software much less). Document the reasoning — the ADCO group may publish guidance per category, and authorities can ask why you chose less than they consider appropriate.
| Product type | Typical expected use | Practical support period |
|---|---|---|
| Consumer mobile app | 2–4 years | 5 years (floor applies) |
| Home router / gateway | 6–8 years | 7–10 years |
| Industrial controller / OT device | 10–20 years | 10–15 years, with paid extension options |
| Enterprise on-premises software | 5–10 years | Aligned with published lifecycle policy, ≥ 5 years |
| Smart meter gateway | 15+ years | Sector-specific, often mandated |
What to publish and where
Annex II requires the information and instructions to the user to state, among other things, the end date of the support period — at least the month and year — and that it be available at the time of purchase, in a clear and understandable form, and on the manufacturer's website for at least ten years. Put the date on the product page, in the documentation and in the sales channel; keep a per-product, per-version lifecycle page current.
Operating the support period
- Record start date, end date, expected lifetime and rationale per product; record the approver.
- Alert internally well before end of support (12 and 6 months) so extensions, migrations or end-of-life communications are planned.
- Keep vulnerability handling running for every supported version — the duty is per product in the field, not per latest release.
- Keep issued security updates downloadable for ten years or the rest of the support period.
- At end of support, communicate clearly, provide the last security state, and keep the technical documentation for ten years.
Support period and the SBOM
The support period is also a promise about every component inside the product. A five-year commitment on a device whose Linux kernel line reaches end of life in two years means either a planned migration or a paid extended-maintenance contract with the upstream vendor. Use the SBOM to list components with their own end-of-life dates, compare them with the declared support period, and treat every gap as a documented risk with an owner. Vellaci surfaces component end-of-life data next to the product's support period so the comparison is a view, not a spreadsheet exercise.
Common mistakes
- Confusing the sales period or the warranty with the support period.
- Publishing a period shorter than expected use because engineering capacity is tight — the regulation points the other way.
- Setting one period for the whole portfolio when hardware generations differ.
- Ending updates for older versions while they are still within the support period.
Frequently asked questions
- Can we charge for support beyond the period?
- Security updates during the support period must be free of charge. Paid extended support beyond the declared period is a commercial matter, provided the declared period itself meets the legal test.
- Does the support period apply to each version or the product?
- To the product with digital elements as placed on the market. In practice manufacturers define it per product line and hardware generation and keep every version placed on the market within it supported, which is why version-level SBOMs and vulnerability matching matter.
- What if a component vendor ends support earlier?
- Your obligation to users is unchanged. Plan component lifecycles against your support period, keep alternatives ready, and treat an upstream end-of-life as a risk to document and mitigate.