Turning the support period into commitments
The rule is set out in Support period and life cycle. This page covers its contractual and commercial translation.
What goes where
| Medium | Content |
|---|---|
| Product documentation (Annex II) | Type of security technical support offered and the end date of the support period, at least the month and year, in clear and understandable terms |
| Datasheet and product page | The same date, visible at the time of purchase |
| Terms and conditions | What security support covers and does not cover, and how fixes are made available |
| Technical documentation | The duration chosen and its justification |
| Internal register | The consolidated view, with limiting dependencies |
Drafting the statement
It must be understandable to a non-specialist buyer. A standard wording:
Security support. This product receives security updates until [month year]. During that period, security fixes are provided free of charge and, where technically feasible, distributed separately from functional updates. After that date no new fixes will be produced; fixes already published remain downloadable until [month year].
The two dates are distinct and both must appear: the end of fix production, and the end of their availability.
Desynchronisation with upstream
The structural problem: you commit five years to your customers, on a product built from components whose upstream support ends earlier.
| Situation | Options |
|---|---|
| Commercial third-party component whose support ends before yours | Negotiate extended support; plan a migration; shorten your commitment |
| Abandoned free component | Fork and maintain, replace, bring in-house — see Integrating open source |
| Underlying operating system or platform reaching end of life | Plan the migration, or align your end of support |
Each option has a cost, which must be provisioned when the decision to integrate the component is taken, not discovered three years later. That is why “upstream support duration” appears in the diligence grid.
Free of charge
Security fixes are free of charge during the support period, except where otherwise agreed for tailor-made products between businesses.
Direct commercial consequence: a maintenance contract cannot condition access to security fixes. It may cover functional support, upgrades, assistance, guaranteed response times — not the security fixes themselves.
Existing offerings must be reviewed on that basis. For some vendors it is a business model question, and it should be treated as one.
End-of-life policy
To be written once and applied to every product:
- Announce the end of support, with a defined notice period — twelve months is reasonable for a professional product.
- Remind at regular intervals during the notice period, through every available channel.
- Offer a migration path: successor product, procedure, support.
- Publish the last update, with the list of known unfixed vulnerabilities.
- State the residual risk of use after the end of support.
- Keep published fixes available until the date owed.
- Archive the technical documentation and the SBOM for the remaining period.
On cessation of operations
The Regulation provides that a manufacturer ceasing operations informs the market surveillance authorities and, by any means available, the users of the products concerned. It also encourages transferring the source code or publishing it as free software so maintenance can continue.
These provisions must be anticipated in your articles and liquidation procedures: it is too late to arrange them once cessation has been decided.
The register
The table to keep is in Support period and life cycle. It is reviewed at every committee, because it reveals commitments that have become untenable — and the only moment to correct them at no cost is before they are made.