Three questions that separate a mandate from a recommendation
Most SBOM advice fails a simple test. It describes an obligation without saying where the obligation comes from, who inspects it, or what happens to a company that ignores it. Those three questions decide everything. Is there a statute, a regulation, or a signed contract behind the requirement? Is there a named party whose job it is to look at the artifact? And is there a consequence that lands on the supplier if the artifact is missing or wrong? A requirement that answers all three is enforced. A requirement that answers none is guidance, and guidance is worth reading but not worth budgeting against as though it were law.
The SBOM landscape in August 2026 contains a small number of items that pass all three tests and a large number that pass none. The gap between those two groups widened sharply over the past eighteen months, and much of the published advice on the subject has not caught up. Buyers are still writing SBOM clauses that cite rescinded policy. Suppliers are still budgeting for an attestation regime that no longer exists. Both mistakes are avoidable by reading the primary documents.
This piece separates the two groups by name and by date. It covers what changed in U.S. federal policy between January 2026 and March 2026, the two mandates that survived that change untouched because they never depended on it, and the technical baseline that was rewritten in July 2026 and now defines what a competent SBOM contains.
The federal attestation chain, and exactly where it broke
The chain started with Executive Order 14028, Improving the Nation's Cybersecurity, signed May 12, 2021. Section 4 of that order directed the government to require secure development practices from software suppliers. OMB implemented it through two memoranda, M-22-18, Enhancing the Security of the Software Supply Chain through Secure Software Development Practices, and its companion update M-23-16. Those memoranda required agencies to collect a self-attestation from software producers, built on NIST Special Publication 800-218, the Secure Software Development Framework. CISA published a common attestation form so producers would not face a different questionnaire from every agency. Under that regime an agency could also require an SBOM, though the form itself never made one mandatory.
Executive Order 14144 arrived January 16, 2025 and would have tightened the machinery considerably. Executive Order 14306, signed June 6, 2025, amended it and struck most of that tightening, replacing the attestation-validation provisions with a narrower set of NIST assignments: stand up a consortium at the National Cybersecurity Center of Excellence, update SP 800-53 guidance on deploying patches, and publish an updated Secure Software Development Framework.
Then the foundation went. OMB Memorandum M-26-05, Adopting a Risk-based Approach to Software and Hardware Security, dated January 23, 2026, rescinded M-22-18 and M-23-16 outright. Its stated reason is blunt: the earlier policy "imposed unproven and burdensome software accounting processes that prioritized compliance over genuine security investments." In their place, M-26-05 tells each agency to maintain a complete inventory of its software and hardware and to develop assurance policies matched to its own risk determinations. Agencies may use the attestation form. Agencies may adopt contract terms requiring a producer to supply a current SBOM on request. Neither is directed.
The last piece fell in March. FAR Case 2023-002, Supply Chain Software Security, was the rulemaking that would have written the attestation and SBOM expectations into the Federal Acquisition Regulation as a clause. The 2026 Unified Agenda lists it under completed actions with a single word: withdrawn, on March 6, 2026. The stated reason is that the case "was intended to implement Office of Management and Budget (OMB) direction that has since been rescinded." Today, FAR Part 40, Information Security and Supply Chain Security, contains one subpart of substance, on security prohibitions and exclusions; Subparts 40.1 and 40.3 are both marked reserved. There is no FAR clause obligating a contractor to deliver an SBOM.
One related rulemaking is still moving and is easy to confuse with the withdrawn one. FAR Case 2021-017, Cyber Threat and Incident Reporting and Information Sharing, sits at the final rule stage with a target date of September 2026. It concerns incident reporting and information sharing between contractors and the government. It is not an SBOM rule.
| Where the obligation comes from | Status as of August 2026 | Who checks it | What happens without one |
|---|---|---|---|
| FD&C Act section 524B 21 U.S.C. 360n-2 | In force. Statutory, applies to premarket submissions filed on or after March 29, 2023 | FDA, at premarket review | Submission is incomplete; the device does not reach market |
| EU Cyber Resilience Act Regulation (EU) 2024/2847 | In force since Dec 10, 2024. Reporting duties apply Sep 11, 2026; main obligations Dec 11, 2027 | National market surveillance authorities, on reasoned request | Conformity fails; the product cannot carry CE marking |
| Federal Acquisition Regulation | No clause. FAR Case 2023-002 withdrawn Mar 6, 2026 | Nobody | Nothing |
| OMB software supply chain policy M-22-18 and M-23-16 | Rescinded by M-26-05, Jan 23, 2026. Attestation form and SBOM terms are now optional per agency | Varies by agency and contract | Depends entirely on the contract you signed |
| CMMC and NIST SP 800-171 | In force (32 CFR effective Dec 16, 2024; DFARS rule effective Nov 10, 2025). Contains no SBOM control | C3PAO and DoD assessors | No SBOM finding is possible; nothing to fail |
| FedRAMP | In force. Baselines do not require an SBOM | Third-party assessment organization | No SBOM finding is possible |
| Your customer's contract terms | Whatever the signed document says | The contracting officer or the buying program | Withheld acceptance, cure notice, breach |
Section 524B is the U.S. mandate written in statute
Section 3305 of the Consolidated Appropriations Act, 2023, signed December 29, 2022, amended the Federal Food, Drug, and Cosmetic Act by adding section 524B, Ensuring Cybersecurity of Devices. Codified at 21 U.S.C. 360n-2, subsection (b)(3) says the sponsor of a premarket submission for a cyber device shall "provide to the Secretary a software bill of materials, including commercial, open-source, and off-the-shelf software components."
That single clause is the strongest SBOM requirement in U.S. law, and it is strong for structural reasons rather than rhetorical ones. It is statutory, not policy, so it does not move when an administration changes its posture on software accounting. It attaches to a gate a company must pass through, so a missing SBOM is not a finding to be remediated later but a submission that is not complete. And the statute defines its own scope: a cyber device is one that includes software validated, installed, or authorized by the sponsor, can connect to the internet, and contains technological characteristics that could be vulnerable to cybersecurity threats.
The timing is settled. The requirements do not apply retroactively to submissions filed before March 29, 2023, but they do apply to a new submission for a previously authorized device when a change requires premarket review. FDA's separate refuse-to-accept policy for cyber devices expired October 1, 2023; from that date the agency has expected complete section 524B content in the submission itself. A manufacturer building a connected product under FDA jurisdiction has had a hard SBOM obligation for three years, entirely independent of anything OMB or the FAR Council did.
The Cyber Resilience Act: an SBOM you must build and may never ship
Regulation (EU) 2024/2847, the Cyber Resilience Act, is the other real mandate, and it reaches any company placing a product with digital elements on the EU market. It entered into force on December 10, 2024. Reporting obligations apply from September 11, 2026, and the main obligations from December 11, 2027. The Commission published practical guidance for manufacturers on July 27, 2026.
The SBOM requirement sits in Annex I, Part II, point 1. Manufacturers must "identify and document vulnerabilities and components contained in products with digital elements, including by drawing up a software bill of materials in a commonly used and machine-readable format covering at the very least the top-level dependencies of the products." Three details in that sentence matter more than the requirement itself.
The floor is top-level dependencies. The CRA sets a lower depth bar than the current CISA technical baseline does. That is a floor, not a ceiling, and a manufacturer with better tooling should exceed it, but it defines what a market surveillance authority can insist on.
The SBOM goes to the regulator, not automatically to the customer. Annex VII lists the SBOM among the technical documentation to be supplied "further to a reasoned request from a market surveillance authority." Annex II handles the customer side differently: if the manufacturer decides to make the SBOM available to users, the instructions must say where to find it. Publishing to customers is optional. Producing it and holding it is not.
The format is not fixed yet. Article 13(24) lets the Commission specify the format and elements of the Annex I SBOM through implementing acts, taking European and international standards into account. Until that happens, a machine-readable SPDX or CycloneDX document is the defensible choice, and a company that has already standardized on one of those is positioned for whichever way the implementing act lands.
What the 2026 minimum elements changed
The technical definition of a competent SBOM was rewritten this summer. On July 29, 2026, CISA, NSA, FBI and fifteen international partner agencies published 2026 Minimum Elements for a Software Bill of Materials (SBOM), which updates and replaces the NTIA minimum elements published July 12, 2021. A draft went out for comment on August 22, 2025 and the comment period closed October 3, 2025; the July 2026 document is the finished version.
Read the scope statement before anything else, because it is the sentence most commonly misquoted: "The minimum elements do not create new requirements; they refine how organizations should generate and request SBOMs." This is a technical baseline, not a regulation. It becomes binding only when a contract points at it. Its practical weight comes from the fact that buyers now have something specific to point at.
The 2021 list had seven data fields. The 2026 list has seventeen, plus six practice-and-process elements. The additions are the interesting part, because each one closes a gap that made 2021-era SBOMs hard to act on.
| 2021 element | 2026 element | What changed in practice |
|---|---|---|
| Supplier Name | Component Producer | Names the entity that originated the software, not whoever passed it along. Where provenance is unclear, the author must mark the component as being of unknown provenance |
| Depth | Coverage | 2021 asked only for top-level dependencies. 2026 asks for all components including transitive dependencies, with no minimum depth, so a component absent from the SBOM can be read as genuinely absent |
| Other Unique Identifiers | Component Identifiers | At least one common machine-processable identifier such as CPE or PURL, and if several exist, include all of them |
| Automation Support | Machine-Processable Data | SWID tags dropped from the named formats. SPDX and CycloneDX are the two the document names as widely used |
| Known Unknowns | Explicitly Identifying Unknown Information | An author must now distinguish information that is unknown from information deliberately withheld, and provide a route for recipients to ask about redactions |
| Access Control | Removed | Folded into Distribution and Delivery. Access controls may limit who receives an SBOM but must not block sharing among authorized parties or block ingestion into security tools |
| — | Ten new fields | SBOM Author Signature, Data Format Name and Version, Generation Context, Tool Name and Version, SBOM Version, Component Hash Value and Algorithm, Component License |
Two of the new fields change how much a recipient can trust the document. SBOM Author Signature gives assurance that the named signatory produced the data and that nobody edited it afterward, using existing software-signing infrastructure and key management. SBOM Generation Context records the lifecycle phase the SBOM came from, with "before build," "build" and "after build" offered as sufficient values. That last one settles a long-running argument quietly: an SBOM generated from source and an SBOM generated by binary analysis after build are different artifacts with different blind spots, and now the document has to say which it is.
Component License is the field that will surprise engineering teams that treated SBOMs as a security artifact only. License identifiers, preferably SPDX identifiers, are now part of the minimum, including an indication of proprietary license conditions. Legal exposure and security exposure now share one inventory.
Where a federal SBOM obligation reaches you now
With the government-wide clause gone, the obligation reaches suppliers through the contract, and through nothing else. M-26-05 tells agencies they may adopt contract terms requiring a producer to provide a current SBOM on request. Some will; some will not; the ones that already wrote such terms into existing awards still hold them. That means the honest answer to "does the government require an SBOM from us" is: read the award, not the news.
Cloud platforms get a specific instruction
M-26-05 carries a one-line footnote directing that for a cloud platform, an agency adopting an SBOM contract term should specify that the producer must provide an SBOM of the runtime production environment on request. That is a materially different artifact from a build-time SBOM of the application repository, and a supplier that can only produce the latter will be answering a question the customer did not ask.
The runtime distinction is the single most common gap we see between what a buyer wants and what a delivery team can produce on short notice. A build-time SBOM describes what the source tree declared. A runtime SBOM of a production environment describes what is actually loaded and executing, including base-image packages, sidecars, and anything installed by a deployment step. The two documents disagree more often than teams expect, and the disagreement is usually the interesting part.
The CISA document acknowledges that software-as-a-service complicates the model. Producer and operator share responsibility, and change frequency in a continuous-delivery pipeline can outpace any sensible delivery cadence for a document. The workable pattern it points at is snapshotting through an API rather than shipping a file with each release.
What does not require an SBOM, stated plainly
Three widely believed requirements do not exist, and saying so is more useful than hedging.
NIST SP 800-171 does not require an SBOM. Revision 3 of the control set contains no mention of a bill of materials. Since CMMC assesses implementation of SP 800-171, a CMMC assessment cannot produce an SBOM finding. The CMMC program rule at 32 CFR took effect December 16, 2024 and the DFARS acquisition rule that puts the requirement into contracts took effect November 10, 2025, and neither adds one.
FedRAMP does not require an SBOM. The baselines are built on NIST SP 800-53 Revision 5, and that control catalog does not mention a bill of materials anywhere, so there is no SBOM deliverable to inherit. A cloud service provider may choose to maintain one, and several security products in the FedRAMP marketplace generate SBOMs as a feature, but that is a product capability rather than an authorization requirement.
The SSDF does not require an SBOM either. SP 800-218 mentions one in practice PS.3.2 as an example of how to collect and share provenance data for the components in a release. It is an illustration inside a recommendation, not a mandated output. The framework is also mid-revision: SP 800-218 Revision 1, describing SSDF version 1.2, went out as an initial public draft on December 17, 2025 with comments closing January 30, 2026, and version 1.1 remains the current final publication. A separate final publication, SP 800-218A, covers generative AI and dual-use foundation model development as a community profile.
On AI specifically, the position is clearer than the marketing around it suggests. CISA and G7 partners published Software Bill of Materials for AI — Minimum Elements on May 12, 2026, and the document states its own status: the supplemental elements it describes are neither exhaustive nor mandatory. The July 2026 general minimum elements make the same point from the other side, noting that AI systems may carry supply chain data of the kind engineers discuss as model cards or data cards, and then declining to add elements for them.
Building one that survives contact with a real buyer
Whether or not a rule compels it, an SBOM is cheap to generate and expensive to reconstruct after an incident. The practices below come from the 2026 minimum elements and are the ones that separate a document a security team can act on from a file that satisfies a checkbox.
- One SBOM per version, generated by the build, not by hand. Every release, update, and rebuild that pulls changed dependencies gets its own document with its own timestamp.
- Sign it. The author signature is what lets a recipient tell your document from a document that claims to be yours.
- Record the generation context. Say whether the data came from source before build or from binary analysis after build. A recipient who knows which one they hold can reason about what is missing.
- Mark unknowns explicitly, and distinguish them from withheld data. A blank field tells a recipient nothing. "Unknown to the author" and "withheld" carry different risk meanings.
- Include license identifiers. Use SPDX identifiers where they exist and flag proprietary conditions where they do not.
- Cover transitive dependencies, not just the first layer. The value of the document is a recipient's ability to conclude that a newly disclosed vulnerability does not affect them.
- Decide the delivery mechanism before the contract is signed. A version-specific URL, an API, or delivery alongside installation are all acceptable. Silence is not.
- Pair it with security advisories. VEX and CSAF documents tell a recipient whether a listed component's vulnerability is actually exploitable in your product, which is the difference between an inventory and an answer.
Common objections, answered
Does an SBOM expose our intellectual property?
An SBOM lists components and their relationships, not source code or algorithms. The 2026 minimum elements anticipate genuine sensitivity: an author may withhold information, but must say that something is withheld rather than leaving a silent gap, and must give recipients a route to ask about redactions. Access controls on distribution are permitted. What is not permitted, in a document claiming to meet the baseline, is quiet omission.
Our tooling produces a different SBOM every build. Is that a defect?
Not by itself. The Frequency element expects a new SBOM for each build or release, including builds that pull updated dependencies. Variation that tracks real dependency change is correct behavior. Variation between two builds of the same commit with no dependency change is a tooling problem worth chasing, because it undermines a recipient's ability to compare.
SPDX or CycloneDX?
Both are named in the 2026 minimum elements as widely used, open, machine-processable and human-readable. SPDX is standardized as ISO/IEC 5962:2021; CycloneDX is published as ECMA-424. Producers may pick based on their ecosystem and tooling. The guidance to consumers is the useful half: accept any widely used, interoperable, machine-processable format, and decline deprecated versions of any format.
The FAR clause is gone. Should we stop producing SBOMs?
Only if no contract you hold asks for one, no product you sell reaches the EU market or FDA review, and you are content to reconstruct your dependency graph by hand the next time a widely used library is compromised. The cost of generating an SBOM in a build pipeline is small and recurring. The cost of not having one is concentrated in the worst possible week.
Bottom line
Two SBOM mandates bind today. Section 524B of the FD&C Act binds medical device sponsors at premarket review, and it has since March 2023. The EU Cyber Resilience Act binds manufacturers placing products with digital elements on the EU market, with reporting duties from September 2026 and the main obligations from December 2027. Everything else in the U.S. federal space now reaches a supplier through a specific contract term or not at all, because M-26-05 rescinded the OMB policy in January 2026 and FAR Case 2023-002 was withdrawn in March.
The technical baseline moved in the opposite direction from the policy. The July 2026 minimum elements are stricter, deeper and more automatable than the 2021 version they replace, and they now describe what a buyer should ask for even though no rule compels the ask. That combination, weaker mandates and a sharper standard, rewards the supplier who builds the artifact because it is useful and can hand over a signed, complete, machine-readable document the day a customer asks. It penalizes the one who waits for a clause.
Frequently asked questions
Not government-wide. OMB Memorandum M-26-05, dated January 23, 2026, rescinded the memoranda that had driven the secure software attestation regime, and FAR Case 2023-002, Supply Chain Software Security, was withdrawn on March 6, 2026. Agencies may still adopt contract terms requiring an SBOM on request, so the obligation is contract-specific. Read the award.
Section 524B of the Federal Food, Drug, and Cosmetic Act, codified at 21 U.S.C. 360n-2. Subsection (b)(3) requires the sponsor of a premarket submission for a cyber device to provide FDA with a software bill of materials covering commercial, open-source and off-the-shelf components. It applies to submissions filed on or after March 29, 2023.
Neither does. CMMC assesses implementation of NIST SP 800-171, and Revision 3 of that control set contains no bill-of-materials requirement. FedRAMP baselines derive from NIST SP 800-53 and do not include an SBOM deliverable. An assessor working from either framework has no SBOM control to score.
The list grew from seven data fields to seventeen. New fields include an author digital signature, component hash value and algorithm, component license, tool name and version, and generation context. Supplier Name became Component Producer, Depth became Coverage with no minimum depth, and SWID tags were dropped from the named formats, leaving SPDX and CycloneDX.
No. Annex VII lists the SBOM among technical documentation supplied to a market surveillance authority on reasoned request. Publishing it to end users is optional under Annex II; if a manufacturer chooses to publish, the product instructions must say where it can be found.
There is guidance, not a standard. CISA and G7 partners published Software Bill of Materials for AI — Minimum Elements on May 12, 2026, and the document describes its supplemental elements as neither exhaustive nor mandatory. The general 2026 minimum elements deliberately do not add AI-specific fields, treating AI systems as software that should meet the same baseline first.