Alexander Culafi , Senior News Writer , Dark Reading January 29, 2026 5 Min Read Source: Abaca Press via Alamy Stock Photo The White House's Office of Management and Budget (OMB) has issued a memorandum to roll back software security requirements established by the previous administration, including following NIST guidance and suggestions to use software bills of material (SBOMs) to help ensure secure software development practices. Security pros, however, are split on what that means in practice. On Jan. 23, OMB Director Russell Vought issued M-26-05 , which rescinds two memorandums signed in 2022 and 2023 (M-22-18 and M-23-16, respectively). The former, the most significant of the two, required federal agencies to requisition a self-attestation from commercial software producers guaranteeing that contracted software meets NIST secure development guidelines (and suggested the use of SBOMs in certain cases). M-23-16, meanwhile, was a clarification and scope-defining memorandum that extended some deadlines for compliance with M-22-18. M-26-05 rescinds these requirements, with Vought writing they "imposed unproven and burdensome software accounting processes that prioritized compliance over genuine security investments." He added, "this policy diverted agencies from developing tailored assurance requirements for software and neglected to account for threats posed by insecure hardware." Agencies may still use resources developed under the memorandum and may still elect to continue requiring SBOMs and letters of attestation , but the mandate and expectation to do so are gone. Agencies are still expected to maintain a complete inventory of software and hardware used, and to develop assurances according to their needs. SBOMs, which detail the components and dependencies used in a piece of software, are generally good to have because much of the sophisticated software in the wild these days uses dozens of components (if not more), and all it takes is one bad vulnerability in one of those components to have supply chain consequences . Having provenance helps defenders get ahead of such a thing, and letters of attestation help ensure there's a minimum software quality used by the public sector. The rollback, then, is "a disaster," according to Jeff Williams, co-founder and chief technology officer (CTO) of Contrast Security as well as a founder of the Open Worldwide Application Security Project (OWASP). He tells Dark Reading that former President Joe Biden's cybersecurity executive order called for radical transparency, and that while M-22-18 was a "watered down version of application security best practices," it was also a "major victory toward a market-based approach to cybersecurity." He adds, "The new OMB 26-05 takes us back to square zero. Now agencies are free to do whatever they want to ensure their code is secure and nobody has to attest to anything. And to be clear, attestation is very different from compliance," SBOMs: Granular Compliance vs. Risk Reduction And yet, the problem is complex . While it may be tempting to join Williams in finger wagging at the new memorandum (as one would at acting Cybersecurity and Infrastructure Security Agency chief Madhu Gottumukkala uploading sensitive documents to a public version of ChatGPT over the summer, or at the widespread public-sector cyber layoffs), this situation is a bit different, some argue. Tim Amerson, federal field chief information security officer (CISO) at GuidePoint Security, tells Dark Reading that while the original memos were well intentioned, "in practice, the effort was often optimized for documentation over risk reduction." He continues, "Teams spent time collecting artifacts but lacked the maturity, tooling, or threat context to operationalize them. The M-26-05 shifts focus back to what matters: that agencies are accountable for outcomes. Security decisions are now explicitly tied to mission risk, the threat environment, and operational impact, rather than to a universal checklist. That aligns far better with zero-trust principles , modern risk management, and how adversaries actually operate." NetRise CEO Tom Pace meanwhile feels the new guidelines offer agencies flexibility to focus scrutiny where it matters most, toward high-impact systems and critical infrastructure, "without forcing low-risk or commodity software through the same process." Secure Software Rollbacks: The Potential Long-Term Impact for Organizations One would hope that the new memorandum would mean a move away from granular documentation and toward more thoughtful, case-by-case thinking. Agencies would then, in a perfect world, become an active participant in considering whether software is secure, which would raise expectations for vendors across the board. Contrast's Williams does not see that as the most likely outcome. "I expect that most vendors will do the minimum and that procurement will have no way to verify [the security of software an organization is buying]," he says. Some also worry that a lack of required standards will remove important incentives for agencies to stay cyber-aware even in the face of everything else federal agencies are up against. "By rescinding the prior memos without clearly replacing them with a mandatory minimum baseline, OMB is betting heavily on agency discipline and procurement rigor," says Exabeam CISO Kevin Kirkwood. "Maturity varies across the agencies, and some will quietly relax requirements, and vendors will route their weakest practices to the most permissive buyers. This will cause a fragmentation in the discipline and can make the problems worse." Feds Should Preserve NIST's Framework as the Baseline Indeed, eliminating the mandates take federal agencies outside of conventional cybersecurity wisdom, Veracode chief security evangelist Chris Wysopal argues: "While the requirements may have exposed gaps in less mature programs, the attestation itself was lightweight and aligned with widely accepted secure development principles." Similarly, Tim Mackey, head of software supply chain risk strategy at application security vendor Black Duck, further notes that in the paragraph after Vought referred to NIST's Secure Software Development Framework (SSDF) as unproven and burdensome, the OMB director linked to it as a resource for how best to proceed. "While it's debatable whether self-attestations, such as those in M-22-18, are worth much, the reality is that attestation to elements of the SSDF has been a requirement for several years, and any associated burden reflects the need to improve cybersecurity practices," he explains. Long term, the impact of M-26-05 depends on how agencies implement this new flexibility. "If agencies create bespoke attestation requirements, vendors will spend more effort interpreting and responding to inconsistent contractual demands rather than improving software security. That fragmentation would be counterproductive," Wysopal says. "However, if agencies continue to rely on the SSDF as a common reference point when requesting attestations on a risk-based basis, security outcomes should not materially degrade. The key risk introduced by M-26-05 is inconsistency, not the removal of attestation itself; maintaining a shared SSDF-based baseline is critical to avoiding that outcome." About the Author Alexander Culafi Senior News Writer, Dark Reading Alex is an award-winning writer, journalist, and podcast host based in Boston. After cutting his teeth writing for independent gaming publications as a teenager, he graduated from Emerson College in 2016 with a Bachelor of Science in journalism. He has previously been published on VentureFizz, Search Security, Nintendo World Report, and elsewhere. In his spare time, Alex hosts the weekly Nintendo podcast Talk Nintendo Podcast and works on personal writing projects, including two previously self-published science fiction novels. See more from Alexander Culafi