The Conventional Wisdom
Federal agencies are embracing OMB M-26-05, which promises a shift from checkbox compliance to "risk-based validation." This move aims to replace rigid, one-size-fits-all mandates with security decisions tailored to each agency's threat model. It sounds like a step forward, moving beyond compliance theater to real security.
Why This Approach Is Incomplete
Risk-based security without a shared baseline isn't flexibility—it's ambiguity with a better marketing pitch.
When OMB replaced M-22-18 and M-23-16 with M-26-05, they removed a critical component: a common language for what "secure software" means. The old memos, despite their flaws, provided a foundation. Agencies knew what evidence to collect and what questions to ask vendors.
Now, each agency interprets "risk-based validation" differently. Your procurement team at the Department of Education might accept a vendor's self-assessment, while the Department of Defense demands continuous SBOM updates and third-party attestation. Neither approach is wrong, but they're not interoperable. When the next supply chain incident occurs, we'll see that "risk-based" meant different things across agencies.
The real issue: risk-based security requires more structure, not less. You need frameworks for comparing risks, shared taxonomies for vulnerabilities, and agreement on what evidence validates security claims. Without these, "risk-based" becomes "whatever sounds reasonable to the person reviewing this procurement."
The Evidence
Consider what M-26-05 actually enables. The memo allows agencies to request current SBOMs for cloud platforms, which is beneficial. However, it's optional. Agencies can decide whether SBOMs matter, and both decisions are compliant with the memo.
This creates a race to the bottom in procurement. Vendors will optimize for the least demanding agencies. Why maintain continuous SBOM generation if only a few agencies ask for it? Why invest in automated vulnerability disclosure if most procurement officers don't know what questions to ask?
This pattern has been seen before. When PCI DSS v4.0.1 introduced the "customized approach," some organizations treated it as permission to skip controls. The standard requires proving that custom controls meet the same objectives, but without assessor training and detailed documentation, teams defaulted to whatever seemed reasonable. OMB M-26-05 has the same structural problem, just without PCI's requirement to prove equivalence.
Consider the practical impact on your team. Under the old memos, you could point to specific requirements. Now, you're negotiating what "risk-based validation" means for each contract. You're explaining why your agency needs SBOMs when others don't ask. You're building evidence frameworks from scratch because there's no shared baseline to reference.
What to Do Instead
If your agency is implementing M-26-05, build your own baseline—and make it public.
Define your evidence requirements explicitly. Specify requirements clearly: "For any software processing PII, we require quarterly SBOMs in CycloneDX format, automated vulnerability scanning results from the last 30 days, and documentation of patch deployment timelines." Include these requirements in your procurement templates.
Borrow structure from mature frameworks. NIST 800-53 Rev 5 defines software supply chain controls. The NIST Cybersecurity Framework has supply chain risk management functions. Use these as your baseline, then add agency-specific requirements.
Treat SBOMs as minimum viable evidence, not the goal. M-26-05 mentions SBOMs, which is progress. But an SBOM is just an ingredient list. You need to know if these components are vulnerable, how quickly patches are deployed, and the vendor's disclosure process. Build your validation requirements around these questions, using the SBOM as supporting evidence.
Create shared validation criteria with peer agencies. Coordinate with other agencies in your sector. Define what "low risk" versus "high risk" software means for your context. Agree on minimum evidence requirements and publish these criteria so vendors can build to a consistent standard.
Document your risk decisions. When you accept a vendor without full evidence, document why. This creates institutional memory and makes your "risk-based" approach auditable.
When the Conventional Wisdom Is Right
The old approach needed to change. M-22-18's government-wide attestation timeline ignored the reality that some agencies were still running outdated systems. Requiring the same security evidence from a legacy mainframe and a modern cloud service was impractical.
Risk-based security is the right direction if done rigorously. Some agencies have mature risk management practices and the budget to evaluate vendors thoroughly. For them, M-26-05's flexibility enables better security decisions than checkbox compliance ever could.
The memo's emphasis on SBOMs for cloud platforms addresses a real gap. Cloud services change constantly, and static attestation doesn't reflect current operations. If agencies require current SBOMs and use them for continuous validation, that's a significant improvement over annual paperwork exercises.
The problem isn't risk-based security. The problem is assuming "flexibility" alone produces better outcomes. It doesn't. Flexibility without structure produces inconsistency. In procurement, inconsistency means vendors optimize for the lowest common denominator.
For risk-based security to work, agencies need model validation frameworks, shared evidence standards, and training for procurement officers evaluating security claims without a checklist. Until then, we've just traded compliance theater for risk-based theater. The lighting is better, but the audience still can't tell what's real.
