How the new SBOM standard is transforming software supply chain management and why it is critical for your CRA compliance
Bitsea GmbH · July 2026 · Reading time: approx. 8 minutes
Introduction: A Standard in Transition
The Software Bill of Materials (SBOM) has evolved from a niche topic into a regulatory requirement over the past few years. With the EU Cyber Resilience Act (CRA), a machine-readable software inventory is becoming a prerequisite for bringing products with digital elements to the European market. Organizations that develop, distribute, or integrate software can no longer ignore SBOM requirements.
At the same time, the most important SBOM standard continues to evolve: SPDX (System Package Data Exchange), maintained under the umbrella of the Linux Foundation and internationally recognized as ISO/IEC 5962, is taking its next major step forward with version 3.1. The first Release Candidate (SPDX 3.1-RC1) was published at the end of January 2026, with the final release expected later this year.
At Bitsea, we have closely followed the development of SPDX 3.x from the beginning — and we have continuously aligned Curator Pro, our platform for SBOM management, license compliance, and vulnerability management, with the new data model.
In this article, we explain what SPDX 3.1 brings to the table, what it means for organizations in practice, and how Curator Pro helps you navigate this transition with confidence.
From Documents to Knowledge Graphs: What SPDX 3.x Changes at Its Core
To understand where SPDX 3.1 is heading, it is worth taking a brief look back. SPDX 2.x — still the most widely used version in practice today — is built around a document-centric approach: an SPDX document acts as a self-contained “envelope” describing a collection of packages, files, and snippets.
This works well for the traditional use case of “one SBOM per release”, but it reaches its limits when information from multiple sources needs to be combined, tracked across different versions, or referenced at a more granular level.
SPDX 3.0 (released in April 2024) fundamentally redesigned this architecture. The new model is element-based: every element — whether a package, file, vulnerability, person, or organization — exists independently, carries a globally unique identifier, and is connected to other elements through typed relationships. A flat software inventory becomes a knowledge graph. The model is further enhanced through profiles that organize the data model around specific use cases: Core, Software, Licensing, Security, Build, AI, Dataset, and Lite. SPDX 3.1 continues this evolution and significantly expands the standard beyond software alone.
The Key New Features in SPDX 3.1
The SPDX 3.1 Release Candidate (3.1-RC1) clearly shows the direction of travel: SPDX is evolving into a universal BOM standard for entire systems. The major enhancements include:
Hardware Profile (HBOM): For the first time, SPDX 3.1 can natively describe hardware components. For manufacturers of embedded systems, IoT devices, and products with digital elements — precisely the target group addressed by the Cyber Resilience Act (CRA) — software and hardware bills of materials can be represented within a single, consistent model.
A single element can also take on multiple roles simultaneously, for example representing a hardware chip while also serving as the carrier of a cryptographic algorithm.
Supply Chain Profile: Supply chain events such as transportation, handovers, and provenance records become part of the standard. This brings SPDX closer to what regulations such as the CRA and NIS2 actually require: transparency across the entire supply chain — not just visibility into the source code.
Safety / Design Assurance: Requirements and safety evidence (in the context of functional safety) can be modeled as elements and linked to components. This is particularly relevant for industries such as automotive, aerospace, medical technology, and industrial automation.
Cryptography and CBOM: SPDX 3.1 introduces a curated list of more than 130 verified cryptographic algorithms, following a methodology similar to the established SPDX License List.
For organizations preparing for post-quantum migration and comprehensive cryptographic asset inventory, this represents an important foundation: the Cryptography Bill of Materials (CBOM) gains a strong foundation within the SPDX ecosystem.
AI Transparency: The AI/Dataset Profile is expanded with three new element types that are essential for modern AI systems: AI Agent, Prompt, and RAG (Retrieval-Augmented Generation). This enables organizations to document how an AI system is built — from traditional models and generative AI to agent-based architectures. With the EU AI Act introducing transparency obligations, these capabilities provide a glimpse into the next generation of compliance requirements.
Services: Services can now also be described — including dependencies such as SaaS components — representing an important step toward a SaaSBOM.
Important Planning Consideration: The 3.1-RC1 release is explicitly intended for testing and validation. Individual features may still change before the final release. However, the core model — elements, relationships, and profiles — is stable and already supports production-level architectural decisions today.
What Does This Mean for Your Organization?
From a management perspective, three key implications emerge:
1. SBOM Becomes System BOM. The era in which an SBOM was simply a list of open-source packages is coming to an end. Regulators and customers increasingly expect a complete picture: software, hardware, cryptography, AI components, and supply chain information.
Organizations that continue to design their processes and tools around a simple “package list per release” approach are creating technical debt.
2. The Lifecycle Becomes the Focus. An SBOM is not a static document — it is a living artifact. It is created during the build process, enriched through scanning, linked with vulnerability data (VEX/VDR), updated with every release, and must remain traceable and informative over many years. The CRA introduces support period requirements and reporting obligations that simply cannot be fulfilled without properly maintained and versioned BOM data.
The graph-based model of SPDX 3.x is the technical answer to exactly this challenge.
3. Interoperability Becomes a Key Selection Criterion. In practice, organizations will encounter SPDX 2.3, SPDX 3.x, and CycloneDX side by side. Your suppliers will provide SBOMs based on what their existing tools support. A future-ready SBOM management platform must therefore be able to import, consolidate, and export all relevant formats — in the format required by your customers or your notified body.
Curator Pro: Built for the BOM Lifecycle According to SPDX 3.x
This is exactly where Curator Pro comes in.Our platform was not designed as a document repository for SBOM files. Instead, it was built as a BOM lifecycle management system based on an element-based graph model — architecturally aligned with the way SPDX 3.x represents the world.
Element Graph Instead of File Storage. Curator Pro stores components, licenses, vulnerabilities, and their relationships as a graph within a multi-tenant PostgreSQL architecture.
Components are uniquely identified and deduplicated through Package URLs (PURLs) — the same library used across twenty products becomes a single knowledge object, not twenty separate copies.Changes to assessments, license classifications, or vulnerability status are therefore applied consistently across the entire product portfolio.
Complete BOM Lifecycle Management. From generation, import, and enrichment — including scanner integrations with ScanCode.io and FOSSology and vulnerability data from open sources — through curation, review, and approval, all the way to export, archival, and compliance evidence: Curator Pro manages the entire BOM lifecycle — documented, traceable, and audit-ready.
Integrated CRA Compliance. Curator Pro includes a dedicated CRA compliance module with a control catalog that structures and maps the requirements from: Annex I (Part I and Part II) reporting and documentation obligations under Articles 13 and 14
technical documentation requirements under Annex VII SBOM, VEX/VDR, and vulnerability management are not separate silos. Instead, they are interconnected building blocks of a comprehensive compliance evidence framework.
SPDX 3.1 Readiness. Our approach to BOM lifecycle management is already aligned with the SPDX 3.x element model. We are currently validating the SPDX 3.1 Release Candidate against our data architecture, with the goal of supporting SPDX 3.1 import and export capabilities when the final release becomes available.
For our customers, this means: You can continue working productively today with SPDX 2.3 and CycloneDX — and evolve with the standard over time, without data migration projects or tool replacement.
Roadmap Beyond SBOM. The enhancements introduced in SPDX 3.1 align closely with our product roadmap: SBOM combined with VEX/VDR forms the foundation for CRA compliance
CBOM (Cryptography Bill of Materials) is the next expansion area in development
AI-BOM and SaaSBOM will follow in the medium term. With Kurt, the integrated AI assistant within Curator Pro, we also support compliance teams with analysis and assessment workflows — while maintaining clear data control and governance rules.
Practical Recommendations for the Transition
What should you do now? Based on our experience from real-world projects, we recommend the following:
Assess Your Current State: Which SBOM formats and versions are you currently producing and receiving? SPDX 2.3 will remain widely used for a long time — plan for coexistence, not a hard migration.
Prioritize Processes Over Formats: First, define your BOM lifecycle: generation, enrichment, approval, maintenance, archival. Also define clear ownership and responsibilities. The format is ultimately an output decision.
Evaluate Graph Capabilities: Ask your tooling providers how they handle the element-based model of SPDX 3.x. Organizations that only manage files internally will not be able to leverage the full potential of the new standard.
Evaluate RC1 — But Do Not Force It Into Production Yet: Use the Release Candidate for testing, validation, and architectural decisions.Production commitments toward customers should be based on the final SPDX 3.1 release, not on a pre-release version.
Keep CRA Deadlines in Focus: The CRA reporting obligations and full applicability timeline are approaching faster than many organizations expect. A robust SBOM and vulnerability management infrastructure is the foundation for meeting these requirements — regardless of when SPDX 3.1 reaches final release status.
Conclusion
SPDX 3.1 marks the transition of the SBOM from a simple software inventory to a system knowledge graph: hardware, supply chain information, cryptography, and AI become part of a shared standard.
For organizations subject to the Cyber Resilience Act (CRA), this is positive news — provided that their tools and processes are able to evolve alongside the standard.
Curator Pro was built from the beginning with exactly this future in mind: an element-based graph model, complete BOM lifecycle management, integrated CRA compliance, and format flexibility — supporting everything from SPDX 2.3 and CycloneDX to SPDX 3.x.
We are actively following and contributing to the standard’s evolution throughout the Release Candidate phase, ensuring that our customers are ready when the final release becomes available.
Would you like to understand how your organization can approach the transition to SPDX 3.x and meet CRA requirements in practice? Contact us — we would be happy to demonstrate Curator Pro in a personalized demo.