Setting the support period
The support period reflects how long the product is reasonably expected to be in use, taking into account the product, its expected lifetime, user expectations, and comparable products. It must be at least five years unless the expected lifetime is genuinely shorter, and it must be published clearly — including in the user information and, where relevant, at the point of sale.
For industrial and infrastructure devices, a five-year period is often indefensible: a meter or a building controller runs for fifteen. Be honest at design time, because you will be held to what you publish, and because setting it too short is a market disadvantage as well as a regulatory risk.
When the support period ends, consider making the last SBOM available and telling users clearly what stops. Some manufacturers publish an end-of-support advisory as a matter of policy; it manages expectations and reduces support load.
The supplier problem
Your obligation is unconditional; your suppliers' contracts probably are not. In a typical embedded BOM you depend on:
- A silicon vendor's BSP, bootloader, radio stack and crypto library.
- A module vendor's certified radio module with opaque firmware.
- An RTOS or Linux distribution with its own lifecycle.
- Open-source components, some unmaintained.
- Possibly an ODM that wrote the application.
If the silicon vendor stops patching the Wi-Fi stack in year four of your ten-year support period, the obligation is still yours.
Contract terms to insist on
- SBOM delivery for every binary component, in SPDX or CycloneDX, updated at every release.
- Security patch commitment with a stated end date, and a notification duty for vulnerabilities within a fixed window (48-72 hours is achievable).
- A support period at least as long as yours — or an explicit gap you have priced and mitigated.
- Source escrow or source access for critical components, so you can patch when the vendor will not.
- The right to disclose the component and vulnerability in your public advisories; NDAs that forbid this conflict directly with Annex I Part II (4).
- Cooperation with reporting, including timely technical detail so you can meet a 24-hour early warning.
Due diligence on third-party components
Article 13(5) obliges manufacturers to exercise due diligence when integrating components sourced from third parties, and to ensure those components do not compromise the product. In practice:
- Check the component's maintenance status and vulnerability history before adoption, and record the check.
- Prefer components with a published security policy and a disclosure contact.
- Re-review at each major release; a component that was maintained at design-in may be abandoned three years later.
- Where you find a vulnerability in a third-party component, you must report it to the person or entity maintaining the component.
Making the decade affordable
Long support is affordable only if the platform is shared. One maintained BSP, one update client, one signing chain and one SBOM pipeline across the portfolio turns ten-year support from a per-product tax into a platform cost. That is a product-architecture decision, and it is the single highest-leverage CRA investment an embedded organisation can make.