Five years is a tempting answer. It fits neatly into a roadmap and looks like a rule you can copy. But if customers expect to run your device for ten years, a five-year support promise needs another look. Start with the life of the product in the customer’s hands.
Leave with a decision
Set a support end date with the reasoning attached
- 1Collect evidence of how long the product will actually be used.
- 2Check whether you can maintain its core components for that period.
- 3Record the decision and give unresolved gaps an owner.
First, separate this decision from the September reporting deadline
This is preparation for the CRA’s main application date, 11 December 2027. The Article 14 reporting duties start earlier, on 11 September 2026. Choosing a support period does not postpone those reporting duties.
Article 13(8) ties support to expected use. It sets a five-year minimum unless the product is expected to be used for less than five years, in which case support must cover that expected use. Longer-lived products can need longer support. A warranty expiry or an internal budget cycle does not, by itself, establish the right period.
Build the decision from evidence you already have
Ask product management and engineering for the evidence behind the expected service life. Sales material is useful too: a promise about long-term industrial use is awkward to reconcile with a short security-support window.
Put the following in a short decision note. Mark missing evidence as missing; do not turn an optimistic answer from a supplier into a confirmed commitment.
- Product and release: exactly what is being supplied, and which market-placement dates the decision covers.
- Expected use: customer contracts, replacement cycles, field experience or another stated basis for the duration.
- Core dependencies: operating system, firmware and third-party components, with their known support commitments.
- Delivery: who can build, test and distribute fixes throughout the proposed period.
- Owner and review trigger: who resolves a gap, and which supplier or product change requires another assessment.
A supplier’s earlier end date is a gap to resolve
Consider a hypothetical industrial gateway. Customers plan to use it for eight years. Its core operating-system supplier currently offers five years of support. The team has three years of maintenance to account for before it can rely on that eight-year plan.
Possible responses include extending the supplier arrangement, maintaining the component internally or replacing it. Each needs evidence that the organisation can actually carry it out. Simply shortening the product’s support period to match the supplier avoids the difficult part of the decision.
For a unit first placed on the market on 1 March 2028, an accepted eight-year support period would run to 1 March 2036. That is illustrative date arithmetic, not a finding that eight years is legally sufficient for this gateway. Later units need their own placement dates accounted for; do not copy the same endpoint across a continuing sales run without checking the period they receive.
Keep three dates separate
The decision should distinguish the support end date, the next internal review date and how long already-issued security updates remain available. They answer different questions.
Under Article 13(9), an issued security update must remain available for at least ten years after issue or for the rest of the support period, whichever is longer. Keeping a download online is different from continuing to develop fixes. Article 13(19) also requires the support endpoint, including at least month and year, to be clear at purchase.
Record a conclusion, or record what prevents one
In CRA Operations, add the product and open Assessments → Support period and vulnerability handling. Use the evidence gathered above, submit the assessment and check the resulting ProseID Record. It preserves the supplied answers and the published rule version used.
If the date is justified, put it on the product and retain the supporting decision. If a dependency is unresolved, leave the product’s support date unset and create a task with an owner and due date. “Waiting for a supplier commitment” is a useful result when it stops an unsupported promise from reaching customers.
This article explains an operational approach to CRA preparation. It does not replace the Regulation, official guidance or advice for a specific product and organisation.
Not lawyer-reviewed.