SBOMVault.ai
Start Free
← Back to blog
Compliance

EO 14028, three years on: where federal SBOM requirements actually stand

January 20, 2025·7 min read·SBOMVault Team

It has been more than three years since Executive Order 14028, "Improving the Nation's Cybersecurity," was signed in May 2021. For software vendors, it was the moment the Software Bill of Materials went from a good idea to a procurement requirement. Three-plus years in, where do things actually stand?

What EO 14028 set in motion

The executive order itself did not hand vendors a checklist. It directed federal agencies and NIST to develop one. The practical requirements arrived through follow-on guidance:

  • NIST's Secure Software Development Framework (SSDF, SP 800-218) defined the secure-development practices vendors are expected to follow.
  • OMB Memorandum M-22-18 (September 2022) required agencies to obtain self-attestation from software producers that they follow those practices.
  • OMB Memorandum M-23-16 (June 2023) updated timelines and clarified scope.
  • CISA's secure software development self-attestation form gave the attestation a concrete shape.

The throughline: if you sell software to the federal government, you are expected to attest to secure development practices, and an SBOM is part of the evidence base.

What is genuinely required today

A fair summary of the current state for vendors selling to United States agencies:

  1. Self-attestation to SSDF-aligned practices is the binding mechanism — a named executive vouches that your organization follows them.
  2. SBOMs are increasingly requested as supporting artifacts, and agencies may require them by contract.
  3. Scope has widened from the initial "critical software" framing toward software broadly.

What is still messy

Anyone who tells you this is fully settled is selling something. The real picture includes friction:

  • SBOM consumption lags production. Agencies can ask for SBOMs faster than they can ingest and act on them at scale.
  • Format and depth expectations vary across agencies and contracts.
  • Attestation is a paperwork burden that does not, by itself, make software more secure — the practices behind it do.

Why this matters even if you do not sell to the government

Two reasons. First, federal requirements set the template that regulated industries and large enterprises copy; "send us your self-attestation and SBOM" is now common in private-sector procurement. Second, the EU Cyber Resilience Act is pushing in the same direction on the other side of the Atlantic, which means expectations are converging globally rather than diverging.

What to do about it

The teams handling this well are not the ones with the thickest binders. They are the ones who made compliance a byproduct of good engineering:

  1. Adopt SSDF practices for real, not just on the attestation form.
  2. Automate SBOM generation so every release produces one without human effort.
  3. Keep evidence trails — vulnerability scans, fix decisions, sign-offs — captured as you work, so an audit is a download rather than a project.

Three years on, EO 14028's lasting effect is cultural as much as regulatory. It normalized the expectation that software vendors can account for what is inside their products. That expectation is not going away — it is spreading.

Try SBOMVault free →