The support period and security updates
Manufacturers must provide security updates to address vulnerabilities throughout the expected lifetime of a product or for a clearly defined support period. This requirement ensures that products with digital elements remain secure against evolving threats after they are placed on the market.
What it means
The intent is to eliminate "abandonware" and ensure that users are not left with insecure hardware or software because a manufacturer stopped providing patches prematurely. The regulation shifts the burden of long-term security onto the producer, requiring them to maintain a mechanism for delivering fixes over time.
In practice, this means you cannot simply release a product and stop maintaining it while it is still in active use. You must either support the product for its entire reasonable expected lifetime or explicitly define a "support period" (e.g., five years from the date of purchase) so that the buyer knows exactly when security updates will cease.
This scope includes not only the technical ability to push an update but also the organizational process of monitoring for new vulnerabilities and the transparency of communicating those lifecycles to the end user.
How to meet it
- Define a concrete support period for each product line (e.g., "X years from release") and document this in your product specifications.
- Establish a vulnerability management lifecycle that includes discovery, triage, patching, and deployment timelines.
- Implement a secure delivery mechanism for updates, such as over-the-air (OTA) updates or a dedicated authenticated download portal.
- Clearly communicate the support period to customers via user manuals, technical documentation, or at the point of sale.
- Develop a process to notify users when security updates are available and provide instructions on how to apply them.
- Ensure that the update mechanism itself is secure (e.g., using digital signatures) to prevent the delivery of malicious firmware.
Evidence an auditor asks for
- A formal Product Support Policy or Lifecycle Document specifying the duration of security support for each product version.
- Records of vulnerability disclosures and a corresponding log showing when patches were developed and released (the "time-to-remediate").
- Publicly available documentation, such as a website or manual, where the support period is explicitly stated for the end user.
- Release notes or changelogs that specifically identify security fixes provided during the support window.
Common pitfalls
- Using vague terminology like "reasonable period" or "as long as possible" instead of defining a specific number of years or a clear event.
- Failing to update the support period when hardware components reach end-of-life, leaving a gap between physical usability and security coverage.
- Neglecting to document the communication channel used to notify users of critical updates, relying instead on "silent" updates that may not be applied by all users.