Skip to content

In short, OEMs should link SBOMs to machines via software versions and configurations, maintain that link throughout the lifecycle, and update it whenever the machine’s software changes.

From an OEM perspective, the most sensible way to link an SBOM to a specific machine is to treat the SBOM as part of the machine’s configuration data, not as a standalone document.

Each machine should have a unique asset identity (for example a serial number, asset ID, or digital twin). The SBOM is then linked to that asset by software and firmware version, not by individual physical unit only. In practice, this means one SBOM can cover many machines that share the same software stack and version.

When the OEM builds or commissions a machine, it records the machine’s asset ID, the installed firmware and software versions, and the corresponding SBOM version. When the OEM updates the software or firmware, it also updates the SBOM reference for that asset.

The physical machine does not change, but its cyber configuration does, and the SBOM linkage reflects that change.

For scalability, OEMs typically manage SBOMs centrally and link them to assets through: a configuration management system, an asset or fleet management platform, or a product lifecycle management (PLM) system.

This approach enables the OEM to quickly identify affected machines when a vulnerability appears in a specific software component and to deploy targeted updates, exactly as required by the CRA.

Ask our experts for more specific information on how you should link SBOM to your assets.

Read also