ENISA releases technical guidance on Software Bills of Materials for SMEs and software stewards

The European Union Agency for Cybersecurity, ENISA has published its Technical Advisory for Software Bill of Materials on 22 October 2026, offering lifecycle-based implementation guidance for organisations beginning SBOM adoption, particularly SMEs and software stewards.

The advisory recommends starting with build-time generation, capturing direct and transitive dependencies, validating identifiers, and binding each SBOM to its exact software artifact. It also recommends retaining historical inventories and documenting missing information. These practices help teams distinguish deployed exposure from irrelevant component matches.

The advisory explicitly treats SBOMs as a foundational data layer rather than a complete security solution. Their value depends on consumption, risk-based prioritisation and documented remediation decisions.

Why this matters for MedTech and patient safety

Component inventories can support vulnerability assessment across embedded device firmware, laboratory systems and SaMD cloud backends. For manufacturers and healthcare delivery organisations, incomplete or outdated inventories can delay identification of exposed systems. Depending on the component and deployment, missed vulnerabilities could contribute to care disruption, altered diagnostic data or lateral movement into clinical networks.

Regulatory angle

ENISA states that the advisory neither creates obligations nor constitutes a legal interpretation of the CRA.

The Cyber Resilience Act requires in-scope manufacturers to identify and document components and vulnerabilities, including through machine-readable SBOMs covering at least top-level dependencies. Its main requirements apply from 11 December 2027 while reporting obligations already apply since 11 September 2026.

Medical device Products covered by the EU MDR or IVDR are excluded from CRA scope. Medical-device teams should therefore map SBOM evidence to their applicable FDA and EU medical-device post-market processes rather than treat this advisory as proof of compliance.

Recommended next steps

• Check coverage: Select one supported release; compare its SBOM with build artifacts and deployed versions. Then record unidentified dependencies and supplier gaps.

• Pilot the workflow: Generate SPDX or CycloneDX output, validate identifiers and completeness, bind it to the release digest, and retain validation evidence.

• Review controls and logs: Also check repository access, signing and validation failures. Where identified device vulnerabilities cannot be patched before validation, employ a contextualized risk assessment approach by connecting findings to actual exploitability, clinical criticality, patch-validation timelines and have a customer-communication plan in place.

Further reading: ENISA Technical Advisory for Software Bill of Materials.