On May 12, 2021, President Biden signed Executive Order 14028, "Improving the Nation's Cybersecurity," in response to the SolarWinds supply chain attack and the Colonial Pipeline ransomware incident. Now, three years later, it is worth assessing what the order has actually accomplished, where it has fallen short, and what the next phase of federal cybersecurity policy looks like.
What EO 14028 Required
The executive order was sweeping in scope. Among its key provisions:
- Required SBOM (Software Bill of Materials) delivery from vendors selling to the federal government
- Mandated adoption of zero trust architecture across federal agencies
- Required secure software development practices for federal software suppliers
- Established the Cyber Safety Review Board (CSRB) modeled on the NTSB
- Required improved logging and detection capabilities across federal systems
- Directed NIST to develop secure software development guidelines
The order set aggressive timelines, with many requirements expected to be implemented within 60 to 365 days. Three years on, the reality has been more gradual than the timelines suggested.
SBOM Adoption: Growing but Uneven
SBOMs were perhaps the most discussed provision of EO 14028. The order required that software vendors provide SBOMs to federal agencies as part of the procurement process. NIST published minimum elements for SBOMs in July 2021, and CISA followed with guidance on SBOM formats, generation, and consumption.
Three years later, SBOM adoption has grown significantly but remains uneven:
What has worked: The major SBOM formats (SPDX and CycloneDX) have matured substantially. SBOM generation tooling has improved, with tools like Syft, Trivy, and Microsoft's SBOM Tool making it straightforward to generate SBOMs for common software types. Major software vendors have begun including SBOMs with their products. The conversation has shifted from "what is an SBOM?" to "how do I use SBOMs effectively?"
What has not worked: SBOM consumption tooling lags behind generation tooling. Many organizations can produce SBOMs but struggle to operationalize them for vulnerability tracking and risk management. The quality and completeness of SBOMs varies enormously. SBOM exchange formats and sharing mechanisms are still maturing.
Federal agencies themselves have had mixed success implementing SBOM requirements. Some agencies have integrated SBOM requirements into their procurement processes and are actively consuming SBOMs from vendors. Others have treated it as a checkbox exercise, collecting SBOMs without operationalizing them.
Secure Software Development Attestation
In March 2024, CISA released the final version of the Secure Software Development Attestation Form, which requires software producers selling to the federal government to attest that they follow secure development practices aligned with the NIST Secure Software Development Framework (SSDF).
The attestation form requires senior company officials to confirm that their organization:
- Separates build environments from development environments
- Maintains provenance data for internally developed and third-party components
- Employs automated tools to check for and remediate known vulnerabilities
- Maintains trusted source code supply chains
- Implements multi-factor authentication and conditional access for development systems
This attestation requirement is significant because it creates personal accountability. Senior officials signing the form are making a formal representation to the federal government about their security practices. False attestation carries legal risk.
However, the attestation is self-reported and compliance verification is limited. Without systematic auditing, there is a risk that attestation becomes a rubber stamp rather than a driver of genuine security improvement.
Zero Trust Implementation
EO 14028 directed federal agencies to adopt zero trust architecture, and OMB followed with Memorandum M-22-09 establishing specific zero trust goals for agencies. Progress has been mixed:
Some agencies have made substantial progress in implementing identity-centric access controls, microsegmentation, and continuous verification. The Department of Defense's zero trust strategy and the CISA Zero Trust Maturity Model have provided frameworks for implementation.
However, many agencies are still in the planning or early implementation phases. Legacy systems that cannot support modern authentication mechanisms are a persistent barrier. Budget constraints and competing priorities have slowed implementation at some agencies.
The Cyber Safety Review Board
The CSRB was one of the more innovative provisions of EO 14028. Modeled on the National Transportation Safety Board (NTSB), it was intended to conduct thorough reviews of significant cybersecurity incidents and publish lessons learned.
The CSRB has published reviews of the Log4Shell vulnerability (2022) and the Microsoft Exchange Online intrusion by Storm-0558 (2023). The Storm-0558 review was particularly notable for its direct criticism of Microsoft's security culture and practices, demonstrating that the board was willing to hold major vendors accountable.
However, the CSRB has been criticized for its slow pace (the Storm-0558 report took several months to produce) and its lack of enforcement authority. Unlike the NTSB, the CSRB can only recommend, not mandate changes.
What Comes Next
The next phase of federal cybersecurity policy is likely to focus on:
Enforcement and verification. The initial EO focused on establishing requirements and frameworks. The next phase will need to focus on verifying compliance and enforcing accountability.
Supply chain security beyond SBOMs. SBOMs are a necessary but not sufficient component of supply chain security. Build provenance, reproducible builds, and runtime monitoring are complementary capabilities that need further development.
AI-specific security requirements. EO 14110 (October 2023) addressed AI safety and security, but specific technical requirements for AI systems in federal use are still being developed.
International harmonization. The EU Cyber Resilience Act, NIS2 Directive, and other international regulations are establishing their own software supply chain security requirements. Harmonizing these with U.S. requirements will be important for companies operating globally.
How Safeguard.sh Helps
Safeguard.sh is built on the foundation that EO 14028 established. Our SBOM generation, management, and continuous monitoring capabilities directly address the requirements of the executive order, from providing machine-readable SBOMs to tracking vulnerabilities against your software inventory. For organizations selling to the federal government, Safeguard.sh provides the tooling needed to meet secure software development attestation requirements with actual evidence rather than aspirational statements. Our policy gates enforce the security standards that EO 14028 envisions, turning compliance requirements into automated, verifiable controls.