End of support is a product-security transition, not only a lifecycle announcement. Users need to know the exact date, which product or version it applies to, what security support stops, whether migration is recommended, and where historical updates or archived software can still be found.
Start With the Date Already Communicated at Purchase
Article 13(19) requires the support-period end date, including at least the month and year, to be clearly and understandably specified at the time of purchase. End-of-support communication should remain consistent with that original commitment unless the manufacturer has formally extended the period. Users should not discover a shorter date only when support is about to end.
- Use the same product-specific date.
- Include at least month and year.
- Avoid silently shortening the period.
- Correct inconsistent public records.
Identify the Exact Product and Versions Reaching End of Support
A manufacturer can support several product generations at once. End-of-support notices should identify the exact product, model, software branch or version to which the date applies. Broad brand-level statements can create confusion where newer versions remain supported after an older branch reaches the end of its support period.
- Product name and type.
- Relevant models or branches.
- Version range where applicable.
- Supported successor where available.
Explain What Security Support Ends
Annex II point 7 connects the support period to the period during which users can expect vulnerabilities to be handled and security updates to be provided. End-of-support communication should therefore explain that active vulnerability handling and new security updates are ending for the affected product, rather than using only a vague end-of-life label.
- Explain vulnerability-handling status.
- Explain new security-update status.
- Keep commercial warranty language separate.
- Avoid ambiguous lifecycle terminology.
Give Users Practical Migration Information
The CRA does not prescribe one universal migration notice format, but security communication is more useful when users can act on it. Where a supported successor, upgrade path or replacement product exists, the end-of-support notice should identify it and explain any important compatibility or data-migration considerations.
- Identify supported alternatives.
- Explain important compatibility limits.
- Explain data migration where relevant.
- Avoid implying that an unsupported version remains safe merely because it still operates.
Distinguish Active Support From Historical Update Availability
Article 13(9) can require security updates issued during the support period to remain available after active support ends. End-of-support communication should therefore distinguish the end of new vulnerability handling from the continued availability of previously issued security updates. Users may still need historical packages when rebuilding or restoring a supported deployment history.
- Explain that active support is ending.
- Keep issued update locations accessible.
- Preserve historical version information.
- Avoid saying all security resources disappear at end of support.
Label Unsupported Software Clearly
Article 13(11) allows public software archives but requires clear and easily accessible information about risks associated with using unsupported software. Where an end-of-support product remains downloadable, the archive or download page should clearly state that the software is unsupported and may contain vulnerabilities that are no longer handled through the normal support process.
- Label unsupported status prominently.
- Explain continuing cybersecurity risk.
- Separate archive availability from support status.
- Point to supported alternatives where appropriate.
Use More Than One Communication Channel Where Risk Justifies It
The Regulation specifies purchase-time visibility for the support end date but does not prescribe one universal end-of-support notification channel. Manufacturers can use account portals, product notifications, email, documentation sites or support pages according to the product and user relationship. High-impact products can justify more direct notice than a passive documentation update.
- Use channels appropriate to the product.
- Consider direct notice for high-impact products.
- Keep the public support page current.
- Maintain consistent wording across channels.
Preserve the End-of-Support Communication Record
The manufacturer should retain the support end date, product scope, public notices and any migration information used to communicate the transition. This creates a clear record of what users were told and helps support teams answer later questions about historical support status.
- Support end date record.
- Affected product scope.
- Published notices.
- Migration guidance.
- Historical update location.
Official sources
Read the full legal text and Commission material for precise wording, qualifications and updates.