Understanding OMB M-26-05: The Shift From Compliance To Risk-Based Decision Making in Federal Software and Hardware Security
On January 23, 2026, the Office of Management and Budget (OMB) released memorandum M-26-05, “Adopting a Risk-Based Approach to Software and Hardware Security,” formally rescinding the previous software supply chain security requirements established under M-22-18, “Enhancing the Security of the Software Supply Chain through Secure Software Development Practices,” and M-23-16, a companion policy. The rationale was blunt: M-22-18 ‘imposed unproven and burdensome software accounting processes that prioritized compliance over genuine security investments’ and ‘diverted agencies from developing tailored assurance requirements.’ This policy shift moves federal agencies away from prescriptive compliance requirements toward agency-directed risk assessments tailored to its mission needs.
What M-26-05 Changes
The memo eliminates mandatory attestation and software bill of materials (SBOM) requirements while preserving agency discretion to use these tools voluntarily. Agencies must still maintain comprehensive software and hardware inventories, especially of critical assets, but assurance policies must now reflect agency-specific risk determinations.
The memo also expands the scope to include hardware security and references NIST SP 800-218, “Secure Software Development Framework,” and CISA guidance — specifically, “A Hardware Bill of Materials (HBOM) Framework for Supply Chain Risk Management” and “2025 Minimum Elements for a Software Bill of Materials (SBOM)” — as optional resources. This turn in approach is important because SBOM formats (SPDX, CycloneDX) lacked interoperability, making aggregation and analysis across vendors difficult. More so, SBOMs for cloud services were particularly problematic — the runtime production environment changes constantly, making point-in-time SBOMs stale quickly!
This change acknowledges a practical reality: while SBOMs hold theoretical value for supply chain transparency, federal agencies struggled to operationalize them. Many lacked the tooling to ingest, correlate, and act on SBOM data, while vendors often resisted providing them or delivered formats that defied meaningful analysis.
Why Risk-Based Approaches Enable Deeper Product Examination
The shift to risk-based security validation creates an opportunity for agencies to conduct more meaningful assessments of the products they consume. Under compliance-driven models, the focus often centers on whether vendors have completed required attestations or delivered specified documentation. A risk-based approach instead asks whether specific products introduce acceptable risk given an agency’s threat environment, data sensitivity, and operational context. This requires agencies to move beyond flat asset inventories, and toward criticality-based classification. Not all software carries equal risk- a collaboration tool used by a small team warrants different scrutiny than a platform processing personally identifiable information (PII) at scale. Criticality analysis enables agencies to prioritize assessment depth and security investment based on actual mission impact, data sensitivity, and exposure rather than applying uniform requirements across disparate risk profiles.
This is where security architecture becomes essential. A mature security architecture practice provides the analytical framework for understanding how individual products fit within the broader enterprise environment. When evaluating a software product for consumption, security architects can map the product’s capabilities against the agency’s reference architecture, identify integration points with existing systems, and assess where trust boundaries exist. This examination extends beyond checking whether a vendor follows security development practices to understanding how the product will actually operate within the agency’s specific environment.
Security architecture enables visibility into risks that standardized compliance artifacts cannot capture. Consider the difference between a vendor attestation confirming they follow NIST SP 800-218 practices versus an actual architectural analysis showing how the vendor’s product will interact with the agency’s identity systems, data repositories, and network segments. The attestations tell you about the vendor’s development process; the architectural analysis tells you about your actual risk exposure.
For deeper exploration on how security architecture and enterprise visibility intersect with risk-based governance, see my earlier blog post, “Why Your Federal Enterprise Architecture Is Incomplete,” and the accompanying white paper, “The SaaS Visibility Gap: Why Federal Enterprise Architecture Is Increasingly Incomplete.” Both examine how agencies can close the gap between documented architecture and operational reality — a prerequisite for the kind of meaningful product assessments M-26-05 now demands.
Connecting Product Security to Enterprise Risk Management
A structured process for evaluating software and hardware should connect individual product assessments to the organization’s broader enterprise risk management program. When agencies make risk determinations about specific products, those decisions carry implications for organizational risk posture, budget allocation, and operational capability.
From an enterprise risk management perspective, product security assessments generate risk data that should inform leadership decision-making. If an agency’s architecture team identifies that a particular cloud service requires accepting certain residual risks, that information belongs in the agency’s risk register and should factor into authorization decisions. The risk-based approach outlined in M-26-05 creates space for agencies to build these connections deliberately rather than treating software security as an isolated compliance exercise.
The economic impact extends beyond individual procurement decisions. When agencies conduct thorough architectural assessments of products before acquisition, they reduce the likelihood of discovering integration problems, security gaps, or capability mismatches after contracts are signed. The cost of identifying that a product cannot meet security requirements during a structured evaluation process is far lower than discovering the same problem during implementation or, worse, during a security incident. Organizations that invest in mature security architecture capabilities effectively reduce total cost of ownership across their technology portfolio.
Capability Management and Organizational Maturity
The flexibility granted by M-26-05 places greater responsibility on agencies to develop and maintain the internal capabilities necessary for effective risk-based decision making. An agency cannot conduct meaningful product security assessments without skilled security architects who understand both the technical characteristics of products and the operational context in which those products will operate.
Capability maturity models provide useful frameworks for agencies assessing their readiness to implement risk-based approaches. Organizations at lower maturity levels may find that prescriptive compliance requirements actually served as helpful guardrails, ensuring minimum security practices even without sophisticated internal assessment capabilities. As agencies mature, they develop the processes, expertise, and institutional knowledge to make nuanced determinations that better serve their specific missions and objectives.
The practical implication is that agencies should honestly assess their current capability maturity before designing their risk-based assurance processes. An agency with a well-established security architecture function, experienced risk management professionals, and mature governance processes will implement M-26-05 very differently than an agency still building these foundational capabilities. Both can comply with the memorandum’s requirements, but the depth and sophistication of their product security assessments will differ significantly.
Looking Forward
M-26-05 represents a policy decision that greater security comes from agency-tailored risk assessments than from standardized compliance processes. Whether this proves correct will depend largely on whether agencies invest in the security architecture, enterprise risk management, and capability development necessary to make risk-based approaches effective. From my point of view, the outlook is mixed. Agencies with mature security architecture programs will likely thrive under this flexibility– they’ve been constrained by prescriptive requirements that diverted resources from genuine risk reduction. But for agencies that relied on compliance frameworks as a substitute for security judgment, the removal of guardrails may expose capability gaps that take years to close. The policy assumes a baseline of enterprise maturity that not all agencies possess, and without additional investment in workforce development and security architecture capabilities, some will struggle to meet the standard M-26-05 implicitly demands.
For organizations that have already built mature security practices, the new policy provides welcome flexibility to focus resources on genuine risk reduction rather than compliance documentation. For organizations still developing these capabilities, the challenge will be building the institutional capacity to conduct meaningful assessments while maintaining adequate security posture during the transition.
The inclusion of hardware security within scope and the explicit acknowledgment that agencies face sophisticated threat actors suggest that future federal cybersecurity policy will continue to emphasize substantive security outcomes over process compliance. Agencies that use this transition period to strengthen their security architecture capabilities and enterprise risk management integration will be better positioned to meet whatever requirements emerge next.
