Tell customers on an end of support release three things: whether the release contains the affected component, that it no longer receives fixes because its support period ended, and the specific upgrade path to a supported version. Do not promise a patch you have decided not to build, and do not stay silent.
Definitions
A support period is the time during which a vendor handles vulnerabilities and ships security updates for a release. End of support means that period has finished. An end of support release can still contain a vulnerable component, and customers may still run it.
Why silence is the wrong answer
Customers on old releases often have the least tooling and the most exposure. If they hear nothing from you and then read about the issue elsewhere, trust drops. The EU Cyber Resilience Act's Annex II asks for the end date of the support period to be given to users, so they can know how long vulnerabilities will be handled. That date makes the end of support conversation easier, because it was never a surprise.
Message structure
| Part | Content |
|---|---|
| Status | Affected, not affected or not assessed, in plain words |
| Support position | The release is past its support end date, and no fix is planned |
| Risk | What an attacker could do if the component is present |
| Path | The supported release to move to, and the upgrade guide |
| Interim measures | Any mitigation that works without upgrading, if you tested one |
| Help | Who to contact, and whether you offer migration support |
Steps
- List releases past their support end date that customers still run.
- Check the SBOM for each, if it exists, to see whether the component is present.
- If there is no SBOM, say that the status is not assessed, instead of guessing.
- Decide your policy: assess and state status, but do not patch. Write it down.
- Send the message to the customers you know are on those releases.
- Put a general note on the advisory page for anyone you cannot reach.
- Record the exceptions: contractual extended support is a different cohort, with its own message.
What not to do
- Silently back port a fix, then answer inconsistently to different customers.
- Mark an end of support release not affected without checking.
- Make the support end date vague. State it in the advisory and in product documentation.
- Treat all old releases alike. An extended support contract changes the answer.
Keep the policy simple
A short written policy helps support staff answer in one line: we assess status for older releases, we do not patch past the end date, and we will help you move. Link it from every advisory. See also which supported versions are affected.
Quick check
Do we owe a VEX for an end of support release?
There is no universal rule, but a status for releases customers still run is helpful. If you do not assess, say so.
Can we charge for patching an old release?
That is a commercial decision outside this post. The Cyber Resilience Act has its own terms on security updates, so check your obligations with counsel.
Safeguard's SBOM and dependency scanning and asset discovery help identify what older releases contain. A free scan is available.
Sources
- Regulation (EU) 2024/2847, EUR-Lex, Annex II
Last reviewed: 19 October 2026.
