Executive Order 14028, "Improving the Nation's Cybersecurity," was signed by President Biden on May 12, 2021, seven days after the Colonial Pipeline ransomware attack shut down fuel delivery across the Eastern United States and five months after the SolarWinds breach compromised roughly 18,000 organizations, including nine federal agencies. The order is the most consequential software supply chain security policy the U.S. government has issued: it directs NIST to define a Secure Software Development Framework, requires federal software vendors to generate a Software Bill of Materials (SBOM), and forces agencies to only buy software from vendors who self-attest to secure development practices. Enforcement flows through federal procurement — if you sell software to the U.S. government, EO 14028 already shapes what you have to prove. If you don't, its requirements are becoming the de facto baseline auditors, insurers, and enterprise customers expect anyway. Here's what it actually requires, who it binds, and how the requirements have shifted since 2021.
What is Executive Order 14028?
Executive Order 14028 is a 10-section presidential directive that rewrites how the federal government buys, builds, and defends software, with Section 4 ("Enhancing Software Supply Chain Security") aimed directly at vendors. It set cascading deadlines — 45, 60, 90, 180, 270, and 360 days from the May 12, 2021 signing date — for NIST, CISA, OMB, and the FAR Council to publish standards and for agencies to adopt them. Beyond supply chain security, the order also mandates zero trust architecture adoption (Section 3), EDR deployment on federal endpoints, removal of contractual barriers that stopped IT vendors from sharing breach information with CISA (Section 2), and creation of a Cyber Safety Review Board modeled on the NTSB (Section 5), which conducted its first review on the Log4j vulnerability in 2022.
Why did the Biden administration issue EO 14028?
The order was a direct policy response to two 2021 incidents that exposed how a single compromised vendor or pipeline operator could cascade into national-scale disruption. SolarWinds attackers inserted malicious code into Orion software updates between September 2019 and June 2020, and that single build-pipeline compromise reached roughly 18,000 SolarWinds customers, including the Treasury, Commerce, and Homeland Security departments. The Colonial Pipeline ransomware attack on May 7, 2021 forced the shutdown of a pipeline carrying 45% of the East Coast's fuel supply, triggering gas shortages across six states. Both incidents shared a root cause the order calls out explicitly: commercial software was being deployed into federal environments with no visibility into how it was built, what components it contained, or whether the vendor followed any secure development practice at all.
What does EO 14028 require for software supply chain security?
Section 4 requires every vendor selling software to the federal government to provide a Software Bill of Materials and follow NIST's Secure Software Development Framework (SSDF). NIST published the minimum elements for an SBOM on July 12, 2021 — 60 days after the order, exactly on schedule — defining that an SBOM must include supplier name, component name, version, dependency relationships, and a timestamp, among other fields. NIST released the SSDF itself as Special Publication 800-218 in February 2022, organizing requirements into four practice groups: Prepare the Organization, Protect the Software, Produce Well-Secured Software, and Respond to Vulnerabilities. NIST also had to publish a definition of "critical software" within 60 days; it released that definition on June 25, 2021, initially scoping in things like identity management systems, operating systems, and network monitoring tools that run with elevated privilege on federal systems.
What is the self-attestation requirement under EO 14028?
Vendors must sign a standardized form certifying they built their software in conformance with the NIST SSDF, and OMB made that legally binding through Memo M-22-18 on September 14, 2022. The memo requires federal agencies to collect self-attestation letters from software producers before using their products in production, with the option to require a third-party assessment for critical software instead of self-attestation. OMB followed up with M-23-16 in June 2023, extending the compliance timeline and clarifying that open-source software consumed but not modified by an agency's own developers is exempt. CISA finalized the common self-attestation form itself in March 2023 and revised it again in 2024 after industry groups flagged inconsistencies in how "critical software" scoping applied to SaaS and cloud-delivered products. Vendors that submit a false attestation are exposed to liability under the False Claims Act, which is the enforcement teeth that distinguishes this from a voluntary framework.
Does EO 14028 apply to private companies?
EO 14028 binds federal agencies directly and reaches private companies only through the procurement contracts those agencies sign, so a company with no federal customers has no direct legal obligation under it. In practice the reach is wider than that carve-out suggests: any software vendor, integrator, or SaaS provider that wants federal revenue — a market FedRAMP-authorized providers alone measure in tens of billions of dollars annually — has to build SBOM generation and SSDF-aligned practices into its engineering pipeline before it can bid. The FAR Council proposed a rule in 2023 to write SBOM and attestation requirements directly into the Federal Acquisition Regulation, which would convert today's OMB-memo-driven obligations into binding contract clauses across the full federal supply base, not just agencies' direct software purchases.
Has EO 14028 changed since it was signed in 2021?
Yes — EO 14028 has been amended twice since 2021, most recently by an order President Trump signed in June 2025 that narrowed some of its provisions. President Biden issued EO 14144 in January 2025, days before leaving office, adding requirements around AI security and expanding secure software attestation to cover more of the federal software supply base. The Trump administration's June 2025 order rolled back several of those additions — including provisions tied to digital identity and some AI-specific mandates — while leaving the core SBOM, SSDF, and self-attestation machinery from Sections 4 intact. For vendors, the practical takeaway is that the underlying engineering obligations (produce an SBOM, follow the SSDF, attest to secure practices) have proven durable across two administrations even as peripheral provisions get renegotiated.
How Safeguard Helps
Meeting EO 14028's Section 4 requirements means proving three things continuously, not just at contract signing: what's in your software, whether you built it securely, and whether the vulnerabilities in it actually matter. Safeguard generates and ingests SBOMs directly from your build pipeline, keeping the CycloneDX or SPDX documents agencies expect current with every release instead of stale at audit time. Reachability analysis then cuts through the noise in that SBOM by determining which flagged CVEs sit in code paths your application actually executes, so your team isn't burning attestation cycles chasing components that are present but dormant. Griffin AI triages the vulnerabilities that are reachable and opens auto-fix PRs that bump the affected dependency to a patched version, shrinking the gap between "vulnerability disclosed" and "vulnerability remediated" that self-attestation is ultimately meant to shorten. Together, that pipeline turns EO 14028 compliance from a once-a-year paperwork exercise into evidence your engineering team is already producing.