DOSS has developed an integrated architecture to strengthen security throughout the IoT lifecycle. The components support structured security information exchange based on the Device Security Passport, automated component testing, system-level security modelling, compliance assessment and secure device deployment, while multiple DOSS specifications have also contributed to ETSI publications.
INTEGRATED ARCHITECTURE
DOSS Supply Trust Chain
Connecting cybersecurity information and assurance throughout the IoT lifecycle.
The DOSS Supply Trust Chain (STC) provides the overarching framework for exchanging and using security information throughout the IoT lifecycle. It connects manufacturers, system integrators, operators and security services, enabling security information to accompany products as they move through the supply chain. Through the STC, DOSS modules can share security evidence, assessment results and updated information, supporting continuous trust rather than security assessment at a single point in time.
Architecture:
Resources:
The challenge
Security information is fragmented across manufacturers, suppliers, integrators and operators, reducing transparency as products move through complex supply chains.
The DOSS approach
Explain the end-to-end secure communication framework.
How the Supply Trust Chain works
- Security information is represented through the Device Security Passport (DSP).
- Components are security-tested.
- Architectures are modelled and tested in the Digital Cybersecurity Twin (DCT).
- Security requirements are assessed through Architecture Security Validator (ASV).
- Devices are securely onboarded.
- Operational findings can feed security information back into the chain.
The DOSS prototype uses the DSP Platform as the secure integration point for DSPs and security evidence.
Key capabilities
- Controlled security information exchange
- Traceability across the lifecycle
- Automated testing and validation integration
- Security feedback
- Secure access to security evidence
The challenge
Security information about connected products is currently distributed among SBOMs, vulnerability records, hardware information, network policies, test reports and multiple repositories.
The DOSS approach
Explain the OSCAL-based DSP and its role as the structured point of access to this information.
What information can a DSP contain?
- SBOM
Software composition - HBOM
Hardware composition - CBOM
Cryptographic assets - MUD
Expected network behaviour - VEX / VDR
Vulnerability information - Security assessment information
Testing and lifecycle evidence
The DSP concept has contributed to ETSI TR 104 285 – Device Security Passport.
SPECIFICATION & DATA MODEL
Device Security Passport
A machine-readable security record accompanying an IoT product throughout its lifecycle.
The Device Security Passport (DSP) is a machine-readable representation of the security information associated with an IoT device. Based on OSCAL, the DSP brings together security information such as SBOM, HBOM, MUD, VEX/VDR and other security descriptors into a structured lifecycle-oriented model.
DOSS defines generic and instance-level DSPs and uses them to make security information available across manufacturing, system integration and operation.
The DSP framework:
Resources:
SPECIFICATION & DATA MODEL
Component Tester
Finding vulnerabilities before components become part of an IoT system.
The Component Tester creates an integrated environment for automated security testing of IoT software and firmware. It combines multiple techniques to identify vulnerabilities, validate findings and verify whether security patches effectively address detected weaknesses.
Overview of the DOSS Component Tester:
Resources:
The challenge
Explain that vulnerabilities can originate in open-source, third-party, firmware or internally developed software.
The DOSS approach
Integrated security testing environment.
How it works
Component
↓
Static analysis
↓
Dynamic / fuzz testing
↓
Interactive validation
↓
Patch validation
↓
Structured security report
↓
Device Security Passport
Testing capabilities
- Static analysis
- Dynamic testing
- Interactive testing
- Firmware fuzzing
- Patch validation
Key capabilities
- Earlier detection
- Reduced false positives
- Evidence of exploitability
- Patch verification
- Machine-readable results
- Integration into DevSecOps
The Component Tester methodology has contributed to ETSI TR 104 287 – Security Validation Methodology for IoT Components
.
The challenge
Component-level testing cannot reveal every weakness created by interactions between components.
The DOSS approach
Virtual system-level cybersecurity testing environment.
How it works
1. Build system model
↓
2. Retrieve component security information
↓
3. Identify impactful attack goals
↓
4. Generate attack trees and test cases
↓
5. Execute attacks in the digital twin
↓
6. Analyse weaknesses and recommend countermeasures
Key capabilities
- Attack-tree generation
- Automated test generation
- Vulnerability scanning
- Penetration testing
- Impact analysis
- Remediation recommendations
The DCT examines how vulnerabilities interact and how attacks can affect critical system functions rather than assessing vulnerabilities only in isolation.
SYSTEM SECURITY MODELLING
Digital Cybersecurity Twin
Testing attacks against a virtual system before they reach the real one.
A virtual representation of an IoT system that enables security testing before deployment. The DCT identifies impactful attack scenarios, generates attack trees and executable tests, performs automated vulnerability scanning and penetration testing, and recommends measures to address discovered weaknesses.
This corresponds directly to the implemented DCT workflow: retrieving component DSP information, determining attack goals, generating attack trees and executable tests, running them in a virtual environment and producing remediation recommendations.
Overview of the DOSS Digital Cybersecurity Twin:
Resources:
COMPLIANCE & ASSURANCE
Architecture Security Validator
Turning cybersecurity requirements into continuous, traceable architecture assessment.
The Architecture Security Validator (ASV) platform enables the semi-automated validation of IoT architectures against cybersecurity standards and requirements. It transforms security standards into machine-readable requirements, combines automated evidence with expert assessment and produces traceable compliance results.
The current ASV implementation combines the Digital Transformation Module, Automated Assessment Module and CyberPass, with DCT-generated evidence feeding automated compliance assessment and expert review handling requirements that cannot be validated automatically.
The Architecture Security Validation Process:
Resources:
The challenge
Standards and regulatory documents are primarily written for humans and compliance assessment remains labour-intensive.
The DOSS approach
Automated/semi-automated assessment and pre-certification platform.
How it works
The three implemented ASV components:
DIGITAL TRANSFORMATION MODULE
Standards → structured requirements
↓
AUTOMATED ASSESSMENT MODULE
Requirements + evidence → assessment
↓
CYBERPASS
Expert review where automation cannot make the decision
↓
Traceable compliance result
Key capabilities
-
AI-assisted standard transformation
-
Machine-readable security requirements
-
Automated evidence evaluation
-
Human-in-the-loop validation
-
Quantified compliance assessment
-
Traceability
DCT-generated security evidence can be associated with individual requirements and consumed by the Automated Assessment Module.
The DOSS methodology for transforming standards into structured requirements contributed to ETSI TS 104 286 – Digital Transformation of Security Standards into Requirements
The challenge
Traditional onboarding authenticates and provisions a device, but security policies may only be applied afterwards.
The DOSS approach
Integrate FIDO Device Onboard + DSP so that security information can be retrieved and security policy applied as part of onboarding.
How it works
NEW DEVICE
↓
FDO authentication / ownership transfer
↓
Retrieve Device Security Passport
↓
Interpret device security information
↓
Translate security policy
↓
Apply policy
↓
Operational network access
The DOSS approach specifically enables policy enforcement before operational access rather than leaving a gap after credential provisioning.
Key capabilities
- Zero-touch provisioning
- DSP integration
- Security-policy deployment
- FDO-based onboarding
- Lifecycle-aware security configuration
- Reduced deployment time
SECURE DEPLOYMENT
Secure Onboarding Platform
From trusted device identity to security-aware network access.
The DOSS Secure Onboarding Platform combines secure device onboarding with security information contained in the Device Security Passport. Building on FIDO Device Onboard, it enables devices to be authenticated, provisioned and subjected to appropriate security policies before they receive operational network access. This supports automated deployment while helping ensure that newly introduced devices comply with the security requirements of their target environment.
The Secure Onboarding Platform Architecture:
Resources:
DOSS Results Published in ETSI Documents
Three ETSI documents – two Technical Reports and one Technical Specification – based on research and technical results developed within the DOSS project have been published, bringing key project concepts and methodologies into the European standardisation landscape.
ETSI TR 104 285
Device Security Passport
ETSI TS 104 286
Digital Transformation of Security Standards into Requirements
ETSI TR 104 287
Security Validation Methodology for IoT Components
These documents are available for download from the ETSI website:
ETSI TR 104 285: Device Security Passport
ETSI TS 104 286: Digital Transformation of Security Standards into Requirements
ETSI TR 104 287: Security Validation Methodology for IoT components
