On May 12, 2021, President Biden signed Executive Order 14028, "Improving the Nation's Cybersecurity." It was a direct response to the SolarWinds attack and the Colonial Pipeline incident, and it set in motion the most significant federal cybersecurity policy changes in a decade.
Five years later, the results are mixed. Some provisions transformed the industry. Others remain unfulfilled promises. And the threat landscape has evolved in ways the EO did not anticipate.
This review assesses each major provision against its original intent and real-world impact.
What the EO Required
EO 14028 had seven major sections:
- Removing barriers to threat information sharing
- Modernizing federal cybersecurity (zero trust, encryption, EDR)
- Enhancing software supply chain security
- Establishing a Cyber Safety Review Board
- Standardizing the federal vulnerability response playbook
- Improving detection of cybersecurity incidents on federal networks
- Improving investigation and remediation capabilities
For supply chain security, Section 4 was the most consequential. It directed NIST to develop standards for secure software development, required federal agencies to comply with those standards, and — critically — mandated that software vendors provide SBOMs as part of federal procurement.
What Worked
SBOM Awareness Went Mainstream
Before EO 14028, SBOMs were a niche concept known primarily to license compliance teams. The EO put SBOMs on the agenda of every software vendor selling to the federal government, and the ripple effect extended far beyond federal procurement.
The SBOM minimum elements guidance published by NTIA (later CISA) provided a concrete specification that tooling vendors could implement against. The result was an explosion of SBOM generation tooling — Syft, cdxgen, Microsoft SBOM Tool, and dozens of others — that made generation accessible to any organization.
Would this have happened without the EO? Eventually, probably. But the EO accelerated the timeline by years.
NIST SSDF Became the Baseline
NIST SP 800-218, the Secure Software Development Framework (SSDF), was published in response to Section 4e. It provides a set of practices for secure software development that federal agencies can require of their vendors.
The SSDF is not revolutionary — most of its recommendations were already considered best practices. But codifying them in a NIST publication gave procurement officers a concrete reference and gave vendors a clear target.
In practice, SSDF compliance has become a procurement requirement for most federal software acquisitions. Vendors self-attest to compliance, though the rigor of those attestations varies widely.
The Cyber Safety Review Board Produced Useful Analysis
The CSRB, modeled on the NTSB for aviation safety, has published detailed reviews of major incidents including the Log4Shell vulnerability, the Microsoft Exchange compromise, and the MOVEit attack.
These reports are genuinely useful. They go deeper than typical incident post-mortems, examining root causes, organizational failures, and systemic issues. The Log4Shell report, in particular, provided actionable recommendations for both the open-source community and enterprise consumers.
The CSRB's limitation is that its recommendations are non-binding. It can identify what went wrong and suggest fixes, but it cannot compel action.
Zero Trust Architecture Progressed
Federal agencies have made measurable progress toward zero trust, driven by OMB Memorandum M-22-09 (which implemented Section 3 of the EO). Agency zero trust implementation plans are public, progress is tracked, and the deadline pressure has forced modernization of legacy systems.
The progress is uneven — some agencies are well ahead of the curve while others are struggling — but the direction is unmistakable.
What Did Not Work
Software Supply Chain Attestation Remains Weak
Section 4 required software vendors to attest to their secure development practices. In theory, this creates accountability. In practice, the attestation framework has three problems:
Self-attestation without verification. Vendors attest that they follow SSDF practices, but nobody audits the claims. Without verification, attestation is a trust exercise, not a security control.
Binary compliance. Attestation is pass/fail — you either attest or you do not. There is no gradient that distinguishes a vendor with mature security practices from one that checked the boxes yesterday.
No consequences for inaccuracy. While the False Claims Act theoretically applies, no enforcement action has been taken against a vendor for inaccurate software security attestation. Without precedent, the deterrent effect is limited.
SBOM Consumption Lagged Behind Generation
The EO successfully drove SBOM generation. It did not drive SBOM consumption with equal force. Federal agencies now receive SBOMs from their vendors, but most lack the tooling and processes to do anything meaningful with them.
A 2025 GAO report found that only 23% of federal agencies had automated SBOM analysis capabilities. The rest either reviewed SBOMs manually (impractical at scale) or stored them without analysis.
The EO Did Not Anticipate AI
EO 14028 was signed before the generative AI explosion. It says nothing about AI-generated code, AI agents in development workflows, or the supply chain risks introduced by LLM-assisted development. A subsequent executive order (EO 14110, October 2023) addressed AI safety and security, but the two EOs do not integrate cleanly.
The gap is significant. AI agents are now participants in the software supply chain — writing code, selecting dependencies, and producing artifacts. The security frameworks established by EO 14028 need to extend to AI-driven development, but the legal and policy foundations for that extension are still being built.
What Comes Next
The EO itself is aging out — executive orders are tied to administrations, and their longevity depends on whether successor administrations choose to maintain, modify, or revoke them. The durable impact of EO 14028 will be measured by how much of it has been codified into law, regulation, or industry standard.
On that front, the picture is encouraging. The Software Transparency Act would codify SBOM requirements in legislation. CISA's enforcement of SBOM mandates goes beyond the EO's procurement focus. And NIST SSDF has been widely adopted outside the federal context.
The next five years will likely see:
- Legislative codification of the EO's key provisions
- Expansion to cover AI-driven development
- Transition from self-attestation to verified compliance
- Deeper integration between SBOM requirements and vulnerability management
- International harmonization with the EU CRA and similar frameworks
How Safeguard.sh Helps
Safeguard was built in the post-EO 14028 world, and our platform directly addresses both the successes and the gaps of the executive order. We automate SBOM generation for federal compliance, provide the consumption tooling that most agencies lack, and map SSDF practices to verifiable controls rather than self-attestation checkboxes. As the regulatory landscape evolves — from EO to legislation, from guidance to enforcement — Safeguard evolves with it, ensuring our customers stay ahead of compliance requirements rather than scrambling to catch up.