End of support should therefore be treated as a controlled lifecycle event. Manufacturers should communicate the support end date clearly, preserve security updates that remain subject to Article 13(9), maintain required records and avoid presenting unsupported historical software as though it continues to receive ordinary vulnerability handling.
Article 13(8) Ties Effective Vulnerability Handling to the Support Period
Article 13(8) requires manufacturers, when placing a product with digital elements on the market and for the support period, to ensure that vulnerabilities of the product, including its components, are handled effectively in accordance with Annex I Part II. The support period therefore creates an important lifecycle boundary for the manufacturer's ordinary vulnerability-handling obligation. The manufacturer should know the end date in advance and operate the vulnerability process consistently until that date.
- Track the support-period end date.
- Continue vulnerability handling throughout the period.
- Include product components in the process.
- Avoid treating support as ended before the communicated date.
The End Date Should Already Have Been Communicated to Users
Article 13(19) requires the end date of the support period, including at least the month and the year, to be clearly and understandably specified at the time of purchase in an easily accessible manner and, where applicable, on the product, packaging or by digital means. Annex II also requires information about the type of technical security support offered and the support end date. End of support should therefore not arrive as an unexpected internal decision that contradicts the date communicated to users.
- State the month and the year.
- Keep user information accessible.
- Keep product and website information consistent.
- Avoid silently shortening the communicated period.
Issued Security Updates Can Remain Available After Support Ends
Article 13(9) creates a separate rule for security updates already made available during the support period. Each such update must remain available after issuance for a minimum of 10 years or for the remainder of the support period, whichever is longer. If the support period has ended first, that availability obligation can therefore continue. This rule concerns continued availability of issued updates rather than an automatic obligation to create new security fixes indefinitely.
- Preserve issued security updates.
- Maintain access for the Article 13(9) period.
- Keep version information understandable.
- Distinguish availability from creation of new fixes.
Historical Software Archives Are Optional
Article 13(11) allows manufacturers to maintain public software archives that improve user access to historical versions. The Regulation does not require every manufacturer to operate such an archive. Where a public archive is maintained, users must be clearly informed in an easily accessible manner about risks associated with using unsupported software.
- Treat a public software archive as optional.
- Identify unsupported versions clearly.
- Provide accessible risk information.
- Avoid implying continuing security support.
Unsupported Software Warnings Should Be Unambiguous
A user downloading an old version from an official archive can reasonably assume that the manufacturer still recognises the software. The archive should therefore distinguish availability from support status. The warning should make clear that the version is unsupported software and may contain vulnerabilities that are no longer being handled through the normal support-period process. This reduces the risk that historical availability is mistaken for active security maintenance.
- Label unsupported software clearly.
- Separate archive availability from support status.
- Warn about continuing security risk.
- Direct users toward supported versions where appropriate.
Recital 61 Discusses Source-Code Release After Support
Recital 61 states that when products reach the end of their support periods, manufacturers should consider releasing the source code either to other undertakings that commit to extending vulnerability-handling services or to the public. This is useful policy context, but recital 61 should not be presented as a separately numbered operative obligation requiring source-code publication in every case. Where source code is shared with another undertaking, the recital also recognises that ownership and public dissemination can be controlled through contractual arrangements.
- Recognise recital 61 as policy context.
- Do not describe source-code release as universally mandatory.
- Consider continuity options where appropriate.
- Protect legitimate ownership interests.
Plan Secure Decommissioning
Annex II requires detailed instructions or a reference to instructions covering secure decommissioning of the product, including how user data can be securely removed. End of support can therefore be connected to decommissioning guidance where continued use would create unacceptable operational risk. The appropriate advice depends on the product and whether a supported migration path remains available.
- Provide secure decommissioning information.
- Explain secure removal of user data.
- Identify supported migration options where available.
- Avoid leaving users without practical end-of-life guidance.
Technical Documentation Retention Continues
Article 13(13) requires manufacturers to keep the technical documentation and the EU declaration of conformity available to market surveillance authorities for at least 10 years after the product was placed on the market or for the support period, whichever is longer. Reaching the end of support therefore does not mean technical documentation can automatically be deleted.
- Retain technical documentation.
- Retain the EU declaration of conformity.
- Apply the longer applicable retention period.
- Keep records accessible to market surveillance authorities.
Preserve End-of-Support Evidence
Useful evidence includes the communicated support end date, user-facing support information, records showing vulnerability handling through the final supported period, security-update availability records, unsupported-software archive warnings where relevant and required retained technical documentation. This evidence helps demonstrate that end of support was a managed lifecycle event rather than an undocumented cessation of security activity.
- Support end date.
- User communications.
- Final supported vulnerability cases.
- Historical update availability.
- Archive warnings.
- Technical-documentation retention.
Official sources
Read the full legal text and Commission material for precise wording, qualifications and updates.