Executive Order 14028 SBOM Requirements: What to Comply With and How

What Are the Executive Order 14028 SBOM Requirements in 2026?

In January 2026, OMB dropped the federal attestation mandate. The SBOM requirement survived. Executive Order 14028 directed federal agencies to require a software bill of materials (SBOM) from the software suppliers they buy from.

Initially signed in May 2021, the order directed federal agencies to require an SBOM from software suppliers, either delivered to the purchaser or published publicly.

An SBOM is a machine-readable inventory of the components inside a piece of software, much like an ingredients list. Section 4, "Enhancing Software Supply Chain Security," did not spell out every technical detail itself. It tasked two agencies with those details: the National Telecommunications and Information Administration (NTIA) and the National Institute of Standards and Technology (NIST).

Those two agencies defined what an SBOM must contain and how it fits into federal procurement. In short, Executive Order 14028 SBOM rules set the baseline that still shapes federal software purchasing today.

What are the NTIA minimum elements for an SBOM?

In July 2021, NTIA published its "Minimum Elements for an SBOM." This baseline defines what a conformant SBOM needs, and it still anchors federal expectations today.

According to NIST software supply chain guidance, NTIA's Minimum Elements for an SBOM define three categories: minimum data fields, automation support, and practices and processes. Agencies should require suppliers to provide access to machine-readable SBOMs in conformance with the EO and NTIA's minimum elements.

The minimum data fields cover seven pieces of information:

• Supplier name: who created the component.
• Component name: what the component is called.
• Version: which release is included.
• Unique identifiers: codes that pin down the exact component.
• Dependency relationship: how components connect to each other.
• SBOM author: who generated the record.
• Timestamp: when the record was created.

In 2025, the Cybersecurity and Infrastructure Security Agency (CISA) proposed an update.

Which SBOM formats meet federal requirements?

NTIA recognizes three formats:

• SPDX: built by the Linux Foundation to describe components, licenses, and relationships.
• CycloneDX: built by OWASP for security uses like vulnerability and dependency tracking.
• SWID tags: built as an ISO standard to identify and tag installed software.

Both SPDX and CycloneDX meet the NTIA minimum data fields and can carry much more detail.

Why does the federal government require SBOMs?

Modern software is mostly assembled, not written from scratch. Most applications are built largely from open source components, so one weak link can affect many organizations at once.

The scale is easy to underestimate. Each year brings a flood of new Common Vulnerabilities and Exposures (CVE) entries, which are public records of known software flaws. Security researcher Jerry Gamblin counted 48,185 CVEs in 2025, a 20.6% increase from 2024's 39,962.

Two widely studied events, the SolarWinds compromise and the Log4Shell vulnerability, showed how a single component can ripple across thousands of downstream users. Transparency is how buyers regain visibility into what they are running.

The Verizon 2026 Data Breach Investigations Report found, in its full report, that third-party breaches reached 48% of all breaches, with third-party involvement up 60% year over year.

Who has to comply with EO 14028 SBOM requirements?

Executive Order 14028 SBOM obligations apply first to a narrow group: U.S. federal agencies and the software vendors and integrators that sell to them. New acquisitions began carrying these expectations in fiscal year 2023.

The practical reach is wider. Enterprise buyers now copy federal language into their own contracts, so many vendors get SBOM requests even without a government deal.

Compliance also connects to secure development. The order pointed to secure software development attestation under the NIST Secure Software Development Framework (SSDF), published as NIST SP 800-218.

What changed in 2026 under OMB M-26-05?

This is where most explainers get it wrong. The Executive Order 14028 SBOM mandate did not disappear, but the memos that implemented it have changed.

The Office of Management and Budget (OMB) drove early implementation. OMB M-22-18 (2022) and M-23-16 (2023) required secure-development self-attestation using CISA's "Common Form," with SBOMs required as needed.

In January 2026, OMB M-26-05 adopted a risk-based approach and rescinded the standardized attestation mandate. Agencies are no longer required to use the Common Form, but they may still require SBOMs by contract.

For the fuller regulatory timeline, see our overview of federal software supply chain requirements.

Is an SBOM enough to manage supply chain risk?

A conformant SBOM proves transparency, but transparency is only the first step. A raw component list becomes a long queue of CVEs, and most of them are not worth emergency action.

That volume is not the same as risk. J.P. Morgan reports that only 1.5% to 2% of reported vulnerabilities are exploited each year.

Most of that noise comes from code developers never chose directly. Our research shows more than 95% of open source vulnerabilities live in transitive dependencies, which are the dependencies of your dependencies.

An SBOM tells you what you have, not what is exploitable. It is also easy to get wrong, since SBOMs vary by tool and lifecycle stage. That is why we say SBOMs are a means to an end, not the finish line.

How do you find which SBOM vulnerabilities are exploitable?

Reachability answers a sharper question: can a vulnerable function be reached and run in your application? We call our approach full stack reachability because it traces this across code, open source dependencies, and containers.

Our research shows about 90.5% of vulnerabilities are unreachable at the function level. Combining reachability with the Exploit Prediction Scoring System (EPSS) can cut roughly 98% of the noise.

That is the basis for reachability-based prioritization: fix the findings that can be exploited first.

Vulnerability Exploitability eXchange (VEX) records this in a machine-readable form. It states which listed vulnerabilities affect a product, and it is worth understanding what VEX documents add to an SBOM.

Exploitable exposure is common in the wild. Datadog's 2026 State of DevSecOps report found that 87% of organizations have at least one known, exploitable vulnerability in deployed services.

How do you fix SBOM findings without breaking the build?

Knowing what matters is half the battle. Fixing it without breaking your application is the other half.

Upgrades are riskier than they look. Our research shows 95% of version upgrades contain at least one breaking change, and fixes require a major version update about 24% of the time.

Upgrade impact analysis predicts those breaks before you commit to them. When upgrading is too painful, backported patches let teams stay safe on their current version.

How do you build a practical SBOM program?

A good program moves from generating SBOMs to acting on them. Here is a practical, risk-based sequence that matches what agencies now expect.

1. Generate automatically: produce SBOMs in your continuous integration (CI) pipeline in a standard format like SPDX or CycloneDX.
2. Check accuracy: use software composition analysis (SCA) to capture a build-time inventory including transitive dependencies.
3. Centralize storage: ingest and manage SBOMs for first- and third-party software in one place.
4. Add exploitability context: layer reachability and VEX on top so you triage the few findings that matter.
5. Plan remediation: use upgrade analysis and backported patches to fix without breaking things.
6. Set policy: define cadence, delivery method, and ownership so you can run an SBOM program you can audit.

Frequently Asked Questions

Is Executive Order 14028 still in effect in 2026?

The order's text remains in force, but its implementing memos changed under OMB M-26-05, and agencies still commonly require SBOMs.

Did EO 14028 require an SBOM or recommend one?

It directed federal agencies to require SBOMs in procurement, while delegating the technical specifics to NTIA and NIST.

What are the NTIA minimum elements?

They fall into three categories: minimum data fields, automation support, and practices and processes.

Do I need an SBOM if I don't sell to the federal government?

Increasingly yes, because enterprise buyers and other regulations now request SBOMs in their own contracts.

How is an SBOM different from a vulnerability scan?

An SBOM is an inventory of components; pair it with reachability and VEX to learn which listed vulnerabilities are exploitable.

How do you move from SBOM compliance to action?

The direction of travel is clear: transparency plus accountable, risk-based action. Executive Order 14028 SBOM compliance is now about action, not just paperwork.

An SBOM is necessary, but on its own it is not sufficient. The value shows up when you can tell which findings matter and fix them safely.

See how Endor Labs turns SBOMs into prioritized, evidence-based action. Book a demo to walk through full stack reachability, VEX, and safe remediation on your own code.