ETSI EN 303 645 provision 5.2-3 says manufacturers should continually monitor for, identify and rectify vulnerabilities in their products during the defined support period. The guidance text adds that a list of all software components and sub-components is a prerequisite for that monitoring, and mentions SBOM tools.
The wording
Provision 5.2-3 reads that manufacturers should continually monitor for, identify and rectify security vulnerabilities within products and services they sell, produce, have produced and services they operate during the defined support period. Note 1 expects due care for all software and hardware components in the product, including selected third parties that provide associated services.
The explanatory text observes that software often contains open source and third party components. It says creating and maintaining a list of all software components and their sub-components is a prerequisite to monitoring for product vulnerabilities, and that tools exist to scan source code and binaries to build a software bill of materials identifying third party components and versions. That information is then used to watch the associated security and licensing risks.
What this means in practice
The word is should, not shall, so this is a recommendation in this standard. Still, it describes a loop most teams need anyway.
- Inventory. Know which components and versions are in each released firmware.
- Watch. Compare that inventory against advisory sources on a schedule.
- Decide. For each hit, judge whether it affects your product.
- Fix. Patch, mitigate or document why it does not apply.
- Tell people. Reports go first to affected stakeholders, and the standard also names sharing with industry bodies.
Support period matters
The monitoring duty is tied to the defined support period, and the standard says manufacturers can continue outside it and release updates. This links to provision 5.3-13, which asks for the support period to be published. Without a stated period, nobody knows how long the loop runs.
| Element | Why it matters |
|---|---|
| Per-release component list | Lets you answer which units are affected |
| Support period stated | Defines how long monitoring continues |
| Advisory intake | Finds new problems after release |
| Disclosure policy | Gives finders a place to report |
A starting point
Pick your newest shipping firmware. Write down its components, with versions, from the build system. Set a weekly reminder to check them, and record each decision. That small habit is most of what the provision asks for.
Where Safeguard fits
Safeguard provides SBOM and dependency scanning, reachability analysis, and policy gates for the source repositories and manifests it supports, and you can run a free scan at gold.safeguard.sh/scan. Check coverage for your build system before relying on it.
Try it yourself
Open a finding and note the fields you would need to decide whether it affects a given release.
Click through it at your own pace, or open it full screen.
Quick check
Is an SBOM mandatory under this standard?
The provision says manufacturers should monitor, and the supporting text calls a component list a prerequisite. It does not use the word SBOM as a shall requirement.
Does the standard cover third party services?
Note 1 expects due care for selected third parties that provide associated services, as well as components in the product.
Sources
Last reviewed: 19 October 2026.
