Why Regulators Are Mandating SBOMs
The logic behind SBOM regulations is straightforward: modern software is overwhelmingly composed of open source and third-party components, yet most organizations have no systematic way to track what those components are, whether they are vulnerable, or what license obligations they carry.
The Log4Shell incident of December 2021 — a zero-day with a CVSS score of 10.0 affecting an estimated 88% of organizations — made this painfully visible at a global scale. Regulators concluded that voluntary adoption was not working, and began embedding SBOM requirements into binding law.
By early 2026, the regulatory landscape has moved from a single U.S. executive order to a multi-jurisdiction web of binding requirements. Here is what you need to know.
1. Executive Order 14028 (United States)
Signed by President Biden in May 2021, Executive Order 14028: Improving the Nation's Cybersecurity is the foundational U.S. federal mandate. It requires software vendors selling to the U.S. government to be able to provide an SBOM for any software product upon request, and to attest to a set of secure software development practices.
Who it applies to
Any company or developer that sells software products or services to U.S. federal government agencies. This includes commercial off-the-shelf (COTS) software, SaaS applications, and custom-developed software.
Key obligations
- Maintain an SBOM for all software delivered to federal customers
- Be able to provide that SBOM to agencies upon request
- Attest to secure software development practices via a self-attestation form
- Notify agencies of known vulnerabilities in delivered software
EO 14028 has been in effect since May 2021. OMB M-26-05 (January 2026) revised attestation memos to a risk-based framework, but the underlying SBOM and secure development requirements remain unchanged.
2. FDA Cybersecurity Guidance (United States)
The U.S. Food and Drug Administration requires SBOMs for all medical devices with cybersecurity components — defined as "cyber devices" — submitted for premarket approval. This requirement has been in effect since March 2023 and was updated with additional guidance in 2025.
Who it applies to
Manufacturers of any medical device that contains software, programmable logic, or connectivity to other devices or networks. This includes pacemakers, insulin pumps, infusion systems, diagnostic imaging equipment, and hospital software platforms.
Key obligations
- Submit an SBOM as part of the premarket 510(k) or PMA application
- Demonstrate a plan for monitoring, identifying, and patching vulnerabilities post-market
- Include all commercial, open source, and off-the-shelf software components
- Update the SBOM when significant software changes occur
3. EU Cyber Resilience Act (European Union)
The EU Cyber Resilience Act (CRA) entered into force in December 2024 and represents the most far-reaching software security legislation ever enacted. It applies to any product with digital elements sold in the EU market — essentially any connected device or software product.
Who it applies to
Manufacturers and importers of any hardware or software product with digital elements placed on the EU market. This includes IoT devices, operating systems, web browsers, consumer software, industrial control systems, and enterprise applications. Open source software used commercially is also covered under certain conditions.
Key obligations
- Maintain an SBOM for all software components in the product
- Report actively exploited vulnerabilities to ENISA within 24 hours
- Provide security support and updates for the product's expected lifetime (minimum 5 years)
- Conduct conformity assessments and affix CE marking for cybersecurity compliance
Timeline
- December 2024 — CRA entered into force
- September 2026 — Reporting obligations for vulnerabilities become applicable
- December 2027 — Full product requirements take effect
December 2027 sounds distant, but the supply chain and compliance infrastructure needed to comply — SBOM generation, vulnerability disclosure processes, CE marking — takes 18-24 months to implement properly. You need to start now.
4. PCI DSS 4.0 (Payment Card Industry)
PCI DSS 4.0, which took full effect in March 2025, introduces software component inventory requirements for organizations that develop bespoke or custom payment software. Requirement 6.3.2 specifically mandates that an inventory of all bespoke and custom software be maintained, including all third-party components.
Who it applies to
Any organization that develops, maintains, or deploys custom software in payment card processing environments. This includes banks, fintech companies, payment processors, and merchants who build their own checkout systems.
5. EU DORA (Financial Sector)
The Digital Operational Resilience Act (DORA), which became applicable in January 2025, requires EU financial entities to maintain detailed records of their ICT dependencies — a requirement that functionally necessitates SBOM-like software inventories. Affected entities include banks, insurance companies, investment firms, and critical ICT third-party providers.
The Compliance Deadline Summary
| Regulation | Jurisdiction | Who It Applies To | Key Date | Status |
|---|---|---|---|---|
| EO 14028 | United States | Federal software vendors | May 2021 | IN FORCE |
| FDA Cybersecurity | United States | Medical device manufacturers | Mar 2023 | IN FORCE |
| PCI DSS 4.0 | Global (card brands) | Payment software developers | Mar 2025 | IN FORCE |
| EU DORA | European Union | Financial entities | Jan 2025 | IN FORCE |
| EU CRA (reporting) | European Union | All digital products sold in EU | Sep 2026 | UPCOMING |
| EU CRA (full) | European Union | All digital products sold in EU | Dec 2027 | UPCOMING |
| South Korea mandate | South Korea | Public sector software | 2027 | UPCOMING |
How to Build a Compliance-Ready SBOM Program
Achieving SBOM compliance across multiple regulatory frameworks is not as complex as it sounds, because the underlying requirements converge on the same core capabilities:
- Automated SBOM generation — Generate SBOMs as part of every build, in SPDX or CycloneDX format.
- Continuous vulnerability monitoring — Cross-reference your SBOM against vulnerability databases and receive alerts when new CVEs affect your components.
- License compliance scanning — Detect license obligations and conflicts across all dependencies, including transitive ones.
- SBOM storage and versioning — Maintain a historical record of SBOMs for each product version — regulators may ask for historical data.
- Disclosure workflows — For EU CRA, you need a process to report actively exploited vulnerabilities within 24 hours.
Stay Compliant with Fossity
Fossity is designed for teams that need to meet multiple SBOM compliance requirements simultaneously. It generates SBOMs in SPDX and CycloneDX formats, continuously monitors for new vulnerabilities across your component inventory, enforces license policies, and maintains a full audit trail for regulatory reporting. Whether you are preparing for EO 14028, FDA submission, EU CRA, or PCI DSS 4.0, Fossity provides the evidence your compliance teams need.
Get Compliant with Fossity →The Cost of Non-Compliance
The consequences of failing to meet SBOM compliance obligations vary by framework but are uniformly severe:
- EO 14028 — Loss of federal contracts; potential debarment from government procurement
- FDA — Rejection of device submissions; mandatory recalls; civil and criminal penalties under the FD&C Act
- EU CRA — Market withdrawal orders; fines up to €15 million or 2.5% of global annual turnover (whichever is higher)
- PCI DSS — Loss of card processing privileges; fines from card brands; mandatory forensic audits
In 2026, the question is no longer whether to implement SBOM practices. The question is how quickly you can get there.