26.1: U.S. Executive Order 14028 and Federal Requirements¶

Legal Disclaimer: This chapter provides general educational information about U.S. federal regulatory requirements for software supply chain security. It does not constitute legal advice and should not be relied upon as a substitute for consultation with qualified legal counsel familiar with your specific circumstances, business activities, and applicable law. Regulatory requirements are subject to change, and interpretations may vary. Organizations subject to federal procurement requirements should consult with attorneys experienced in government contracting and cybersecurity law.

The December 2020 SolarWinds compromise (detailed in Book 1, Section 7.2) marked a turning point in how governments approach software supply chain security. Attackers had infiltrated SolarWinds' build systems and inserted malicious code into software updates distributed to approximately 18,000 customers (per SolarWinds SEC filing¹)—including nine federal agencies and numerous Fortune 500 companies. The breach remained undetected for months, exposing the fundamental vulnerability of trusting software without visibility into its origins, components, and development practices.

Five months later, President Biden signed Executive Order 14028: Improving the Nation's Cybersecurity² on May 12, 2021.

This landmark order represents the most comprehensive federal intervention into software supply chain security to date, establishing requirements that extend well beyond government systems to reshape how software is developed, delivered, and verified across the entire technology industry.

The Policy Imperative: From Incident to Action¶

The SolarWinds attack—formally attributed in April 2021 to the Russian Foreign Intelligence Service (SVR)—demonstrated how compromised build processes could deliver digitally signed, legitimate-appearing updates carrying malicious payloads directly into victim networks. Traditional security controls failed because organizations trusted software from an established vendor without any mechanism to verify the integrity of its supply chain.

"The United States faces persistent and increasingly sophisticated malicious cyber campaigns that threaten the public sector, the private sector, and ultimately the American people's security and privacy." — Executive Order 14028, Section 1

The attack crystallized several painful lessons. First, software supply chains had become critical infrastructure requiring the same security attention as power grids and financial systems. Second, the federal government lacked visibility into how the software it purchased was developed and what components it contained. Third, voluntary security practices had proven insufficient—binding requirements were necessary to drive meaningful change.

EO 14028 emerged from this recognition, tasking multiple federal agencies with developing standards, guidance, and requirements to address these gaps. Unlike previous cybersecurity directives focused primarily on government systems, this order explicitly targets the software supply chain itself, creating ripple effects throughout the commercial software industry.

Key Provisions of Executive Order 14028¶

The executive order spans eleven sections addressing various aspects of cybersecurity, but several provisions directly impact software supply chain security:

Section 4: Enhancing Software Supply Chain Security establishes the framework for secure software development and verification. It directs the National Institute of Standards and Technology (NIST) to publish guidelines for evaluating software security, including criteria for secure development environments, automated testing, and provenance verification. Critically, it requires agencies to obtain attestations from software vendors regarding their security practices.

Section 5: Establishing a Cyber Safety Review Board creates a mechanism for analyzing significant cyber incidents, modeled loosely on the National Transportation Safety Board. This board was designed to examine major attacks, identify lessons learned, and recommend improvements—providing ongoing feedback to refine supply chain security practices. However, the CSRB's membership was terminated in January 2025 as part of broader administrative changes, and its future status remains uncertain. The loss of this analytical capability represents a gap in the federal government's ability to systematically learn from supply chain security incidents.

Section 6: Standardizing the Federal Government's Playbook for Responding to Cybersecurity Vulnerabilities and Incidents mandates consistent incident response procedures across agencies, improving coordination when supply chain compromises occur.

Section 4 also establishes requirements for a Software Bill of Materials (SBOM)—a formal, machine-readable inventory of software components. Section 4(e) directs the Secretary of Commerce, through NTIA, to publish minimum elements for SBOMs, while Section 10(j) provides the formal definition. The order explicitly identifies SBOMs as essential for transparency and vulnerability management.

SBOM Requirements and Federal Guidance¶

The National Telecommunications and Information Administration (NTIA) published "The Minimum Elements for a Software Bill of Materials"³ in July 2021, establishing baseline requirements for SBOM content and format. These minimum elements define what information an SBOM must contain to be useful for supply chain security purposes.

SBOM provision was initially positioned as a mandatory requirement under M-22-18. M-26-05 reframed it as an optional contractual term that agencies may adopt. The underlying guidance on SBOM content and format remains relevant regardless of mandate status.

Data Fields required for each component are detailed in Book 2, Section 12.2, "Software Bills of Materials." In summary, NTIA requires: supplier identification, component name and version, unique identifiers (PURL, CPE) for automated correlation, dependency relationships showing component composition, and SBOM authorship and timestamp information.

Automation Support requirements specify that SBOMs must be machine-readable and generated automatically as part of the software build process. The guidance endorses three formats: SPDX⁴ (ISO/IEC 5962:2021), CycloneDX⁵, and SWID tags.

Practices and Processes requirements establish that organizations must define how frequently SBOMs are updated, how they are distributed to recipients, and how access control is managed for SBOM data.

CISA has built upon NTIA's foundation, publishing additional guidance on SBOM sharing, consumption, and integration with vulnerability management programs. The agency's SBOM sharing lifecycle emphasizes that SBOMs are living documents requiring updates as software evolves and as new vulnerabilities are discovered in components.

Organizations implementing SBOM requirements should refer to Book 2, Section 12.2 for detailed guidance on SBOM generation approaches, format selection criteria (SPDX vs. CycloneDX vs. SWID), consumption workflows, and accuracy validation.

Secure Software Development Attestation¶

One of the most significant outputs of EO 14028 was the Secure Software Development Attestation Form⁶, finalized by CISA in March 2024. Under M-22-18 and M-23-16, this form was mandatory for software producers selling to the federal government. It required them to formally attest that their development practices conform to NIST's Secure Software Development Framework (SSDF)⁷.

Following the rescission of those memoranda by M-26-05 in January 2026, the attestation form remains available but is no longer universally required. Individual agencies may choose to require it based on their own risk assessments.

The attestation covers four categories of practices:

1. Prepare the Organization (PO): Ensuring people, processes, and technology are prepared to perform secure software development
2. Protect the Software (PS): Protecting all components of software from tampering and unauthorized access
3. Produce Well-Secured Software (PW): Producing well-secured software with minimal security vulnerabilities
4. Respond to Vulnerabilities (RV): Identifying residual vulnerabilities and responding appropriately

Where agencies do require attestation, signatories must be company executives who can legally bind the organization. False attestations carry potential consequences under federal law, including civil and criminal liability for fraud. This personal accountability provision significantly elevates the stakes beyond typical compliance checkboxes.

The attestation form requires software producers to attest that they:

• Develop and maintain secure software development environments
• Employ automated tools to check for vulnerabilities and remediate them
• Maintain provenance data for internal code and third-party components
• Provide SBOMs upon request
• Operate a vulnerability disclosure program
• Attest to the security practices of their software supply chain

OMB Memoranda: M-22-18, M-23-16, and M-26-05¶

The Office of Management and Budget initially translated EO 14028 requirements into binding agency guidance through two memoranda—before rescinding both in January 2026 in favor of a risk-based approach.

OMB M-22-18⁸ (September 14, 2022), titled "Enhancing the Security of the Software Supply Chain through Secure Software Development Practices," established initial timelines and requirements. It mandated that agencies only use software from producers who attest to following secure development practices, with deadlines based on software criticality.

The memorandum introduced the concept of critical software (as defined in OMB M-21-30)—software that performs functions critical to trust, such as operating systems, hypervisors, network management software, remote access tools, and identity management systems. Agencies faced accelerated timelines for obtaining attestations for critical software.

OMB M-23-16⁹ (June 9, 2023) extended and clarified M-22-18 requirements. Key provisions included:

• Software producers were given revised deadlines tied to the final common form: June 11, 2024 for critical software and September 11, 2024 for other covered software
• Agencies may require third-party assessments for high-risk software
• Open source software is explicitly included in scope
• Agencies must inventory all software, including components within larger systems
• Waivers are available under specific circumstances but require documentation

Together, these memoranda created a framework where federal purchasing power was intended to drive security improvements. Vendors unwilling or unable to attest to secure practices faced potential exclusion from federal contracts.

Rescission: OMB M-26-05¶

OMB M-26-05¹⁰ (January 23, 2026), titled "Adopting a Risk-based Approach to Software and Hardware Security," rescinded both M-22-18 and M-23-16. The memorandum characterized the prior approach as having "imposed unproven and burdensome software accounting processes that prioritized compliance over genuine security investments" that "diverted agencies from developing tailored assurance requirements for software."

M-26-05 replaces the mandatory, government-wide requirements with a risk-based model emphasizing agency autonomy:

• Agency responsibility: Each agency head is "ultimately responsible for assuring the security of software and hardware" on their networks
• No universal method: The memorandum explicitly states there is "no universal, one-size-fits-all method" for achieving security
• Risk-based validation: Agencies should validate provider security "based on a comprehensive risk assessment"
• Hardware included: Unlike the prior memoranda, M-26-05 addresses both software and hardware security

Under M-26-05, agencies retain the option—but no longer the obligation—to use the tools developed under the prior framework:

• The Secure Software Development Attestation Form (agencies "may choose to use" it)
• Contractual terms requiring SBOMs upon request (agencies "may also choose to adopt" these)
• NIST SP 800-218, Secure Software Development Framework
• CISA's 2025 draft Minimum Elements for an SBOM
• CISA's Hardware Bill of Materials (HBOM) Framework (September 2023)

The practical effect is that federal software supply chain security requirements shifted from mandatory, government-wide mandates to optional guidance that agencies may adopt based on their own risk determinations and mission needs.

Evaluating the Mandatory Approach¶

Whether M-22-18's mandatory attestation regime actually improved software security during its enforcement period (September 2022–January 2026) remains an open question. Limited public data exists on attestation completion rates, vendor practice changes, or measurable incident reduction attributable to the policy. This absence of measurement is itself significant—it highlights the difficulty of evaluating cybersecurity regulatory effectiveness and the risk that policy shifts occur based on ideological preference rather than empirical evidence.

M-26-05's characterization of the prior approach as prioritizing "compliance over genuine security investments" reflects a genuine tension in cybersecurity governance. Mandatory approaches provide a consistent floor but risk reducing security to a compliance exercise—organizations may invest in demonstrating conformance rather than achieving actual security outcomes. The attestation form, for example, required executive signatures but could not verify the depth or authenticity of underlying practices.

However, risk-based approaches carry their own failure mode: without standardized metrics, external validation, or reporting requirements, "risk-based" can become "risk-accepted-by-default." Agencies under budget pressure or with competing mission priorities may rationally deprioritize software supply chain security when no external accountability mechanism exists. The prior mandatory approach, whatever its limitations, established a floor below which agencies could not fall.

The question practitioners should ask is not which approach is inherently correct, but what institutional mechanisms now exist to ensure agencies actually conduct meaningful risk assessments of their software supply chains. M-26-05 assigns responsibility to agency heads but does not specify how those heads should be equipped, resourced, or held accountable for their risk determinations.

Impact on Federal Contractors and Suppliers¶

The regulatory landscape for organizations selling software to the federal government shifted significantly with M-26-05's rescission of mandatory requirements. Under the prior framework (M-22-18 and M-23-16), any software "developed, manufactured, sold, procured, or obtained" for use by federal agencies faced uniform compliance obligations. Under M-26-05, requirements vary by agency and are determined by each agency's risk assessment.

Software categories potentially subject to agency-specific requirements include:

• Commercial off-the-shelf (COTS) software
• Custom-developed software
• Software as a Service (SaaS) offerings
• Firmware and embedded software
• Hardware and its associated firmware
• Open source components incorporated into products

Potential agency requirements may include:

1. Completing the Secure Software Development Attestation Form
2. Providing SBOMs (or HBOMs for hardware) upon request
3. Implementing vulnerability disclosure programs
4. Maintaining software development security documentation
5. Ensuring subcontractors and suppliers meet equivalent requirements

The shift to agency-specific requirements introduces a new challenge: fragmentation. Rather than meeting a single government-wide standard, vendors may face different requirements from different agencies. Organizations selling to multiple agencies may encounter varying levels of rigor, different documentation expectations, and inconsistent enforcement—potentially increasing compliance complexity rather than reducing it.

Small and medium businesses face an uncertain landscape. While the rescission of mandatory requirements could reduce burden for vendors selling to less security-focused agencies, it could also mean that agencies with heightened security concerns impose requirements exceeding what M-22-18 demanded. Vendors should monitor the specific requirements of their agency customers.

Implementation Timeline and Current Status¶

The EO 14028 implementation proceeded through phases before the mandatory requirements were rescinded:

The rescission of M-22-18 and M-23-16 does not undo the technical work produced under EO 14028. NIST SP 800-218, the SSDF, the attestation form, and SBOM guidance all remain available as resources. However, the enforcement mechanism—mandatory attestation as a condition of doing business with the federal government—has been removed. Agencies now have discretion to impose, relax, or customize requirements based on their own risk assessments.

The long-term impact remains uncertain. Agencies that had already invested in compliance infrastructure may continue requiring attestations. Others may deprioritize software supply chain security in favor of competing mission priorities. The resulting fragmentation could produce a patchwork of requirements across the federal government rather than the uniform baseline that M-22-18 sought to establish.

CIRCIA and Incident Reporting Requirements¶

While M-26-05 rescinded the mandatory proactive security requirements of M-22-18, separate legislation continues to impose reactive reporting obligations when supply chain incidents occur.

The Cyber Incident Reporting for Critical Infrastructure Act (CIRCIA)¹¹, signed into law on March 15, 2022, complements EO 14028 by establishing mandatory incident reporting for critical infrastructure entities. As standalone legislation rather than executive guidance, CIRCIA was not affected by M-26-05's rescission. It reinforces supply chain security by ensuring visibility into attacks targeting the software supply chain.

Key CIRCIA provisions include:

• 72-hour reporting for covered cyber incidents
• 24-hour reporting for ransomware payments
• Coverage of entities in 16 critical infrastructure sectors
• CISA designated as the receiving agency for reports
• Liability protections for reporting entities

Software supply chain attacks affecting critical infrastructure trigger reporting obligations. An attack resembling SolarWinds—where compromised software updates penetrate multiple sectors—would generate mandatory reports from affected organizations, enabling faster coordinated response.

CISA published a proposed rule implementing CIRCIA in April 2024, with the final rule originally expected by late 2025. Given the current administration's broader regulatory recalibration—evidenced by M-26-05's rescission of software security mandates—the timeline and scope of the final rule remain uncertain. The rules will define covered entities, reportable incidents, and specific reporting procedures.

Industry Spillover Effects¶

While EO 14028 requirements formally applied only to federal procurement, the standards and practices developed under it have influenced the broader market. The rescission of mandatory requirements by M-26-05 does not necessarily reverse these effects, though it may slow their momentum.

Commercial customer expectations: Federal standards established under EO 14028 have already influenced private sector procurement practices. Many organizations incorporated SBOM requirements, attestation expectations, and SSDF-aligned practices into their vendor assessments. These commercial expectations may persist independently of federal mandates.

Vendor inertia: Organizations that invested in secure development practices, SBOM generation, and attestation infrastructure are unlikely to dismantle those capabilities. The sunk costs of compliance create organizational inertia that sustains practices even after mandates are removed.

Insurance and liability: Cyber insurance underwriters reference federal standards when evaluating applicants. The SSDF and attestation frameworks remain relevant benchmarks regardless of their mandatory status in federal procurement.

International divergence and the "Brussels Effect": The European Union's Cyber Resilience Act (see Section 26.2) and similar international regulations continue to advance mandatory requirements with conceptual alignment to EO 14028. The rescission of M-22-18 creates a notable divergence: the U.S. is retreating to voluntary, risk-based approaches at the exact moment the EU is implementing mandatory, penalty-backed requirements. This mirrors the dynamic that produced the "Brussels Effect" in privacy regulation—when GDPR imposed mandatory data protection requirements that became the de facto global standard regardless of other nations' domestic policies. For vendors serving global markets, the EU CRA may similarly set the effective global floor for software supply chain security, rendering the U.S. domestic regulatory posture less consequential for multinational vendors than the EU's mandatory framework.

The Emerging Global Baseline¶

While U.S. federal policy has retreated from mandatory requirements, this may prove strategically irrelevant for many organizations. The EU Cyber Resilience Act applies to any organization placing products on the European market—and its requirements exceed what M-22-18 mandated. For multinational vendors, the practical baseline is set by the most stringent jurisdiction they serve.

Just as GDPR effectively globalized EU data protection standards (the "Brussels Effect"), CRA may establish the de facto global floor for software supply chain security. Organizations debating whether to maintain M-22-18 compliance should recognize that CRA compliance is likely required anyway for EU market access—and CRA goes further, requiring vulnerability handling processes, security updates for the product lifetime, and technical documentation that M-22-18 never mandated.

The U.S. domestic policy debate may ultimately be an argument over a distinction that global markets render moot. For organizations selling internationally, the question is not whether the U.S. requires attestations, but whether the EU requires vulnerability disclosure programs, coordinated disclosure timelines, and CE marking for products with digital elements. For most global technology vendors, the answer is yes—making U.S. policy retreats less consequential than they might appear.

This dynamic has strategic implications for security investment decisions. Organizations that dismantled M-22-18 compliance programs may find themselves rebuilding equivalent capabilities for CRA compliance. Those that maintained their programs despite the U.S. rescission will find themselves better positioned for EU market requirements. The prudent approach treats the most stringent applicable requirement as the organizational baseline, regardless of which jurisdiction imposes it.

Open source ecosystem effects: Investment in open source security tooling, vulnerability databases, and SBOM generation capabilities—initially driven by federal requirements—continues through other channels including the EU CRA, industry consortia, and foundation-led initiatives.

Recommendations for Affected Organizations¶

The rescission of mandatory requirements does not eliminate the underlying security risks that motivated EO 14028. We recommend organizations selling to the federal government—and those concerned with software supply chain security generally—take the following actions:

1. Maintain software and hardware inventories comprehensively, including embedded components and dependencies—M-26-05 explicitly requires agencies to maintain such inventories and may expect the same from suppliers

2. Continue SSDF-aligned practices regardless of mandate status, as the underlying security value of secure development practices exists independently of regulatory requirements

3. Implement SBOM generation as an automated part of build processes, selecting a standard format (SPDX or CycloneDX)—agencies retain the option to require SBOMs contractually, and international regulations (EU CRA) increasingly mandate them

4. Establish vulnerability disclosure programs if not already present, as these remain referenced in M-26-05's optional guidance and are increasingly expected by commercial customers

5. Monitor agency-specific requirements closely, as the shift to risk-based approaches means different agencies may impose different standards—potentially with less advance notice than the phased M-22-18 rollout provided

6. Prepare for international requirements such as the EU Cyber Resilience Act, which may impose obligations exceeding what M-22-18 required (see Section 26.2)

7. Consider hardware security alongside software, given M-26-05's explicit inclusion of hardware and its reference to the CISA HBOM Framework

8. Document security practices thoroughly, as evidence of secure development remains valuable for agency audits, insurance applications, and commercial customer assessments even without a universal mandate

The shift from mandatory to risk-based requirements creates uncertainty but does not reduce the threat landscape. Organizations that maintain strong supply chain security practices position themselves for both government opportunities—where agencies may still require attestation—and an increasingly security-conscious commercial market shaped by international regulations and customer expectations.