CRA Support Period for Hardware and How to Document Your Decision
Document a defensible CRA support period using expected product use, dependencies and an explicit customer support end date.
By Cenitia
The CRA support period is a documented decision about how long the manufacturer will handle vulnerabilities for the product. “Five years” is not a universal shortcut: the decision must reflect the expected period of use and the criteria in Article 13(8).
Use the support decision record to separate the legal assessment, engineering capability and customer communication. This article concerns cybersecurity support; it does not define every warranty, cloud subscription or spare parts obligation.
Begin with expected use
Describe who buys the product, where it is installed and what replacement normally requires. A portable accessory and an embedded building controller may have very different expected use. Record evidence such as contractual expectations, repair arrangements, known deployment lifetimes and comparable product behaviour.
Then identify the support period under CRA Article 13(8). The Commission's July 2026 guidance explains the minimum of five years unless the expected use is shorter, while a longer expected use can require a longer period. A manufacturer needs a justified decision rather than a default copied from another product. See guidance section 5, paragraphs 125–131.
Distinguish facts from estimates. “Our oldest installed unit has operated for seven years” needs an actual service record. In the absence of that evidence, write “planning assumption: seven year deployment” and explain how it will be checked.
Map the dependencies that make support possible
List the operating system branch, bootloader, radio firmware, cryptographic libraries, signing infrastructure and remotely required services. For each, identify upstream maintenance dates, your own patch capability and the fallback plan.
An upstream end of maintenance is a constraint to address, not automatic permission to stop supporting your product on that date. Possible responses include a supported branch migration, a maintained fork, a vendor agreement or a product redesign. Each has cost and validation consequences.
Ask engineering a concrete question: if the supplier disappears, can we rebuild and sign an update for the installed product? Retaining a source archive is insufficient if the build toolchain, keys or deployment path are unavailable.
A fictional decision record
Assume a manufacturer sells a gateway intended to stay inside an industrial cabinet for eight years. Its current Linux branch is maintained upstream for less than that period.
| Decision input | Model observation | Action to resolve it |
|---|---|---|
| Expected use | Eight years is the design assumption | Check contracts, installation constraints and customer evidence |
| Software maintenance | Current branch does not cover the full assumption | Cost and test a migration or extended maintenance arrangement |
| Update access | Some installations are offline | Define an authenticated offline update method |
| Support end communication | A vague “long term support” claim is proposed | Replace it with an approved explicit end date |
This is not a recommendation that eight years suits every gateway. It demonstrates how a support decision exposes engineering work rather than concealing it behind a marketing phrase.
Decide how releases relate to support
Document which firmware branches are maintained and how customers obtain fixes. If you plan to support only a later software version, obtain specific review of the conditions in Article 13(10). Do not assume you can require any upgrade, new hardware or paid subscription as the route to a security fix.
Track the relationship between the product's support period and the continued availability of issued security updates. These are related but distinct obligations; review the applicable Article 13 provisions rather than using one date for every retention and availability rule.
Make the customer statement precise
Article 13(19) addresses providing the support end date at purchase, including at least month and year. A useful statement names the product or covered version and explains how to obtain updates. See the CRA text.
A model statement is: “Cybersecurity support for [identified product] is provided until [month/year]. Update instructions and supported versions are available at [maintained URL].” It is intentionally incomplete. The manufacturer must supply the real date, scope and channel and review other customer rights separately.
Maintain the decision after launch
Assign an owner for dependency changes, significant product modifications and customer communication. Store the rationale, evidence references and approval with the technical documentation. Reassess the plan when the facts change; do not rewrite the recorded original rationale as though the new facts were always known.
A planning estimate of lifetime is not evidence of your product's actual support capability.
CRA applicability and timing
Most CRA product obligations apply from 11 December 2027; manufacturer Article 14 reporting applies from 11 September 2026. Check the product scope, role and specific transitional provisions before treating a future requirement as a current duty. See the Commission manufacturer guidance and reporting guidance.
Continue reading
Related guides
tutorial
Coordinated Vulnerability Disclosure Policy for Hardware Manufacturers
Build a usable hardware vulnerability disclosure policy with intake owners, safe testing boundaries and a security.txt example.
4 min read
reference
CRA for existing products already on the EU market: the Article 69 transitional rules
CRA Article 69 explained: grandfathering for products placed on the EU market before 11 December 2027, substantial modification test, Article 14 reporting carve-back.
14 min read
comparison
ISO/IEC 27001 vs CRA — when to certify both
ISO/IEC 27001:2022 is an organisational ISMS standard; the EU Cyber Resilience Act is a product-level regulation. Where they overlap, where they don't, and why you need both.
9 min read
tutorial
CRA December 2027 readiness — scope, assessment and evidence checks
Key checks before CRA main product obligations apply: legacy products and modifications, support and retention, assessment route, declaration and technical evidence.
3 min read
Put this into practice
Free tools & references
- CRA Readiness CheckerScore your product against the Cyber Resilience Act essential requirements.Open tool →
- EU Directive SelectorDescribe your product and find which EU directives and regulations apply.Open tool →
New to the terminology? Browse the compliance glossary — plain-English, citation-backed definitions of every term above.