With the rapid proliferation of IoT technologies, security concerns have increased due to the opaque nature of supply chains. Operators often lack comprehensive knowledge about the security status of their devices. The DOSS project addresses this gap by providing a system that facilitates transparency, reliability, and timely security information exchange among stakeholders of the IoT supply chain, including manufacturers, vendors, and integrators.

DOSS integrates various security modules, including a component tester, a digital cybersecurity twin, and an architecture security validator. These modules work together to test software and hardware, identify vulnerabilities, and ensure compliance with security standards.

How is OSCAL being used in DOSS?

In the DOSS project, OSCAL has been chosen as the foundation for building the Device Security Passport (DSP), one of the key components of DOSS architecture.  Unlike OSCAL itself, which provides generic models for documenting controls and assessments, the DSP applies and adapts these models to a specific purpose: ensuring transparency and traceability of device security across the entire supply chain. It serves as a machine-readable document and consolidates all available security related information of an IoT component, providing a structured and easily accessible format for all relevant parties. The DSP integrates descriptors such as SBOMs, HBOMs, CBOMs, MUD profiles, and vulnerability disclosures into an OSCAL-inspired structure, ensuring that all this information can be linked, versioned, and audited. Some OSCAL models, like the POA&M, have been simplified or extended, while new fields have been introduced to capture transparency requirements of the EU Cyber Resilience Act (CRA). In this way, OSCAL serves as the technical backbone, and the DSP builds on top of it to deliver a concrete solution for digital products.

DSPs are created by manufacturers and exist in three primary forms:

1. Generic DSP (genDSP) – Contains manufacturer-related information, security posture, product composition, and operational details. It follows established standards, is signed for authenticity, and is stored in the DSP Platform (DSPP). Some sections are publicly available, while other parts of the document require authorization.
2. Instance Level 1 DSP (IDSP1) – Provides specific instance-level information about a product, such as unique identifiers and public keys. IDSP1 records are linked to genDSP files but do not duplicate their content.
3. Instance Level 2 DSP (IDSP2) – Extends IDSP1 with additional operation-related and proprietary information added by system integrators and operators. IDSP2 is stored locally by the operators.

DOSS and the European momentum around OSCAL

DOSS has shared its experience through knowledge-exchange activities, discussions and presentations, using the DSP as a reference case to illustrate how structured security information can support transparency and compliance.

This work has included engagement with the European Cybersecurity Competence Community (ECCO) and ECSO OSCAL task force, where DOSS presented the project and explained how OSCAL was used to develop the DSP in line with CRA-related transparency requirements. The project has also been engaged with the NIST OSCAL community, including OSCAL webinars, helping connect practical implementation experience with the wider development and adoption of OSCAL.

DOSS has actively participated in numerous events and knowledge-sharing activities alongside other European projects and cybersecurity stakeholders, fostering collaboration and raising awareness of OSCAL and its practical applications. These activities have included IoT Day webinars and roundtables, where DOSS showcased how the DSP can support device security, transparency and regulatory compliance.

Beyond these dissemination and knowledge-sharing activities, DOSS has also contributed directly to European standardisation. Building on its work on the Device Security Passport, the project has led to the development of ETSI TR 104 285 V1.1.1 (August 2026), Methods for Testing and Specification (MTS); Device Security Passport, providing a context in which the practical lessons learned through projects such as DOSS can inform wider discussions on how device security information should be structured and communicated.

Additional publications

DOSS’s work on the DSP was also disseminated through research publications and conference presentations, including:

• One Passport to Govern Them All: Bringing Order to IoT Security and Compliance – presented in the context of MobiSec 2025 and published in the revised selected papers.
• Model-Driven Approach to Secure Device Onboarding Using a Device Security Passport – published in Computer Modeling in Engineering & Sciences (2026).