ETSI TR 104 285 V1.1.1 (2026-08)

• Abstract:

  DTR/MTS-TST12DevSecPas

• Status: Not Published
• Technical Committee: MTS TST - Testing
• Current Stage: 12 - Citation in the OJ (auto-insert)
• Due Date: 01-Sep-2026
• Completion Date: 10-Aug-2026

TECHNICAL REPORT
Methods for Testing & Specification (MTS);
Device Security Passport
2 ETSI TR 104 285 V1.1.1 (2026-08)

Reference
DTR/MTS-TST12DevSecPas
Keywords
device, IoT, security, testing
ETSI
650 Route des Lucioles
F-06921 Sophia Antipolis Cedex - FRANCE

Tel.: [phone]  Fax: [phone]

Siret N° 348 623 562 00017 - APE 7112B
Association à but non lucratif enregistrée à la
Sous-Préfecture de Grasse (06) N° w061004871

Important notice
The present document can be downloaded from the
ETSI Search & Browse Standards application.
The present document may be made available in electronic versions and/or in print. The content of any electronic and/or
print versions of the present document shall not be modified without the prior written authorization of ETSI. In case of any
existing or perceived difference in contents between such versions and/or in print, the prevailing version of an ETSI
deliverable is the one made publicly available in PDF format on ETSI deliver repository.
Users should be aware that the present document may be revised or have its status changed,
this information is available in the Milestones listing.
If you find errors in the present document, please send your comments to
the relevant service listed under Committee Support Staff.
If you find a security vulnerability in the present document, please report it through our
Coordinated Vulnerability Disclosure (CVD) program.
Notice of disclaimer & limitation of liability
The information provided in the present deliverable is directed solely to professionals who have the appropriate degree of
experience to understand and interpret its content in accordance with generally accepted engineering or
other professional standard and applicable regulations.
No recommendation as to products and services or vendors is made or should be implied.
No representation or warranty is made that this deliverable is technically accurate or sufficient or conforms to any law
and/or governmental rule and/or regulation and further, no representation or warranty is made of merchantability or fitness
for any particular purpose or against infringement of intellectual property rights.
In no event shall ETSI be held liable for loss of profits or any other incidental or consequential damages.

Any software contained in this deliverable is provided "AS IS" with no warranties, express or implied, including but not
limited to, the warranties of merchantability, fitness for a particular purpose and non-infringement of intellectual property
rights and ETSI shall not be held liable in any event for any damages whatsoever (including, without limitation, damages
for loss of profits, business interruption, loss of information, or any other pecuniary loss) arising out of or related to the use
of or inability to use the software.
Copyright Notification
No part of this document may be reproduced in any form, by any means and in any media, without the prior written
authorization of ETSI and except as expressly permitted below.
By way of exception and when the document is a normative deliverable (European Standard (EN),
Technical Specification (TS), Group Specification (GS) or ETSI Standard (ES)), ETSI authorizes to reproduce
and incorporate into products, services and technical documentation only those extracts (e.g. templates) that are strictly
necessary for the technical implementation of the normative deliverable, to ensure compliance with the latter.
Nothing in this notice shall be construed as limiting any mandatory exceptions to copyright provided by applicable law.

© ETSI 2026.
All rights reserved.
ETSI
3 ETSI TR 104 285 V1.1.1 (2026-08)
Contents
Intellectual Property Rights . 4
Foreword . 4
Modal verbs terminology . 4
Executive summary . 4
Introduction . 5
1 Scope . 6
2 References . 6
2.1 Normative references . 6
2.2 Informative references . 6
3 Definition of terms, symbols and abbreviations . 8
3.1 Terms . 8
3.2 Symbols . 8
3.3 Abbreviations . 8
4 State of the art of device descriptors . 9
4.1 Bill of Material (BOM) . 9
4.1.1 Introduction. 9
4.1.2 Software Bill of Material (SBOM) . 10
4.1.3 Hardware Bill of Material (HBOM) . 11
4.1.4 Cryptography Bill of Material (CBOM) . 12
4.2 Manufacturer Usage Description (MUD) . 12
4.3 Vulnerability Information Exchange Formats . 13
4.3.1 Vulnerability Exploitability Exchange Format (VEX) . 13
4.3.2 Vulnerability Disclosure Report (VDR) . 14
4.4 Security Assessment Frameworks . 15
4.4.1 Open Security Control Assessment Language (OSCAL) . 15
4.4.2 Security Content Automation Protocol (SCAP) . 17
5 Rationale for a device security passport . 18
5.1 Limitations of existing device security descriptors . 18
5.2 Need for an integrated and lifecycle-aware approach . 18
5.3 Design principles of a Device Security Passport . 18
5.4 Considered alternatives and design choices . 19
6 Device Security Passport specification . 19
6.1 Concept and objectives . 19
6.2 Device Security Passport lifecycle . 20
6.3 Stakeholders and roles . 21
7 DOSS: Using the DSP for supply chain management . 22
7.1 DOSS overview . 22
7.2 The role of the DSP in the DOSS project . 23
7.3 DSP data model . 23
8 Role of the Device Security Passport in regulatory context . 25
8.1 Alignment with the Cyber Resilience Act (CRA) . 25
8.2 Alignment with the NIS2 directive . 26
8.3 Alignment with the CSA . 27
9 Lessons learned and recommendations . 27
History . 29

ETSI
4 ETSI TR 104 285 V1.1.1 (2026-08)
Intellectual Property Rights
Essential patents
IPRs essential or potentially essential to normative deliverables (European Standard (EN), Technical Specification (TS),
Group Specification (GS) or ETSI Standard (ES)) may have been declared to ETSI. The declarations pertaining to these
essential IPRs, if any, are publicly available for ETSI members and non-members, and can be found in
ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in
respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the
ETSI IPR online database.
Pursuant to the ETSI Directives including the ETSI IPR Policy, no investigation regarding the essentiality of IPRs,
including IPR searches, has been carried out by ETSI. No guarantee can be given as to the existence of other IPRs not
referenced in ETSI SR 000 314 (or the updates on the ETSI Web server) which are, or may be, or may become,
essential to the present document.
Trademarks
The present document may include trademarks and/or tradenames which are asserted and/or registered by their owners.
ETSI claims no ownership of these except for any which are indicated as being the property of ETSI, and conveys no
right to use or reproduce any trademark and/or tradename. Mention of those trademarks in the present document does
not constitute an endorsement by ETSI of products, services or organizations associated with those trademarks.
DECT™, PLUGTESTS™, UMTS™ and the ETSI logo are trademarks of ETSI registered for the benefit of its
Members. 3GPP™, LTE™ and 5G™ logo are trademarks of ETSI registered for the benefit of its Members and of the
3GPP Organizational Partners. oneM2M™ logo is a trademark of ETSI registered for the benefit of its Members and of ®
the oneM2M Partners. GSM and the GSM logo are trademarks registered and owned by the GSM Association.
Foreword
This Technical Report (TR) has been produced by ETSI Technical Committee Methods for Testing and Specification
(MTS).
Modal verbs terminology
In the present document "should", "should not", "may", "need not", "will", "will not", "can" and "cannot" are to be
interpreted as described in clause 3.2 of the ETSI Drafting Rules (Verbal forms for the expression of provisions).
"must" and "must not" are NOT allowed in ETSI deliverables except when used in direct citation.
Executive summary
The increasing complexity of digital supply chains and the growing regulatory pressure on cybersecurity have
highlighted the need for improved mechanisms to manage, share and reuse device security information throughout the
lifecycle. Current practices rely on a fragmented ecosystem of security descriptors, tools and documents that are often
disconnected, difficult to maintain and poorly suited for automation. The present document analyses the concept of a
Device Security Passport (DSP) as a unifying, machine-readable mechanism to aggregate and reference security-related
artefacts associated with connected devices. The DSP is presented as a lifecycle-aware construct capable of supporting
supply-chain transparency, continuous security management and regulatory compliance, while preserving existing
standards, ownership models and responsibilities. The present document reviews the state of the art of security
descriptors, introduces the DSP concept and lifecycle, and describes its concrete instantiation in the DOSS project. The
applicability of the DSP to regulatory frameworks such as the Cyber Resilience Act, the NIS2 Directive and the EU
Cybersecurity Act is analysed, highlighting its potential to support transparency, evidence reuse and continuous
compliance. Based on the experience gained, the present document identifies key lessons learned and outlines
recommendations for future standardization and research. Overall, the present document demonstrates that the DSP is a
viable and promising approach to improve trust, traceability and automation across device supply chains.
ETSI
5 ETSI TR 104 285 V1.1.1 (2026-08)
Introduction
Digital products and connected devices are increasingly embedded in complex and dynamic ecosystems involving
multiple stakeholders across global supply chains. Manufacturers, system integrators, operators and service providers
each contribute to the security posture of a device at different stages of its lifecycle. At the same time, cybersecurity
threats are becoming more frequent and sophisticated, while regulatory frameworks are imposing stricter obligations
related to transparency, vulnerability management and lifecycle support.
In response to these challenges, a growing number of security descriptors and standards have emerged, including
components inventory, network behaviour profiles, vulnerability disclosure formats and risk reporting mechanisms.
While these artefacts address specific aspects of device security, they are typically developed and managed in isolation.
As a result, security information is fragmented across multiple documents, formats and repositories, making it difficult
to obtain a consistent and up-to-date view of a device's security posture.
This fragmentation is further exacerbated by the dynamic nature of security information. Vulnerabilities, configurations
and operational contexts evolve continuously after deployment, requiring mechanisms that support updates, traceability
and accountability over time. Traditional documentation-based approaches are poorly suited to this task, as they rely
heavily on manual processes and human interpretation.
In parallel, regulatory pressure is increasing. New European frameworks, such as the Cyber Resilience Act (CRA) [i.1],
the Network and Information Systems 2 Directive (NIS2) [i.2] and the EU Cybersecurity Act (CSA) [i.3], introduce
lifecycle-oriented obligations for manufacturers and operators, including transparency requirements, vulnerability
management processes and post-market support obligations. Meeting these requirements using ad hoc documentation
and disconnected artefacts introduces significant overhead for manufacturers and operators and limits the potential for
automation.
These challenges highlight the need for a unified approach to managing device security information across the entire
lifecycle. The Device Security Passport (DSP) is proposed as a response to this need. Rather than introducing yet
another standalone descriptor, the DSP acts as an aggregation layer that links existing security artefacts while
preserving their original formats and ownership. By providing a single logical entry point to security information, the
DSP improves visibility, supports automation and enables continuous security assurance.

ETSI
6 ETSI TR 104 285 V1.1.1 (2026-08)
1 Scope
The present document focuses on presenting the results, observations and lessons learned derived from the analysis and
application of the Device Security Passport (DSP) concept in real project environments. In particular, it examines its
instantiation within the DOSS project, which addresses security challenges in complex device supply chains with a
focus on lifecycle-oriented security management and information sharing. The present document analyses how the DSP
can be used as a unifying mechanism to support transparency, traceability and automation across the device lifecycle,
and discusses its applicability to emerging regulatory and certification frameworks. The present document does not
define normative requirements, but rather provides technical insights and experience-based observations intended to
inform future standardization and research activities.
2 References
2.1 Normative references
Normative references are not applicable in the present document.
2.2 Informative references
References are either specific (identified by date of publication and/or edition number or version number) or
non-specific. For specific references, only the cited version applies. For non-specific references, the latest version of the
referenced document (including any amendments) applies.
NOTE: While any hyperlinks included in this clause were valid at the time of publication, ETSI cannot guarantee
their long-term validity.
The following referenced documents may be useful in implementing an ETSI deliverable or add to the reader's
understanding, but are not required for conformance to the present document.
[i.1] Regulation (EU) 2024/2847 of the European Parliament and of the Council of 23 October 2024 on
horizontal cybersecurity requirements for products with digital elements and amending
Regulations (EU) No 168/2013 and (EU) 2019/1020 and Directive (EU) 2020/1828 (Cyber
Resilience Act).
[i.2] Directive (EU) 2022/2555 of the European Parliament and of the Council of 14 December 2022 on
measures for a high common level of cybersecurity across the Union, amending Regulation (EU)
No 910/2014 and Directive (EU) 2018/1972, and repealing Directive (EU) 2016/1148 (NIS 2
Directive).
[i.3] Regulation (EU) 2019/881 of the European Parliament and of the Council of 17 April 2019 on
ENISA (the European Union Agency for Cybersecurity) and on information and communications
technology cybersecurity certification and repealing Regulation (EU) No 526/2013 (Cybersecurity
Act).
[i.4] National Telecommunications and Information Administration (NTIA) (2021): "The Minimum
Elements For a Software Bill Of Materials (SBOM) Pursuant to Executive Order 14028 on
Improving the Nation's Cybersecurity".
[i.5] Cybersecurity and Infrastructure Security Agency CISA: "Hardware Bill of Materials (HBOM)
Framework for Supply Chain Risk Management", September 25, 2023.
[i.6] IBM: "CBOM: Cryptography Bill of Materials" June 29, 2023.
[i.7] CycloneDX: "Machine Learning Bill of Materials (ML-BOM)".
[i.8] CycloneDX: "Manufacturing Bill of Materials (MBOM)".
[i.9] CycloneDX: "Operations Bill of Materials (OBOM)".
ETSI
7 ETSI TR 104 285 V1.1.1 (2026-08)
[i.10] CycloneDX: "Software as a Service (SaaSBOM)". ®
[i.11] ISO/IEC 5962:2021: "Information technology — SPDX Specification V2.2.1".
[i.12] ECMA-424: "CycloneDX Bill of materials specification", December 2025.
[i.13] ISO/IEC 19770-2:2015: "Information technology — IT asset management. Part 2: Software
identification tag".
[i.14] IETF RFC 8520 (March 2019): "Manufacturer Usage Description Specification", E. Lear,
D. Romascanu, and R. Droms.
[i.15] IETF RFC 7950 (August 2016): "The YANG 1.1 Data Modeling Language", M. Bjorklund.
[i.16] IETF RFC 9761 (April 2025): "Manufacturer Usage Description (MUD) for TLS and DTLS
Profiles for Internet of Things (IoT) Devices", T. Reddy.K, D. Wing, B. Anderson.
[i.17] IETF RFC 9472 (October 2023): "A YANG Data Model for Reporting Software Bills of Materials
(SBOMs) and Vulnerability Information", E. Lear, S. Rose.
[i.18] S. Sebastio, S. Beena, S. Matheu, R. Atoui and A. Skarmeta: "Bolstering Up Smart Products
Cybersecurity (Re-)Certification with Manufacturer's Evidence", 2025 IEEE International
Conference on Smart Computing (SMARTCOMP), Cork, Ireland, 2025, pp. 270-275,
doi: 10.1109/SMARTCOMP65954.2025.00085.
[i.19] A. Molina Zarca, J. Bernal Bernabé, J. Ortíz, A. Skarmeta: "D2.5 Policy-based Definition and
Policy for Orchestration Final Report", ANASTACIA Project, 2018.
[i.20] NIST SP 1800-15 (2019): "Securing Small-Business and Home Internet of Things Devices".
[i.21] CISA: "Minimum Requirements for Vulnerability Exploitability eXchange (VEX)", 2023.
[i.22] CycloneDX: "Vulnerability Exploitability eXchange (VEX)".
[i.23] OASIS (2025): "Common Security Advisory Framework Version 2.1".
[i.24] GitHub: "OpenVEX" March 10, 2026.
[i.25] NIST SP 800-161r1: "Cybersecurity Supply Chain Risk Management for Systems and
Organizations", Boyens, Jon M, 2022.
[i.26] CycloneDX: "Vulnerability Disclosure Report (VDR)".
[i.27] NIST: "OSCAL V1.2.0 Reference".
[i.28] Garcia, Jesus (06/09/2023): "EUROSCAL -Paving the Road towards Automated Cybersecurity
Certification in Europe (Whitepaper)".
[i.29] NIST SP 800-126r4 ipd: "Technical Specification for the Security Content Automation Protocol
(SCAP)", 2025.
[i.30] CVE Foundation: "Common Vulnerabilities and Exposures".
[i.31] NIST: "CCE Platform listing", 2015.
[i.32] NIST Interagency Report 7695: "Common Platform Enumeration: Naming Specification
Version 2.3", 2011, Cheikes, Brant, David Waltermire, and Karen Scarfon.
[i.33] FIRST Forum of Incident Response and Security Teams: "Common Vulnerability Scoring System:
Specification Document", 2023.
[i.34] NIST Interagency Report 7275 (Revision 4): "Specification for the Extensible Configuration
Checklist Description Format (XCCDF) Version 1.2", Waltermire, David, Charles Schmidt,
Karen Scarfone, and Neal Ziring.
[i.35] OVAL Community: "The OVAL Community Guidelines 5.12.2 Documentation", 2024.
ETSI
8 ETSI TR 104 285 V1.1.1 (2026-08)
[i.36] NIST Interagency Report 7694: "Specification for the Asset Reporting Format 1.1", Halbardier,
Adam, David Waltermire, and Mark Johnson.
[i.37] DOSS Project: "Deliverable D6.1 Integrated IoT Supply Chain Architecture", Marton, Anna,
2026.
[i.38] Matheu, S., & Skarmeta Gómez, A: "One Passport to Govern Them All: Bringing Order to IoT
Security and Compliance" In: Jo, H., Shin, S., Skarmeta, A., You, I. (eds.) Mobile Internet
Security. MobiSec 2025. Sapporo, Japan, December 16–18, 2025. Communications in Computer
and Information Science (CCIS), vol. 3053. Springer, Singapore (2026).
NOTE: Please note that at the time of publication of the present document, the specific paper in which the figure
appears is not yet publicly available, although a DOI has already been assigned.
[i.39] IETF RFC 4122 (July 2005): "A Universally Unique IDentifier (UUID) URN Namespace",
P. Leach, M. Mealling, R. Salz.
[i.40] NIST SP 800-53: "Security and Privacy Controls for Information Systems and Organizations".
[i.41] ISO/IEC 27001: "Information security, cybersecurity and privacy protection — Information
security management systems — Requirements".
3 Definition of terms, symbols and abbreviations
3.1 Terms
Void.
3.2 Symbols
Void.
3.3 Abbreviations
For the purposes of the present document, the following abbreviations apply:
ACL Access Control Lists
AI Artificial Intelligence
AP Assessment Plan
AR Assessment Results
ARF Asset Reporting Format
ASV Architecture Security Validator
BOM Bill Of Materials
CBOM Cryptography Bill Of Materials
CCE Common Configuration Enumeration
CISA Cybersecurity and Infrastructure Security Agency
CPE Common Platform Enumeration
CRA Cyber Resilience Act
CSA Cyber Security Act
CSAF Common Security Advisory Framework
CT Component Tester
CVE Common Vulnerabilities and Exposures
CVSS Common Vulnerability Scoring System
DCT Digital Cybersecurity Twin
DHCP Dynamic Host Configuration Protocol
DSP Device Security Passport
DSPP Device Security Passport Platform
DSS Data Security Standard
ETSI
9 ETSI TR 104 285 V1.1.1 (2026-08)
ECSO European Cyber Security Organisation
EUCS European Cybersecurity Certification Scheme for Cloud Services
genDSP generic DSP
HBOM Hardware Bill Of Materials
ICT Information and Communications Technology
ID Identifier
IDSP Instance-level DSP
IoT Internet of Things
IP Internet Protocol
IT Information Technology
JSON JavaScript Object Notation
LD Linked Data
MBOM Manufacturing BOM
MLBOM Machine Learning BOM
MSPL Medium-level Security Policy Language
MUD Manufacturer Usage Description
NIS2 Network and Information Systems Directive 2
NIST National Institute of Standards and Technology
NTIA National Telecommunications and Information Administration
OBOM Operations BOM
ObP Onboarding Platform
OSCAL Open Security Control Assessment Language
OVAL Open Vulnerability and Assessment Language
OWASP Open Worldwide Application Security Project
PCI Payment Card Industry
POA&M Plan of Actions and Milestones
PoC Proof of Concept
SaaSBOM Software-as-a-Service BOM
SBOM Software Bill Of Materials
SCAP Security Content Automation Protocol
SDLC Software Development Life Cycle
SDN Software Defined Network
SP Special Publication
SPDX Software Package Data Exchange
SSP System Security Plan
SWID Software Identification
URL Uniform Resource Locator
UUID Universally Unique Identifier
VDR Vulnerability Disclosure Report
VEX Vulnerability Exploitability Exchange
XCCDF Extensible Configuration Checklist Description Format
XML Extensible Markup Language
YAML Yet Another Markup Language
YANG Yet Another Next Generation
4 State of the art of device descriptors
4.1 Bill of Material (BOM)
4.1.1 Introduction
A Bill Of Materials (BOM) is a structured inventory listing all components, subcomponents, and materials required to
build, deploy, and operate a product or system. BOMs provide transparency, traceability, and risk management across
software, hardware, and cyber-physical supply chains.
ETSI
10 ETSI TR 104 285 V1.1.1 (2026-08)
There are several specialized BOM types. Software BOMs (SBOMs) [i.4] capture software components and
dependencies; Hardware BOMs (HBOMs) [i.5] enumerate physical components and assemblies; and Cryptography
BOMs (CBOMs) [i.6] track cryptographic assets such as keys, certificates, and algorithms. Other BOMs serve more
specialized contexts:
• Machine Learning BOMs (MLBOM) [i.7] cover models, datasets, and training pipelines;
• Manufacturing BOMs (MBOMs) [i.8] document production and assembly processes;
• Operations BOMs (OBOMs) [i.9] describe configurations and operational systems; and
• Software-as-a-Service BOMs (SaaS-BOMs) [i.10] represent cloud-based applications and services.
This clause focuses on SBOMs, HBOMs, and CBOMs, as they constitute the generic, basic BOMs applicable across
most digital systems. Understanding these three types provides the basis for supply chain transparency, security, and
compliance, while specialized BOMs extend these principles to domain-specific use cases.
4.1.2 Software Bill of Material (SBOM)
A Software Bill Of Materials (SBOM) [i.4] is a comprehensive and structured inventory that details all the components
used to build and support a software product. It includes libraries, modules, frameworks, and dependencies, as well as
machine learning models and datasets that may be embedded in or required for the software to operate. By providing
clear visibility into the internal composition of software, an SBOM enhances transparency, strengthens security and
compliance, and supports operational reliability throughout the software lifecycle.
The EU Cyber Resilience Act (CRA), Article 3, Section 37 [i.1], defines an SBOM as "a formal record containing
details and supply chain relationships of components included in the software elements of a product with digital
elements." This formal definition underscores its importance as a foundational mechanism for establishing trust,
traceability, and accountability in the software supply chain. An SBOM allows organizations to understand exactly what
their software is made of - from open-source components to proprietary code - and provides essential insights into
vulnerabilities, license obligations, and component provenance. This transparency enables development, operations, and
security teams to identify and mitigate risks efficiently while maintaining compliance with evolving regulatory and
industry standards.
Typically, an SBOM is generated during the build phase of the Software Development Life Cycle (SDLC), capturing an
exact snapshot of all components that make up a given release. This snapshot represents not only the dependencies and
libraries compiled into the final product but also the metadata required to verify their integrity, origin, and security
posture. The process of creating an SBOM generally involves identifying all software components, associating them
with relevant metadata such as version, license, and supplier information, and representing this data in a standardized
format that enables interoperability between systems and tools. Once generated, the SBOM is shared with stakeholders -
developers, vendors, auditors, and regulators - to promote transparency and facilitate collaboration across the supply
chain.
Modern development and security pipelines have integrated SBOM generation as an automated task, ensuring that each
software build produces a verifiable and up-to-date record of its composition. These SBOMs can then be consumed by
vulnerability scanners, compliance systems, and asset management tools to detect known weaknesses or license
conflicts. Because software components evolve over time, maintaining an accurate SBOM requires continuous updates
as dependencies change, versions are upgraded, or outdated elements are removed. This ongoing maintenance ensures
that the SBOM remains a reliable reference for both operational and security management.
The structure and representation of SBOMs follow internationally recognized standards designed to ensure consistency,
interoperability, and auditability. According to the U.S. National Telecommunications and Information Administration
(NTIA) [i.4], the three primary and interoperable SBOM formats are: ®
• Software Package Data Exchange (SPDX ), standardized as ISO/IEC 5962 [i.11], which provides a
comprehensive framework for documenting license obligations, verifying security attributes, and improving ®
supply-chain transparency. SPDX defines key mandatory fields such as package name, version, license,
supplier, and cryptographic checksum, enabling reliable identification and verification of software
components.
ETSI
11 ETSI TR 104 285 V1.1.1 (2026-08)
• CycloneDX [i.12], developed by the OWASP Foundation, is optimized for application security and supply-
chain risk management. It supports detailed representation of components, dependencies, licenses, and known
vulnerabilities, and is extensible to specialized domains such as SaaSBOMs (for cloud services), HBOMs (for
hardware), and ML-BOMs (for machine learning artifacts).
• Software Identification (SWID) Tags, standardized as ISO/IEC 19770-2 [i.13], complement these formats by
providing machine-readable metadata to identify installed software in enterprise environments.
While all three standards fulfil the core principles of transparency and interoperability, their scope and expressiveness
differ. SPDX is widely used in compliance and licensing contexts, CycloneDX is favoured for vulnerability and risk
management, and SWID tags excel in enterprise asset tracking and inventory use cases.
In practice, the SBOM has evolved into a key enabler of cybersecurity, compliance, and digital trust. It functions
simultaneously as a technical artifact, a governance mechanism, and a regulatory instrument. By providing a verifiable
record of software composition and provenance, SBOMs allow organizations to accelerate vulnerability remediation,
ensure legal and licensing conformity, and strengthen the integrity of their digital products. As software supply chains
grow in complexity and regulatory expectations intensify, the SBOM stands as a foundational mechanism for sustaining
the resilience, transparency, and accountability of the digital ecosystem.
4.1.3 Hardware Bill of Material (HBOM)
A Hardware Bill Of Materials (HBOM) [i.5] is a formal, structured inventory that lists every physical component,
subassembly, and material used in the manufacture of a product, along with the way these components are physically
connected or assembled. Each entry in the HBOM typically includes metadata such as component name, supplier or
vendor, part number or type, version or revision identifier, manufacturing details, and references to external
documentation (for example, datasheets, mechanical drawings, or compliance certifications). Beyond simple listing, an
HBOM may also capture relationships e.g. how each component is packaged, mounted, or electrically/structurally
interconnected in the final assembly.
As modern systems increasingly integrate hardware, firmware, and software, the HBOM complements and interacts
with the SBOM to provide full-stack visibility across the digital and physical layers of a product. This alignment
enables comprehensive supply chain intelligence, facilitating the identification of dependencies, vulnerabilities, and
compliance risks throughout the system lifecycle.
The HBOM plays a crucial role in supply chain management. By maintaining a precise inventory of hardware
components, organizations can ensure that all parts are properly sourced, validated, and tracked. This traceability is
fundamental in detecting counterfeit or malicious parts, identifying vulnerable or obsolete components, and managing
supply disruptions. Without an HBOM, it becomes challenging to trace the origins or lineage of hardware components,
which can pose significant security and reliability risks, especially in critical systems such as telecommunications,
infrastructure, medical devices, or industrial control systems.
HBOMs also assist with obsolescence management, by flagging components approaching end-of-life or becoming
unsupported. They support warranty and liability resolution, by providing clarity on which components are in use and
how they were connected. In sustainability and circular economy efforts, HBOMs help with component reuse,
recycling, and material traceability, allowing organizations to plan for disassembly, end-of-life recycling, or ecological
compliance obligations. HBOM data can be used to demonstrate compliance with governmental or industry sourcing
regulations, such as restrictions on materials from certain regions, use of conflict minerals, or manufacturing origin
requirements.
In terms of standardization and interoperability, two complementary frameworks currently guide HBOM
implementation. The CycloneDX specification [i.12], developed by the OWASP Foundation, extends its established
SBOM data model to incorporate hardware components as part of its "xBOM" family. This unified schema allows the
same machine-readable format to describe hardware, firmware, and software elements, ensuring consistency and
facilitating integration across tools and ecosystems. CycloneDX HBOM supports the representation of hardware
components, firmware images, configurations, and their interconnections, and it provides mechanisms such as BOM-
Link for cross-referencing between related BOMs (for example, linking an HBOM to its corresponding SBOM).
In parallel, the U.S. Cybersecurity and Infrastructure Security Agency (CISA) has developed the HBOM Framework for
Supply Chain Risk Management [i.5], which provides a taxonomy of hardware data elements, a set of recommended
naming conventions, and practical guidance on how HBOM data should be structured and exchanged. CISA's
framework defines several use-case categories such as compliance, security, and supply availability, and specifies
which subsets of data fields are relevant to each. It emphasizes consistency, interoperability, and repeatability, ensuring
that HBOMs from different suppliers can be compared and integrated effectively across the supply chain.
ETSI
12 ETSI TR 104 285 V1.1.1 (2026-08)
4.1.4 Cryptography Bill of Material (CBOM)
A Cryptography Bill Of Materials (CBOM) [i.6] is a structured, machine-readable model designed to identify, manage,
and track cryptographic assets and their dependencies within a system. It provides a comprehensive inventory of
cryptographic components, including algorithms, keys, certificates, protocols, and associated libraries, as well as
metadata necessary to verify their origin, validity, and compliance with security policies.
The CBOM serves as a foundation for cryptographic risk management. By mapping the relationships between
cryptographic assets and their dependent components, it enables organizations to assess risks, detect vulnerabilities, and
ensure that cryptographic implementations adhere to applicable standards and regulatory requirements. This visibility is
particularly critical for maintaining compliance with evolving cybersecurity policies and for supporting the transition to
post-quantum cryptography.
A key feature of the CBOM is its ability to distinguish between "implements" dependencies (e.g. the libraries or
modules that implement cryptographic algorithms and "uses" dependencies), the applications or components that rely
on those algorithms. This distinction allows organizations to understand not only which algorithms are present, but also
how they are applied across different parts of the system, improving accuracy in risk assessments, vulnerability
analysis, and compliance reporting.
The CBOM plays a central role in enabling cryptographic agility. By providing visibility into all cryptographic
implementations, organizations can quickly identify and replace weak, deprecated, or vulnerable algorithms, rotate
expired keys, update certificates, and deprecate unsafe protocols. CBOM also facilitates ongoing management of
cryptographic policies, ensuring that all assets comply with internal and external security standards, industry best
practices, and regulatory guidance.
In terms of standardization and integration, the CBOM is designed as an extension of the CycloneDX SBOM standard
[i.12]. Using CycloneDX's BOM-Link mechanism, an external CBOM or a subset of its components can be referenced
in an SBOM, establishing traceability between cryptographic elements and the software or hardware systems that use
them. This modular approach enables CBOMs to be maintained independently while remaining connected to broader
software or system supply chain representations, supporting holistic governance, auditability, and lifecycle
management.
By adopting CBOMs, organizations gain an actionable framework to manage cryptographic risk, ensure alignment with
security policies, and prepare for future cryptographic transitions. CBOMs complement other supply chain artifacts,
such as SBOMs and HBOMs, enabling end-to-end visibility of software, hardware, and cryptographic dependencies
across complex digital systems.
4.2 Manufacturer Usage Description (MUD)
The Manufacturer Usage Description (MUD) is an IETF standard specification (IETF RFC 8520 [i.14]) introduced in
2019 to bolster the security of Internet of Things (IoT) devices. MUD aims to reduce the attack surface of IoT devices
by providing a standardized method for manufacturers to communicate the expected network behaviour of their devices.
MUD uses a JSON-based structure that details the device's expected communication patterns and network access
requirements. When a device connects to a network, it provides a MUD URL embedded in the device firmware, DHCP
options, or X.509 certificates. This URL points to the MUD file, typically hosted by the manufacturer or a trusted third
party. The network's MUD manager retrieves the MUD file, translates it and enforces the described policies via the
network's security infrastructure, such as firewalls or SDN controllers. Policies described in the MUD file are enforced,
limiting the device's access to only necessary resources. If the MUD file is updated, the network can adjust the policies
dynamically to reflect the changes.
ETSI
13 ETSI TR 104 285 V1.1.1 (2026-08)
In particular, the network behaviour is expressed in the form of policies or Access Control Lists (ACLs) based on the
Yet Another Next Generation (YANG) standard [i.15]. The MUD model is composed of two main containers: "mud"
and "acls". The first one specifies high level information about the MUD profile, such as the MUD URL in which the
MUD file is located (field "mud-url"), when it expires ("cache-validity"), when it was created ("last-update"), and its
version ("mud-version"), as well as information about the device, such as the model ("model-name") and
firmware/software revision ("firmware-rev", "software-rev"). Finally, this container enumerates the ACLs restricting the
communications from/to the device, "to-device-policy" and "from-device-policy". Then, the second container describes
the details of the ACLs. Although the definition of the ACLs is based on the YANG data model for network ACLs, it
has been augmented by the MUD standard to define more expressive restrictions. For example, the terms
"manufacturer" and "same-manufacturer" enable the definition of policies to allow or deny the interaction with devices
from the same manufacturer. Other fields allow referencing network components (e.g. "controller" or "local-networks")
without the need to know the associated IP addresses.
Beyond the basic functionalities defined in IETF RFC 8520 [i.14], MUD has been extended to address more specialized
requirements. For instance, IETF RFC 9761 [i.16] extends the MUD specification to incorporate (D)TLS profile
parameters, enabling network security services to detect unexpected (D)TLS usage that may indicate unauthorized
software or malware on an endpoint. IETF RFC 9472 [i.17] introduces an extension to MUD that allows manufacturers
to specify how SBOM can be retrieved. Broader extensions have been proposed in the context of EU projects such as
CERTIFY [i.18], where a module incorporating Medium Security Policies Language (MSPLs) [i.19] was introduced
into the MUD f
...