Two years ago, SBOM requirements were aspirational guidance. Today, they are contractual obligations, regulatory mandates, and procurement requirements with real enforcement mechanisms. The challenge for organizations operating globally is keeping track of which requirements apply, what they demand, and when compliance is expected.
This article provides a practical overview of the major SBOM-related mandates active or approaching enforcement as of late 2025.
United States
Executive Order 14028 and CISA Guidance
The foundation for US SBOM requirements remains Executive Order 14028 (May 2021), which directed NIST and CISA to develop SBOM guidance for federal software procurement.
Who it applies to: Any organization selling software to the US federal government, including SaaS providers, commercial off-the-shelf software vendors, and custom development contractors.
What is required:
- SBOM generation for software sold to federal agencies.
- SBOMs must conform to NTIA minimum elements (supplier name, component name, version, dependency relationship, unique identifier, timestamp, author).
- SBOM delivery to the purchasing agency.
- Ongoing vulnerability monitoring and notification for components listed in the SBOM.
Enforcement: Procurement language. Federal agencies are increasingly including SBOM requirements in contracts and RFPs. Non-compliance can affect contract eligibility.
CISA Secure Software Development Attestation
Building on EO 14028, CISA's attestation form requires software producers to attest to secure development practices aligned with the NIST Secure Software Development Framework (SSDF).
Who it applies to: Software producers selling to federal agencies (critical software first, then all software).
What is required:
- Attestation that the organization follows SSDF practices.
- Specific attestation items include maintaining SBOMs, vulnerability disclosure processes, and secure build environments.
- Attestation forms signed by a company executive.
Status: Mandatory for critical software, extending to all software sold to federal agencies. The CISA attestation form is a living document that may be updated.
FDA Cybersecurity Requirements (Medical Devices)
The FDA now requires cybersecurity documentation, including SBOMs, for premarket submissions of medical devices with software components.
Who it applies to: Medical device manufacturers seeking FDA approval for devices containing software.
What is required:
- SBOM for all software components, including third-party and open source components.
- Vulnerability management plan.
- Security architecture documentation.
- Plans for post-market cybersecurity updates.
Enforcement: Premarket review. Devices without adequate cybersecurity documentation, including SBOMs, face delays or rejection in the approval process.
European Union
Cyber Resilience Act (CRA)
The CRA is the most comprehensive product cybersecurity regulation globally, and SBOMs are a core requirement.
Who it applies to: Manufacturers of products with digital elements sold in the EU market. This includes software products, IoT devices, and connected hardware. Open source software developed in a non-commercial context has a specific exemption, though the boundaries of this exemption remain debated.
What is required:
- SBOM generation and maintenance for all products with digital elements.
- Vulnerability handling processes including coordinated disclosure.
- Security updates for the expected product lifetime (minimum 5 years for most products).
- Incident reporting to ENISA within 24 hours for actively exploited vulnerabilities.
- Conformity assessment (self-assessment for most products, third-party assessment for critical products).
Timeline: The CRA entered into force in late 2024. Manufacturers have a transition period through 2027 for full compliance, but vulnerability reporting obligations begin earlier.
Enforcement: Market surveillance authorities in EU member states. Non-compliance can result in fines up to 15 million euros or 2.5% of global turnover.
NIS2 Directive
The Network and Information Security Directive 2 (NIS2) imposes cybersecurity obligations on essential and important entities across the EU.
Who it applies to: Organizations in critical sectors (energy, transport, health, digital infrastructure) and important sectors (manufacturing, food, chemicals, waste management).
What is required:
- Supply chain security risk management, which increasingly includes SBOM requirements for software procurement.
- Incident reporting within 24 hours.
- Risk management measures covering supply chain security.
Status: Member states are transposing NIS2 into national law. Implementation varies by country, but the supply chain security requirements consistently point toward SBOM adoption.
Japan
Ministry of Economy, Trade and Industry (METI) SBOM Guidance
Japan has been proactive on SBOM adoption, with METI publishing detailed guidance and running pilot programs.
Who it applies to: Initially focused on critical infrastructure sectors and government procurement. Expanding to broader commercial adoption.
What is required:
- SBOM generation following international standards (CycloneDX or SPDX).
- Integration of SBOMs into vulnerability management processes.
- SBOM sharing between suppliers and consumers in the software supply chain.
Status: Guidance-based rather than mandatory regulation, but government procurement is incorporating SBOM requirements, creating de facto mandates for government suppliers.
Other Jurisdictions
Australia
The Australian Cyber Security Strategy includes software supply chain security as a priority. SBOM requirements are emerging in government procurement and critical infrastructure regulations.
South Korea
South Korea's Personal Information Protection Commission and cybersecurity agencies are developing SBOM guidance, particularly for IoT devices and critical infrastructure software.
India
India's CERT-In has issued advisories on software supply chain security. Formal SBOM mandates are not yet in place, but the regulatory trajectory is clear.
United Kingdom
The UK's Product Security and Telecommunications Infrastructure (PSTI) Act focuses on IoT security. While it does not explicitly mandate SBOMs, the vulnerability disclosure and update requirements effectively require the component visibility that SBOMs provide.
Practical Compliance Guidance
Minimum Viable SBOM Program
For organizations facing multiple SBOM mandates, here is the minimum viable program:
-
Choose a format: CycloneDX or SPDX. Both are accepted by all major mandates. CycloneDX is generally easier to generate and consume programmatically. SPDX has deeper license documentation capabilities.
-
Automate generation: Integrate SBOM generation into your CI/CD pipeline so that every build produces an SBOM. Manual SBOM generation does not scale and introduces errors.
-
Include all components: Direct dependencies, transitive dependencies, build tools, and container base images. The NTIA minimum elements are the floor, not the ceiling.
-
Store and version: SBOMs should be stored alongside the software releases they describe and versioned consistently.
-
Monitor continuously: Generate SBOMs at build time, but also monitor them against vulnerability databases continuously. A new CVE disclosed six months after a release affects the SBOM generated at build time.
-
Distribute on request: Have a process for sharing SBOMs with customers, partners, and regulators. Some mandates require proactive sharing; others require sharing on request.
Common Compliance Gaps
The most frequent compliance gaps organizations discover:
Transitive dependencies missing. Many SBOM tools only capture direct dependencies. Regulators expect the full dependency tree.
Container base image components missing. If you ship containers, the SBOM must include the OS packages in the base image, not just your application dependencies.
No ongoing monitoring. Generating an SBOM at build time and filing it away does not satisfy mandates that require vulnerability notification for listed components.
No VEX capability. As VEX becomes expected alongside SBOMs, organizations that cannot communicate exploitability status will face questions from consumers and regulators.
How Safeguard.sh Helps
Safeguard automates the SBOM lifecycle end-to-end, from generation through monitoring and distribution. The platform generates CycloneDX and SPDX SBOMs that meet the requirements of all major mandates, including NTIA minimum elements, CRA requirements, and FDA guidance. Continuous monitoring against vulnerability databases ensures that new CVEs are correlated with existing SBOMs and flagged for response.
The platform's policy engine can be configured to enforce mandate-specific requirements -- for example, ensuring that all SBOMs include transitive dependencies, container base image components, and component hashes. For organizations navigating multiple overlapping mandates, Safeguard provides a single compliance baseline that satisfies the union of all applicable requirements.