ETSI 303 645: SBOM & AI Hardware Cryptography BOMs + VEX Boosts IoT Security and EU CRA Compliance

Executive Summary

IoT device security is under increasing scrutiny, with standards like ETSI EN 303 645 defining baseline cybersecurity requirements for consumer IoT. New regulations, such as the EU Cyber Resilience Act (CRA), are raising the bar for device makers. This article explores how various Bill of Materials (BOM) types – including Software BOMs (SBOMs), AI BOMs for artificial intelligence components, Hardware BOMs (HBOMs), and Cryptographic BOMs (CBOMs) – along with Vulnerability Exploitability eXchange (VEX) reports, help IoT manufacturers align with ETSI EN 303 645. We detail how each BOM and VEX contributes to meeting key provisions like vulnerability management and software updates, and how this alignment simultaneously supports compliance with the EU CRA’s cybersecurity and transparency requirements. A comparison table maps ETSI’s requirements to similar obligations in the CRA, illustrating that implementing BOM practices improves IoT device security and prepares organizations for emerging regulatory demands. The goal is to provide IoT product teams and cybersecurity professionals with a clear, practical guide to leveraging BOMs and VEX to bolster IoT device security and demonstrate regulatory compliance.

‍

Introduction: IoT Security Standards and Regulations

The rapid growth of IoT has led to heightened concerns about the security of connected devices. In response, standards bodies and regulators have acted. ETSI EN 303 645 (V3.1.3, 2024) is a widely recognized European standard outlining 13 baseline cybersecurity provisions for consumer IoT products. These range from basic measures (like no universal default passwords) to operational processes (such as handling vulnerability reports and providing software updates). Adhering to these guidelines helps manufacturers build secure products by design and be resilient against common threats.

In parallel, the European Union’s Cyber Resilience Act (CRA) was enacted in 2024 to impose mandatory cybersecurity requirements on products with digital elements. The CRA extends the principles of standards like ETSI EN 303 645 into law, requiring manufacturers to build security into products throughout their lifecycle and to maintain transparency about product components and vulnerabilities. Notably, the CRA explicitly mandates that manufacturers produce and maintain a Software Bill of Materials (SBOM) for their products. It also obliges organizations to swiftly address and report vulnerabilities, aligning with the best practices promoted by ETSI EN 303 645.

In this article, we examine how implementing various types of BOMs (SBOM, AI BOM, HBOM, CBOM) and using VEX can fulfill key cybersecurity, vulnerability management, and software update provisions of ETSI EN 303 645. We also explore how these practices map to and facilitate compliance with the EU CRA, reinforcing many of the same principles. By integrating detailed BOMs and VEX reports into their product security processes, IoT manufacturers can meet the ETSI baseline today and get ahead of forthcoming regulatory requirements under the CRA.

‍

SBOM: Software Transparency for Stronger Security and Updates

Software Bill of Materials (SBOM) is a foundational tool for IoT cybersecurity. An SBOM is essentially an inventory of all software components (open-source libraries, third-party packages, firmware, etc.) in a device’s software stack. Maintaining an SBOM helps manufacturers achieve software transparency, which is critical for both vulnerability management and software updates:

• Vulnerability Management: ETSI EN 303 645 emphasizes managing and patching known vulnerabilities. Provision 5.2 requires manufacturers to have a process to handle reported vulnerabilities and act on them promptly. To effectively identify which known vulnerabilities affect a product, an organization must know which software components (and their versions) the product contains. An SBOM provides this insight by identifying third-party components and their versions, allowing the manufacturer to monitor each component for disclosed vulnerabilities. ETSI’s guidance implicitly aligns with SBOM principles: it recommends maintaining a list of third-party software and tracking associated security risks. Using an SBOM, IoT vendors can quickly cross-reference their devices’ components against vulnerability databases and address any issues, thus fulfilling the standard's vulnerability monitoring and remediation expectations. This practice enhances the SBOM security posture by ensuring no known flaws are overlooked in any embedded software.
  
  
• Software Updates: “Keep software updated” is another core provision of ETSI EN 303 645. Manufacturers are expected to develop and deploy security updates to fix vulnerabilities throughout a defined support period. SBOMs support this by serving as a checklist of components that require updates. When a critical bug or exploitable vulnerability is found in a library, the SBOM tells you if your device firmware includes that library (and what version), so you can prioritize issuing a patch. ETSI EN 303 645 even states that all software components that are not immutable “should be securely updatable.” Maintaining an SBOM helps ensure that no component is forgotten during patch management. It also aids in verifying update integrity: since you know what components are supposed to be on the device, you can detect unauthorized or unexpected software. This contributes to ensuring software integrity and secure updates. This capability is essential for CRA compliance – the CRA requires manufacturers to address vulnerabilities and likely expects that no outdated, known-vulnerable software is shipped in products. An SBOM makes it practical to audit your product for such issues before release and throughout its life.
  
  
• Regulatory Transparency: The EU CRA explicitly mandates SBOMs. Manufacturers must “draw up an SBOM in a commonly used format covering at least the top-level dependencies” of the product. They aren’t required to share it publicly, but it must be included in technical documentation and provided to regulators upon request. By having an SBOM practice in place (as urged by ETSI and now required by CRA), organizations can smoothly generate the documentation needed for CRA compliance. In short, SBOM = compliance regarding the CRA’s transparency requirements. It’s worth noting that standards like SPDX and CycloneDX are commonly used SBOM formats and are expected to be referenced by the European Commission for SBOM format specifications, so using these formats now positions manufacturers ahead of the curve.
  
  

SBOMs thus directly contribute to meeting IoT security baseline requirements and legal obligations. They provide a single source of truth about software in the device. It is indispensable for SBOM vulnerability management – tracking vulnerabilities and ensuring timely fixes – and for enabling reliable, secure software update mechanisms.

‍

AI SBOM: Accounting for AI/ML Components in IoT Devices

As IoT devices grow more intelligent, many now incorporate artificial intelligence or machine learning components – for example, a smart camera with an AI-based object detection model. An AI Bill of Materials (AI SBOM) extends the SBOM concept to these AI/ML elements, cataloguing items like pre-trained models, machine learning libraries, neural network architectures, and even the datasets used for training when applicable.

While ETSI EN 303 645’s provisions do not explicitly mention AI, the standard’s spirit of comprehensive risk management applies to all device software, including AI algorithms. AI components can introduce unique security and ethical considerations (e.g., model vulnerabilities to adversarial attacks or biases in training data). Tracking them in an AI BOM ensures they are not overlooked in security evaluations. For instance, if an AI model relies on a specific framework version that later has a vulnerability or critical bug, the AI SBOM will help identify that and drive an update, similar to an SBOM for traditional software.

Cybeats, as an industry leader in SBOM management, has highlighted the importance of AI BOMs. Cybeats recently introduced capabilities to help customers creat, ingest and analyze AI BOMs, giving detailed insight into AI software components and their origins. 

Cybeats' COO Julia Cherry states, “AI SBOM provides a comprehensive solution to track and manage AI components, including models, datasets, and their provenance, ensuring enhanced security and transparency.” 

IoT manufacturers can manage risks associated with AI elements just as systematically as traditional software risks. In the context of compliance, AI BOMs align with emerging regulations on AI and security. While the EU CRA focuses on general product security (and would consider an AI library just another software component to be listed in the SBOM), the EU is also introducing the AI Act, which will require transparency about AI systems. The AI Act calls for information on AI systems' origin and supply chain. Thus, maintaining an AI BOM helps with ETSI security baseline and CRA requirements (by treating AI components as part of the software inventory for vulnerability management) and prepares organizations for AI-specific governance. In short, if your IoT device uses AI, an AI BOM ensures you inventory those AI/ML components and manage them under the same security update and vulnerability monitoring processes as the rest of your software. This is increasingly seen as best practice in IoT cybersecurity as AI becomes more prevalent.

‍

HBOM: Hardware Bill of Materials for Supply Chain Security

IoT devices, by definition, are physical objects, which means security isn’t only about software. Hardware components (chips, sensors, modules, etc.) can harbor firmware or design vulnerabilities or be subject to supply chain risks. A Hardware Bill of Materials (HBOM) is a detailed list of every physical component in a device, from the main CPU and wireless chipsets down to sensors and connectors. Maintaining an HBOM improves device security in several ways:

• Tracking Hardware Vulnerabilities: Hardware and firmware can have known vulnerabilities, like software. For example, a specific Wi-Fi chipset might have a known security flaw in its firmware. ETSI EN 303 645 includes provisions like minimizing exposed attack surfaces and ensuring the integrity of software/firmware – these implicitly cover cases where a hardware element could be exploited. With an HBOM, manufacturers can track each hardware element against vulnerability disclosures. The U.S. Cybersecurity and Infrastructure Security Agency (CISA) has even released an HBOM framework, underlining the importance of consistent hardware component naming and inventory for risk management. In practice, an HBOM lets an IoT maker ask: “Does my product contain any component from the list of parts with known defects or recalls?” and get an answer quickly. This extends vulnerability management to the hardware layer.
  
  
• Secure Supply Chain and Compliance: The EU CRA’s scope broadly covers products with digital elements. It requires manufacturers to consider cybersecurity across the entire product lifecycle and supply chain. Having an HBOM demonstrates due diligence in supply chain security – you know your suppliers and components. If a critical vulnerability in a specific microcontroller is announced, you can identify if you use it and coordinate a remedy (perhaps a firmware patch or a component change in the next product revision). While the CRA doesn’t explicitly demand an HBOM like it does an SBOM, regulators expect manufacturers to address all known risks. Documenting hardware components is increasingly seen as part of compliance evidence. In some industries (like automotive or medical devices), providing a parts list or HBOM is already a quality requirement; the CRA’s emphasis on security may drive similar expectations for IoT.
  
  
• Facilitating Updates and Patches: Some hardware components have updatable firmware. An HBOM can be cross-referenced with a firmware SBOM for those components, ensuring that if a vulnerability is found in the Bluetooth module’s firmware, the device maker can work with that module vendor to get a patch and distribute it. This ties back to ETSI’s “keep software updated” mandate, which includes firmware as part of software. One ETSI provision suggests that if software cannot be updated, the manufacturer must publish the rationale or provide hardware replacement options. Knowing which hardware might need replacement (if it’s unpatchable) is guided by the HBOM.
  
  

In summary, an HBOM complements the SBOM by covering the physical side of an IoT product. It contributes to cybersecurity for connected devices by ensuring transparency into the device’s hardware composition, aligning with baseline security best practices and strengthening compliance with regulations that demand a proactive stance on all potential vulnerabilities (software or hardware). IoT security is a chain – HBOM helps secure the links that SBOM doesn’t cover.

‍

CBOM: Managing Cryptography in Devices

Many IoT security failures stem from weaknesses in cryptography – e.g., use of outdated encryption algorithms or mismanaged keys. A Cryptographic Bill of Materials (CBOM) is an emerging concept aimed at cataloguing all cryptographic elements in a product, including the algorithms, libraries, certificates, and keys (typically their metadata, not the secret keys themselves) used by the device. By maintaining a CBOM, manufacturers gain visibility into exactly what cryptographic primitives their device relies on. This is crucial for complying with provisions like “communicate securely” and “securely store sensitive security parameters” in ETSI EN 303 645.

• Ensuring Strong Cryptography: ETSI EN 303 645 requires that devices use state-of-the-art security for communications and data. For example, no hard-coded insecure credentials, and encryption should be applied where appropriate. A CBOM provides transparency into cryptographic assets in the device, allowing manufacturers to assess if any algorithm is deprecated or weak. According to the CycloneDX project (which supports CBOMs in its BOM standard), a CBOM “provides transparency into cryptographic assets like algorithms, keys, and certificates” and helps assess resilience against deprecated algorithms. If your IoT firmware uses an outdated TLS 1.0 library or an MD5 certificate signature, the CBOM will flag that so you can upgrade to meet modern standards. This directly supports compliance with ETSI’s secure communications mandate and positions the product to meet CRA requirements, since the CRA will likely expect state-of-the-art crypto as well (the CRA’s essential requirements call for protecting the confidentiality and integrity of data and communications).
  
  
• Crypto Agility and Updates: Cryptography is an area where new vulnerabilities are discovered (e.g., a breakthrough attack on an algorithm, or the eventual threat of quantum computing). Having a CBOM means you know where a vulnerable algorithm is used in your product. This makes responding to cryptographic vulnerabilities or required upgrades (such as moving from SHA-1 to SHA-256, or increasing key lengths) much more manageable – you won’t miss an instance. It complements the SBOM in the sense that while an SBOM might tell you which library is used (and that library’s version), the CBOM goes deeper into which algorithms within that library are in play. For compliance, this level of detail can be important. For example, a future harmonized standard under the CRA might require listing cryptographic controls in the technical documentation. A CBOM would satisfy that in an organized way.

In essence, CBOMs (Cryptographic BOMs) ensure that security-critical elements like cryptographic implementations are tracked and managed rigorously like other components. This helps meet specific provisions of ETSI EN 303 645 on secure communications and data protection, and it further strengthens compliance with the CRA by covering an area that regulators care deeply about (cryptography). It’s another piece of the puzzle in making IoT devices trustworthy.

‍

VEX: Prioritizing Vulnerabilities with CycloneDX/SPDX VEX Reports

Finding out that your SBOM has 100 listed vulnerabilities can be overwhelming – not all vulnerabilities pose a risk in a given device context. This is where VEX (Vulnerability Exploitability eXchange) comes into play. A VEX is a specialized report, often in machine-readable format (JSON or XML), that indicates whether specific vulnerabilities are exploitable in the context of a product. Both CycloneDX and SPDX – the leading SBOM standards – support VEX information. In practice, a VEX document will list known vulnerabilities (e.g., CVE IDs) and declare their status for the product: “affected”, “not affected”, “fixed”, “under investigation”, etc., along with justifications.

‍

How VEX Contributes to Security Compliance:

• Effective Vulnerability Management: ETSI EN 303 645’s vulnerability management provision isn’t just about having a policy; it’s about taking action and informing stakeholders. A VEX helps manufacturers communicate the status of vulnerabilities in their product to internal teams, downstream customers, or authorities. For instance, if your SBOM shows a library with a known CVE but your device doesn’t use the vulnerable function, a VEX can note that this CVE is not exploitable (status “not affected”). This level of insight aligns with the ETSI goal of addressing vulnerabilities without unnecessary delay – you focus on what truly matters. It also aligns with “examine system telemetry data” and monitoring provisions (ETSI provision 5.10) in spirit, since you’re essentially monitoring vulnerability context as part of system health.
  
  
• Prioritizing Patches: Not all vulnerabilities are equal. VEX allows organizations to prioritize remediation by filtering out false positives or irrelevant issues. CycloneDX’s VEX documentation highlights that understanding real-world impact is essential. VEX focuses on whether a vulnerability can “actually be exploited in its specific context”, helping prioritize responses and reduce unnecessary efforts. This means your engineering resources can concentrate on patching the critical, exploitable flaws first, precisely the kind of risk-based approach standards and regulators want to see. Both ETSI and the CRA care about the timely fixing of vulnerabilities – VEX is a tool that ensures timely fixes are applied to the right issues.
  
  
• Communication and Trust: Under the EU CRA, incident reporting obligations and potentially requirements are required to inform users about product vulnerabilities and updates. VEX documents can be a machine-readable way to share vulnerability status with customers or regulators. For example, a manufacturer could publish a VEX alongside firmware release notes to declare which CVEs have been addressed and which CVEs were not applicable. This improves transparency and trust. CycloneDX VEX is already used in some contexts to automate security notifications. SPDX is also developing ways to represent vulnerability status. The key is that VEX, being in a standard format, can integrate with security tools. For example, a security operations or TPRM teams can automatically ingest a supplier’s VEX to update their risk dashboard. This efficiency is recognized as an advantage of VEX: it “reduces unnecessary patching by focusing on exploitable vulnerabilities”, leading to streamlined vulnerability management processes.
  
  
• Compliance Mapping: While ETSI EN 303 645 does not mention VEX (the concept gained popularity after the standard’s early versions), using VEX is a proactive way to exceed the standard’s requirements. It demonstrates that the manufacturer has an SBOM, monitors for CVEs, and goes the extra mile to analyze exploitability. This could be very relevant for CRA compliance audits. The CRA demands that manufacturers consider the state of the art and risks, provided that VEX shows a sophisticated handle on risk assessment of vulnerabilities. It could also potentially satisfy any CRA requirement for status reporting on vulnerabilities (e.g., if an authority or a customer asks, “Are you affected by CVE-XXXX-YYYY?”, a VEX is a ready answer).
  
  

In summary, VEX (CycloneDX or SPDX) is the companion to SBOM that brings context to vulnerabilities. It answers the crucial question: “Do I need to worry about this vulnerability in my product?” By integrating VEX into their process, IoT device makers can more effectively meet the vulnerability monitoring and notification requirements of standards like ETSI EN 303 645 and regulations like the CRA. It turns SBOM data into actionable intelligence, ensuring compliance efforts translate into real, improved end-user security.

Diagram: Relationship of SBOM, AI BOM, HBOM, CBOM, and VEX in an IoT device context. BOMs provide transparency into components, while VEX provides vulnerability context. They support compliance with ETSI EN 303 645 and the EU CRA.

‍

Mapping ETSI EN 303 645 Provisions to EU CRA Requirements (Table)

To illustrate the synergy between ETSI’s IoT security guidelines and the EU Cyber Resilience Act, the following table maps key requirements related to SBOMs, vulnerability management, and software updates from ETSI EN 303 645 to analogous requirements in the EU CRA. This comparison highlights how implementing BOMs and VEX not only satisfies the standard but also addresses the CRA's regulatory obligations.

‍

Conclusion

The evolving landscape of IoT security standards and regulations makes it clear that device makers must invest in visibility and proactive management of their product components. ETSI EN 303 645 provides a strong baseline for IoT device security, and its key themes – like eliminating default passwords, handling vulnerability reports, and keeping software updated – are echoed and reinforced by the EU Cyber Resilience Act. BOMs and VEX are practical tools that operationalize these themes:

• SBOMs illuminate all software in a device, enabling continuous monitoring for new threats and smooth updates. This approach addresses the relevant requirements and provisions in ETSI’s best practices and the CRA’s SBOM.
  
  
• AI BOMs ensure that the increasing use of AI in devices does not create blind spots in security or compliance – everything is inventoried, even machine learning models.
  
  
• HBOMs extend that visibility to hardware, supporting supply chain security and covering an area that standards like ETSI touch upon (secure components, minimize risk) that the CRA expects manufacturers to control.
  
  
• CBOMs zero in on cryptographic components, which are the backbone of secure communications. They help meet encryption requirements and adapt quickly when cryptography needs updating.
  
  
• VEX provides context to vulnerability data, allowing manufacturers to communicate and prioritize vulnerability remediation in line with real risk – a practice that shows regulators you’re not just generating SBOMs and alerts, but actively managing and mitigating threats.
  
  

Incorporating these elements results in a comprehensive security posture where an IoT company can confidently say: “We know exactly what’s in our product, we know where our risks lie, and we have processes to address them promptly.” This is precisely the outcome envisioned by ETSI’s cybersecurity standards for consumer IoT, which the EU’s Cyber Resilience Act now demands.

By aligning BOM and VEX practices with ETSI EN 303 645, manufacturers enhance their IoT cybersecurity (making products safer and more trustworthy) and create a solid foundation for regulatory compliance. As the CRA and similar laws come into effect globally, organizations that have embraced SBOMs and related tools will find themselves well-prepared to meet new legal requirements with minimal friction. Ultimately, it’s a win-win: better security management today, and easier compliance tomorrow, leading to more resilient IoT ecosystems and greater trust from consumers and partners.

‍