Under the EU CRA, how do you decide the support period you declare for a product?

## What the regulation actually fixes The CRA turns support into a declared, enforceable commitment rather than a marketing footnote: - The **support period reflects the expected product lifetime**, and is **at least five years** unless the product is expected to be in use for less. - It must be **communicated clearly to the buyer at the point of purchase**, so it becomes a contractual and competitive fact. - Throughout it, the manufacturer must handle vulnerabilities effectively, provide **security updates free of charge and without delay**, and, where technically feasible, **deliver security updates separately from functionality updates**, so a customer can take a fix without accepting feature change. - Security updates that have been issued must **remain available** for a substantial period after issue - at least ten years, or the remainder of the support period if that is longer - so a device recommissioned years later can still be brought current. Notice what that last pair does to your architecture: the update mechanism, the signing keys, the artifact hosting and the ability to build an old branch all have to outlive the product's sales life. ## Inputs to the number **Realistic field lifetime.** Declaring five years on a device that is bolted into a building for fifteen is not a clever minimum, it is a mismatch a market surveillance authority and your customers can both challenge, because the period must reflect expected lifetime. Use your own returns, RMA and telemetry data on how long units stay in service - it is usually longer than product management believes. **Your dependencies' horizons.** This is the input engineers most often skip. If the product's operating system, runtime, cryptographic library or toolchain reaches end of support in year four of a ten-year commitment, the difference is yours to carry: backporting fixes into an unmaintained branch, with no upstream to review them. Choosing a component with a long, credible maintenance horizon is a cheaper decision than any amount of later heroics, and it is a security-supply-chain decision that should sit in the same review as licence and feature fit. **Reachability of the installed base.** Can you actually deliver an update to a unit sold six years ago? Devices behind hostile networks, sites with change-control windows, hardware whose flash cannot hold a modern image, and customers who disabled automatic updates all shorten the effective support period below the declared one. If you cannot deliver, the declaration is a promise you will break in public. **Cost to keep the line alive.** Build environments, hardware in the test lab, signing infrastructure, staff who remember the code. Each additional supported branch and each additional variant multiplies that, which is why the most effective compliance move is usually **convergence**: fewer hardware revisions, one platform image across a product family, and fewer branches that need a fix applied. ## The judgment, and why it is a leadership call A long declared period is a sales asset - especially for buyers in regulated sectors who will pick it over a competitor - and simultaneously a multi-year liability, unpriced unless you put it into the unit economics. A short one is cheap and loses deals, and if it is visibly shorter than the way the product is really used, it is not defensible. So the decision is not made by an engineer estimating effort. It needs: product management on lifetime and market expectation, engineering on the dependency horizons and branch cost, finance on pricing the sustaining team into the unit, and legal on the declaration. The output should be a small number of standard support horizons - not one per SKU - written into the product plan at design time, alongside the requirement that the product be updatable for that long. ## What you tell the customer whose deployment outlives it Have the answer before it happens: a published end-of-support date visible from the start, a paid extended-support option where you can genuinely staff it, a migration path to a supported successor, and an honest end-of-life notice with enough runway for the customer's own change-control process. The failure mode to avoid is silence followed by a critical exploited flaw in an unsupported product that is still holding up someone's production line - which is also, awkwardly, the situation in which the reporting duties still expect you to say something. ## Strong answers versus weak ones A weak answer says *five years, because that is the minimum*. A strong one starts from how long the product is really used, connects the number to the maintenance horizons of the stack beneath it, admits that update delivery and build reproducibility are what make the commitment real, and names the organisational levers - variant reduction, a funded sustaining team, a priced extended-support tier - that make a long horizon survivable.