Express + expert help

View pricing →
Skip to main content
guideCRA4 min read

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 inputModel observationAction to resolve it
Expected useEight years is the design assumptionCheck contracts, installation constraints and customer evidence
Software maintenanceCurrent branch does not cover the full assumptionCost and test a migration or extended maintenance arrangement
Update accessSome installations are offlineDefine an authenticated offline update method
Support end communicationA vague “long term support” claim is proposedReplace 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

Put this into practice

Free tools & references

New to the terminology? Browse the compliance glossary — plain-English, citation-backed definitions of every term above.