In May 2021, a ransomware attack on a single fuel pipeline shut down gas supply across the US Eastern Seaboard, and a few months earlier the SolarWinds breach had already shown that a single poisoned software update could reach 18,000 organizations, including nine federal agencies. Regulators responded with a policy tool that had spent a decade in obscurity: the Software Bill of Materials. Executive Order 14028, signed on May 12, 2021, gave SBOMs their first real legal teeth in the United States. Since then, the EU, UK, Japan, South Korea, and India have each built their own version of the requirement, on their own timelines, with their own formats and enforcement mechanisms. The result is not a global standard — it is a patchwork. A vendor selling into five countries today may face five different definitions of what an SBOM even has to contain, and three different deadlines for producing one.
What actually forced SBOMs out of niche compliance and into law?
Two events compressed a decade of slow standards work into eighteen months: SolarWinds (discovered December 2020) and the Colonial Pipeline attack (May 2021). Both exposed the same blind spot — organizations had no inventory of what third-party and open-source code their critical software actually contained, so when a component turned out to be compromised, nobody could tell quickly whether they were exposed. Executive Order 14028, "Improving the Nation's Cybersecurity," directed NIST and NTIA to define a baseline, and NTIA published its "Minimum Elements for an SBOM" in July 2021, specifying data fields (supplier name, component name, version, dependency relationships, timestamp), operational practices, and support for existing formats like SPDX and CycloneDX. That single document became the reference point nearly every subsequent regulation, in every country, has cited or adapted.
Which governments have turned SBOM guidance into binding law?
Three jurisdictions have moved past guidance into enforceable requirements, each with a different mechanism and deadline. In the US, OMB Memorandum M-22-18 (September 2022) requires federal software vendors to attest to secure development practices, and agencies including CISA now request SBOMs as part of that attestation; separately, the FDA has required SBOMs for medical device premarket submissions since October 1, 2023, under Section 524B of the FD&C Act. In the EU, the Cyber Resilience Act entered into force in December 2024 after formal adoption in October 2024, and it explicitly requires manufacturers of "products with digital elements" to generate an SBOM covering top-level dependencies as part of essential cybersecurity requirements — with most obligations applying from December 2027, giving industry a roughly three-year transition window. Japan's METI issued SBOM introduction guidance in July 2023 for critical industries, and South Korea's KISA has piloted SBOM requirements in its software safety program. None of these three regimes uses identical language for "minimum elements," which means a document that satisfies NTIA's definition does not automatically satisfy the EU CRA's.
Why does adoption look so different depending on where you operate?
Adoption tracks two things closely: how directly a sector touches critical infrastructure, and how mature its national procurement apparatus is. In the US, federal contractors and medical device makers are furthest along because the FDA and DoD have hard deadlines tied to specific submission gates — a device maker literally cannot get FDA clearance without an SBOM attached to the application. In the EU, adoption is still mostly voluntary in practice even though the CRA is law, because the multi-year transition period means enforcement penalties (fines of up to €15 million or 2.5% of global turnover under the CRA) don't bite until 2027. Outside the US, EU, Japan, and South Korea, formal SBOM mandates are largely absent. India's CERT-In has issued advisories referencing SBOMs but no binding requirement; Singapore, Australia, and Brazil have discussed SBOMs in national cybersecurity strategies without codifying them into law. Smaller software vendors in these regions frequently produce their first SBOM only when a US or EU customer demands one contractually — meaning the regulation is being exported through procurement contracts faster than it's being adopted through domestic legislation.
What happens to a vendor that ignores an SBOM mandate?
The immediate consequence is almost always loss of a specific deal or contract, not a direct fine, because most SBOM regimes today enforce through procurement gates rather than general-purpose penalties. A medical device company without an SBOM cannot clear FDA premarket review under Section 524B — the submission is administratively incomplete, not just non-compliant. A software vendor bidding on a US federal contract without an M-22-18 attestation and supporting SBOM is typically excluded before technical evaluation even starts. The EU CRA is the outlier: once its penalty provisions become enforceable in 2027, market surveillance authorities can levy fines up to €15 million or 2.5% of global annual turnover (whichever is higher) for non-compliant products already placed on the market, independent of any single contract. That shift — from "you didn't win this bid" to "your product can be pulled from the EU market and you're fined a percentage of global revenue" — is why compliance teams in Europe are treating 2027 as a hard wall rather than a distant deadline.
Is there even agreement on what format an SBOM should be in?
Not fully, though two formats have absorbed nearly all real-world adoption: SPDX (an ISO/IEC 5962:2021 standard, maintained by the Linux Foundation) and CycloneDX (maintained by OWASP, with a design bias toward security use cases like vulnerability exploitability exchange). NTIA's minimum elements guidance is deliberately format-agnostic and accepts both, as does the EU CRA. In practice this means a company can be fully compliant with the letter of two different regulations while producing SBOMs that a downstream partner's tooling can't parse without a conversion step, because SPDX and CycloneDX model relationships and licensing metadata differently. A third format, SWID tags (ISO/IEC 19770-2), still shows up in some legacy government contexts but has lost ground to the other two. For companies operating across US, EU, and Japanese markets simultaneously, the practical answer has become: generate in one canonical format and maintain automated conversion, rather than trying to author natively in whichever format a given regulator prefers.
What should a security or compliance team actually do in the next 12 months?
The immediate priority is inventorying which of your products already fall under a binding deadline, because the US and EU windows are moving faster than most roadmaps assume. If you sell software to US federal agencies, M-22-18 attestation is already being requested in RFPs today, not in some future cycle. If you make medical devices, Section 524B has applied since October 2023 — any submission without an SBOM will bounce. If you sell into the EU, the CRA's December 2027 enforcement date sounds distant, but generating accurate SBOMs retroactively for a large existing product portfolio routinely takes 12-18 months, which means 2026 is the realistic start date for CRA readiness work, not 2027. Teams that wait for enforcement to start before building the pipeline typically discover their build systems can't produce accurate, automated SBOMs on demand — they can produce a plausible-looking document once, manually, which satisfies nobody at scale.
How Safeguard Helps
Safeguard is built for exactly this fragmented regulatory landscape — where the same product may need to satisfy NTIA's minimum elements for a US federal buyer, the EU CRA's essential requirements for a European customer, and FDA Section 524B for a medical device submission, all from the same underlying build. Safeguard generates SBOMs automatically at build time in both SPDX and CycloneDX formats, so teams aren't forced to choose one format and retrofit the other later. It continuously maps each component in the SBOM against known vulnerability data, so the document isn't a static artifact produced once for a compliance checkbox but a living record that flags new exposure the moment a dependency is found to be vulnerable. For teams managing multi-region compliance, Safeguard tracks which regulatory regime applies to which product line and surfaces gaps against each jurisdiction's specific field and format requirements, rather than treating "SBOM" as a single undifferentiated deliverable. And because retroactive SBOM generation across a large legacy portfolio is the single biggest reason teams miss deadlines like the EU CRA's 2027 enforcement date, Safeguard is designed to backfill SBOM coverage across existing products without requiring a rebuild of every pipeline from scratch — turning a multi-year manual project into something a compliance team can actually finish on schedule.