Navigating SBOM Compliance: Requirements, Regulations, and What’s Next
Software is no longer built in isolation; it’s assembled from thousands of components, dependencies, and services that span open source and proprietary ecosystems. That complexity has introduced new risks, particularly across the software supply chain, where a single vulnerable component can ripple across entire organizations and industries.
That’s where Software Bills of Materials (SBOMs) come in. Much like an ingredient list on food packaging, SBOMs provide a detailed inventory of the components that make up a piece of software. Over the past several years, SBOMs have evolved from a “nice-to-have” transparency tool into a cornerstone of modern cybersecurity strategy, driven largely by high-profile supply chain attacks and increasing regulatory pressure.
Today, SBOM requirements are no longer theoretical. Governments, standards bodies, and industry regulators are actively defining what SBOM compliance looks like… and who is expected to meet those standards. Understanding these requirements is critical not just for compliance, but for maintaining trust, security, and operational resilience in an increasingly interconnected digital ecosystem.
Who is required to use SBOMs?
The short answer: not everyone is explicitly required to use SBOMs—yet. But that’s quickly changing.
Currently, SBOM requirements are most clearly defined in:
- Government procurement (especially in the U.S. and EU)
- Regulated industries (e.g., finance, healthcare, critical infrastructure)
- Organizations selling software to public sector entities
For example, U.S. federal agencies and their vendors are increasingly expected to provide SBOMs as part of secure software development practices, particularly following Executive Order 14028. Similarly, companies operating in or selling to the European Union must prepare for SBOM-related requirements under the Cyber Resilience Act.
Even where SBOMs are not yet mandated, they are rapidly becoming table stakes for doing business, particularly for organizations that:
- Build or distribute software products
- Integrate third-party or open source components
- Operate in security-sensitive environments
In other words, SBOM adoption is moving from compliance-driven to expectation-driven, and organizations that wait for mandates may already be behind.
Learn about the role that SBOMs play in the security of your organization in this white paper.
SBOM Laws & Regulatory Requirements
SBOM compliance spans a growing mix of legislation, executive orders, and industry guidance. While not all policies explicitly mandate SBOMs, many strongly encourage—or effectively require—them as part of broader software supply chain security practices.
NTIA Minimum Required Elements
Before diving into specific laws and regulations, it’s important to understand what actually qualifies as an SBOM. The most widely accepted baseline comes from the NTIA Minimum Elements for an SBOM, published in 2021 as part of a multi-stakeholder effort to standardize software transparency.
Rather than mandating SBOM usage, this guidance defines the minimum information and capabilities an SBOM must include to be useful, establishing a shared foundation across industries and regulatory frameworks.
At a high level, NTIA groups these “minimum elements” into three core areas…
- Data fields (e.g., component name, version, supplier)
- Automation support (machine-readable, scalable generation)
- Practices and processes (how SBOMs are created, updated, and shared over time)
Learn more about SBOM formats and elements.
Key SBOM Laws & Regulations
Below is a high-level overview of key SBOM-related regulations and initiatives:
| Policy/Legislation | Region | Applies to… | SBOM Requirement Level | Deadline |
| Cyber Resilience Act (CRA) | European Union | Manufacturers, importers, and distributors of products with digital elements sold in the EU | Required | Sept 2026 (reporting), Dec 2027 (full compliance) |
| Digital Operational Resilience Act (DORA) | European Union | Financial institutions and ICT service providers | Recommended / implied | Jan. 2025 |
| PCI DSS v4.0 | Global | Organizations that store, process, or transmit cardholder data | Recommended / implied | March 2025 (full enforcement) |
| NIST Secure Software Development Framework (SSDF) | United States (global influence) | Software developers and organizations adopting secure development practices | Recommended | Ongoing |
EU Cyber Resilience Act (CRA)
Region: European Union
Applies to:
- Manufacturers of products with digital elements (software and hardware)
- Importers and distributors within the EU
- Organizations placing products on the EU market under their brand
SBOM Requirement Level: Required
Key Dates and Deadlines:
- September 2026: Reporting obligations begin
- December 2027: Full compliance required
The EU Cyber Resilience Act (CRA) is one of the most comprehensive and enforceable cybersecurity regulations to date and the first to explicitly require SBOMs at scale. It applies broadly to any product with digital elements sold in the EU, regardless of where it is developed. Organizations must provide machine-readable SBOMs and maintain visibility into vulnerabilities across the entire product lifecycle.
Beyond SBOMs, the CRA introduces strict requirements for secure-by-design development, vulnerability disclosure, and ongoing monitoring. It also includes significant financial penalties for noncompliance, making it clear that software transparency is no longer optional. For many organizations, the CRA is setting the global benchmark for SBOM compliance and driving earlier adoption even ahead of enforcement deadlines.
See the official documentation: https://digital-strategy.ec.europa.eu/en/policies/cyber-resilience-act
Learn more about SBOMs and the EU CRA.
Digital Operational Resilience Act (DORA)
Region: European Union
Applies to:
- Financial institutions (banks, insurers, investment firms)
- ICT service providers supporting financial entities
SBOM Requirement Level: Recommended/implied
Key Dates and Deadlines:
- January 2025: Compliance required
DORA focuses on strengthening the operational resilience of the financial sector, with a strong emphasis on managing third-party and ICT risks. While it does not explicitly mandate SBOMs in the same way as the CRA, it reinforces many of the same principles, particularly around software transparency, dependency tracking, and supply chain risk management.
For organizations operating in financial services, this creates an implicit requirement to adopt SBOM-like practices. Financial entities must be able to identify, assess, and monitor risks associated with third-party software providers, which is difficult—if not impossible—without detailed visibility into software components. As a result, SBOMs are increasingly used as a practical tool for achieving DORA compliance and demonstrating due diligence.
See the official documentation: https://www.eiopa.europa.eu/digital-operational-resilience-act-dora_en
Learn more about DORA’s impact on SBOMs.
Payment Card Industry Data Security Standard (PCI DSS)
Region: Global
Applies to:
- Organizations that store, process, or transmit cardholder data
- Merchants, payment processors, and service providers
SBOM Requirement Level: Recommended/implied
Key Dates and Deadlines:
- March 2022: PCI DSS v4.0 released
- March 2024: Initial transition deadline
- March 2025: Full enforcement of new requirements
PCI DSS is one of the most widely adopted security standards globally, governing how organizations protect payment card data. While it does not explicitly require SBOMs, version 4.0 introduces stronger expectations around software inventory, vulnerability management, and secure development practices—all of which closely align with SBOM capabilities.
For example, PCI DSS v4.0 requires organizations to:
- Maintain an inventory of system components and software
- Identify and address vulnerabilities in third-party and custom code
- Implement secure development and change management processes
In practice, SBOMs provide a scalable way to meet these requirements, particularly in environments with complex dependencies and frequent updates. As a result, many organizations are adopting SBOMs not because PCI DSS explicitly mandates them, but because they make PCI compliance more achievable, auditable, and efficient.
See the official documentation: https://www.pcisecuritystandards.org/standards/pci-dss/
Learn more about SBOMs’ role in PCI DSS 4.0
NIST Secure Software Development Framework (SSDF)
Region: United States (global influence)
Applies to:
- Software developers and vendors (especially those working with U.S. federal agencies)
- Organizations adopting secure software development best practices
SBOM Requirement Level: Recommended
Key Dates and Deadlines:
- February 2022: NIST SP 800-218 (SSDF) finalized
- Ongoing: Referenced in federal procurement and compliance frameworks
The NIST Secure Software Development Framework (SSDF) provides a structured set of best practices for integrating security throughout the software development lifecycle. Developed in response to Executive Order 14028, the SSDF outlines how organizations should build, test, and maintain secure software, emphasizing areas like secure coding, vulnerability management, and supply chain transparency.
Although the SSDF is not a law, it functions as a de facto standard for secure software development, particularly in government and regulated environments. SBOMs play a key role in enabling SSDF-aligned practices by providing the visibility needed to track components, assess risk, and respond to vulnerabilities. As a result, organizations aligning with SSDF are often implicitly adopting SBOM generation and management as part of their broader security strategy.
See the official documentation: https://csrc.nist.gov/projects/ssdf
How SBOM Expectations Are Converging Globally
Although SBOM regulations vary by region, there’s a clear trend toward convergence. Across the U.S., EU, and beyond, emerging policies share several common themes:
- Transparency: Organizations must know what’s in their software
- Standardization: Machine-readable formats like SPDX and CycloneDX are becoming the norm
- Lifecycle management: SBOMs are not static—they must be continuously updated
- Vulnerability response: SBOMs are tied directly to faster, more effective remediation
For organizations operating internationally, this convergence is both a challenge and an opportunity. While compliance requirements may differ slightly, investing in robust SBOM practices now can help satisfy multiple regulatory frameworks simultaneously.
The Future of SBOM Compliance
The software industry is entering a new era of compliance. What was once treated as optional documentation is quickly becoming an operational requirement, with governments, regulators, and customers all expecting greater visibility into software supply chains.
SBOM compliance is still evolving, but the direction is clear: more requirements, more enforcement, and higher expectations for automation, accuracy, and continuous visibility.
In the coming years, we can expect:
- Broader mandates across industries beyond government and finance
- Increased enforcement mechanisms, including penalties for non-compliance
- Greater integration of SBOMs into procurement, risk assessment, and incident response workflows
- More industry-specific requirements shaped by the products organizations build, the markets they serve, and the environments they operate in
Perhaps most importantly, SBOMs will become less about “checking a box” and more about enabling real-time security and operational intelligence.
As compliance requirements become embedded throughout the software lifecycle, organizations will increasingly need a “Compliance Operations” (or “CompOps”) mindset that treats compliance as an ongoing operational discipline rather than a periodic audit exercise.
The Role of Artificial Intelligence and Machine Learning
As SBOM datasets grow in size and complexity, manual processes simply won’t scale.
Organizations are already exploring ways to automate vulnerability correlation across SBOM components, prioritize risk based on exploitability and business impact, and identify anomalies across increasingly complex software supply chains.
Rather than replacing SBOMs, AI and automation will help organizations operationalize them at scale, transforming software inventories into more actionable security intelligence.
Future-Proofing Your SBOM Operations
If there’s one takeaway from the current regulatory landscape, it’s this: reactive compliance won’t cut it.
Organizations also need to recognize that SBOM compliance will not look the same across every industry, product, or market. Requirements are already diverging across sectors like healthcare, finance, critical infrastructure, and the public sector, making flexibility and automation increasingly important.
To stay ahead, organizations should focus on:
- Automating SBOM generation: Integrate SBOM creation directly into CI/CD pipelines
- Standardizing formats: Use widely accepted standards like SPDX or CycloneDX
- Maintaining continuous visibility: Treat SBOMs as living documents, not one-time outputs
- Aligning with broader security frameworks: Ensure SBOM practices support SSDF, vulnerability management, and threat intelligence efforts
Organizations that invest early in scalable SBOM operations won’t just be better prepared for compliance requirements. They’ll also be better positioned to build trust, respond to emerging threats, and adapt as software supply chain regulations continue to evolve.
End-to-End SBOM Management & Compliance Automation
Meeting SBOM requirements is one thing. Operationalizing them at scale is another. That’s where Anchore comes in.
Anchore provides end-to-end SBOM management and compliance automation, helping organization generate and manage SBOMs across their software supply chain, continuously monitor for vulnerabilities, enforce policy and compliance requirements, and so much more.
Organizations ranging from government agencies to global enterprises rely on Anchore to bring structure, automation, and confidence to their SBOM initiatives—transforming compliance from a burden into a strategic advantage.
Whether you’re just getting started or scaling mature SBOM operations, Anchore helps ensure you’re not just compliant today, but ready for what’s next.
Learn more
Download the White Paper
How to use SBOMs to strengthen the security of your software supply chain for cloud-native applications
