18/09 edition: a support promise needs a maintenance chain

Preparation, not an accelerated duty

This recovered edition asks whether the product owner can support a maintenance promise with an executable chain. It addresses manufacturers, engineering and technical procurement. It is preparatory analysis published in October, not an announcement of a new support duty arising on 18 September.

Article 71 distinguishes general application on 11 December 2027 from Article 14 application on 11 September 2026. The support requirements discussed here must not be presented as a general mandate already applicable in September. Velqory's proposed early preparation is an operational choice, not a changed legal date.

Support and availability are different clocks

Article 13 links the support period to expected use; it establishes at least five years unless expected use is shorter, in which case the period corresponds to that expected use. It also requires security updates issued during support to remain available for at least ten years after issuance or the remaining support period, whichever is longer.

Velqory proposal: keep two independent fields in the release record. The first explains how long security maintenance exists; the second tracks availability of each issued update. Keeping a package in an archive does not, by itself, show that new fixes will continue to be produced.

A dependency can interrupt the promise

Annex I, Part II includes identifying and documenting vulnerabilities and components, with a machine-readable SBOM covering at least top-level dependencies. Do not turn that minimum into a claim that the text requires all transitive dependencies. Article 13 also provides for due diligence on third-party components.

NCSC recommends identifying obsolete products and understanding versions and owners. As a proposed adaptation, ask each component maintainer for version policy, advisory channels and an alternative if support ends before the product's support does. An open licence does not guarantee that a team will be available to fix issues.

A tabletop exercise for the sold release

This original, untested matrix does not certify compliance. The proposed exercise uses a hypothetical release still being distributed, with a dependency approaching end of support. Procurement should not accept continuity solely from a commercial statement; engineering must show what response it could prepare.

The channel only fixes the newest release

Hypothetical scenario: the team prepares an update for the newest release, but customers on an older release remain within its declared period. Ask who knows those recipients and what compatible update path exists. No invented CVE is needed to expose the delivery gap.

Velqory proposes retaining a controlled demonstration of target-release selection, package validation and incompatibility communication. If the answer is 'the customer should have migrated', request the basis of the original promise before closing. Creating a fix and making a fix usable are different outcomes.

Turn the promise into a product decision

The Commission guidance page lists support periods and risk assessment among preparation topics and stresses its non-binding nature. The obligation comes from the regulation; this article's matrix and exercise are Velqory proposals, with no demonstrated results.

The useful outcome is deciding whether the promise is sustainable, needs resources or requires a legally reviewed commercial strategy change. Retain limitations, dependencies and reassessment conditions. Avoid selling a period simply because the number looks straightforward: the commitment needs someone able to receive, prepare and deliver a security response.