OMB Rescinds Biden-Era Software Security Requirements, Directs Agency-Led and Risk-Based Approach
The Office of Management and Budget (OMB) has rescinded some Biden-era directives on software supply chain security. As a result, software vendors to the federal government may see changes to federal agencies' secure development requirements.
OMB's Memorandum M-26-05, "Adopting a Risk-based Approach to Software and Hardware Security" (M-26-05) rescinds two prior OMB memos, M-22-18, "Enhancing the Security of the Software Supply Chain through Secure Software Development Practices," and M-23-16, "Update to Memorandum M-22-18." In doing so, M-26-05 shifts away from the Biden Administration's push for a more standardized, government-wide approach to software security at federal agencies. Under M-26-05, federal agencies no longer are required to obtain software security attestations from their software vendors, although they may choose to do so based on a "comprehensive risk assessment." The memo also gives agencies more discretion on whether to require their software vendors to provide software bills of materials (SBOMs).
Background
In May 2021, President Biden issued Executive Order 14028, "Improving the Nation's Cybersecurity" (EO 14028). That executive order (discussed in a prior blog post) included directives to the National Institute of Standards and Technology (NIST) to issue guidance on enhancing the security of the federal government's software supply chain. NIST responded with its Secure Software Development Framework (SSDF), published as NIST Special Publication (SP) 800-218.
EO 14028 also directed OMB to require federal agencies to comply with NIST's software security guidance, including the SSDF. OMB published M-22-18 and M-23-16 in 2022 and 2023, respectively. Those memos directed federal agencies to obtain attestations from their software vendors that their software was developed in conformance's with NIST's guidance. Those OMB memos also directed CISA to develop a self-attestation "common form" (discussed in a prior blog post) for agencies to require of their vendors, and directed CISA to establish a central repository for vendors' attestations. Agencies were encouraged—but not required—to use the CISA common form for vendors' attestations.
In January 2025, President Biden issued another cybersecurity executive order, "Strengthening and Promoting Innovation in the Nation's Cybersecurity" (EO 14144), that sought to further strengthen CISA's role in federal software security (we discussed this and other initiatives of the executive order here). Among other things, EO 14144 directed CISA to develop a process to "centrally verify" the completeness of software vendors' attestation forms and to notify vendors and agencies of deficiencies. EO 14144 also ordered CISA, NIST, and OMB to propose federal contracting requirements for vendors to provide those attestations.
President Trump reversed course in a June 2025 executive order, "Sustaining Select Efforts to Strengthen the Nation's Cybersecurity and Amending Executive Order 13694 and Executive Order 14144" (EO 14306), which removed entirely those added directives from EO 14144 (we discussed EO 14306 in a prior blog post). A fact sheet accompanying EO 14306 criticized EO 14144 as imposing overly burdensome software security requirements and "[m]icromanaging technical cybersecurity decisions better handled at the department and agency level, where budget tradeoffs and innovative solutions can be more effectively evaluated and implemented."
OMB M-26-05
Memorandum M-26-05 follows President Trump's approach in EO 14306 and its accompanying fact sheet. Echoing the fact sheet, M-26-05 criticizes M-22-18 and M-23-16 as having "imposed unproven and burdensome software accounting processes that prioritized compliance over genuine security investments" and neglecting hardware security considerations. In rescinding those memos, M-26-05 announces that "[e]ach agency head is ultimately responsible for assuring the security of software and hardware" and should validate the security of vendors' software "based on a comprehensive risk assessment," rather than a "universal, one-size-fits-all method."
Under M-26-05, federal agencies are permitted—but not directed—to obtain secure development attestations from their vendors, and may use CISA's common form for those attestations. Agencies also may continue to leverage NIST's SSDF, for attestations and otherwise, based on their own risk-based approach.
Memorandum M-26-05 also permits agencies to choose whether to require their vendors to provide SBOMs, and to choose whether to use CISA's SBOM and hardware bill of material (HBOM) templates when doing so. Memorandum M-22-18 did not strictly require agencies to obtain SBOMs, but rather noted that SBOMs "may be required" based on the criticality of the software or as determined by the agency. Where agencies required SBOMs, M-22-18 directed them to use a template maintained by CISA. Memorandum M-26-05 makes clear that agencies have discretion on whether to require an SBOM for software vendors and the forms those SBOMs may take. Memorandum M-26-05 also notes that where agencies choose to require an SBOM from their cloud service providers, the agencies should require an SBOM of the cloud services' "runtime production environment" (i.e., the live system that hosts actual government data, as opposed to a test or development environment).
To be sure, M-26-05 maintains the status quo on federal software security in fundamental ways. The memorandum reminds agencies of their existing obligations under federal statutes and NIST guidance to maintain complete software and hardware inventories and to develop security "assurance policies and processes" that match agencies' risk determinations and needs. As many software vendors are well aware, individual federal agencies have had—and will continue to have—a lead role in setting requirements for secure software developments.
Considerations for Federal Software Vendors
How M-26-05 will affect federal software vendors remains to be seen. Some agencies may cease requiring vendors to provide secure development attestations, resulting in decreased compliance burdens and legal risks for those agencies' vendors. However, vendors could see a proliferation of various attestation form templates as agencies move away from the CISA common form and adopt their own customized forms. Some of this proliferation has already occurred, as some agencies have required vendors to provide attestations based on agency-modified versions of the CISA common form. Agencies also could develop their own SBOM and HBOM templates, as M-26-05 makes clear that the CISA templates are not required.
For now, vendors should continue to expect agencies to require attestations using the CISA common form and variations thereof. If vendors are presented with materially different attestations, they should carefully review the commitments they are being asked to make and confirm that their practices support those commitments. Conformance with the CISA common form does not mean a vendor necessarily will be able to satisfy agency-specific attestations. Vendors also should review the CISA SBOM and HBOM templates (which are still in draft form) and be prepared to provide conforming materials, while keeping in mind that agencies may choose to require their own SBOM and HBOM versions.
Vendors also should continue to monitor potential changes to the Federal Acquisition Regulation (FAR). EO 14028 directed the development of standard language for federal contracts requiring software vendors to adopt and attest to compliance with software security practices. FAR Case 2023-002, which proposes to make those amendments to the FAR, has been open since 2023. It is unclear whether that case will move forward given the Trump Administration's push for a decentralized approach.
DWT's Privacy & Security team will continue to monitor developments related to federal software security requirements.
