OMB Rescinds the “Common Form” Secure Software Attestation Requirement

Key Takeaways

• OMB drops mandatory Common Form attestation for federal software
• Agencies must adopt risk‑based, tailored security assessments
• SBOMs still required for cloud providers’ production environments
• Software inventory obligations remain unchanged across agencies
• Vendors must monitor agency‑specific requirements and stay ready

Summary

On Jan. 23, 2026 the Office of Management and Budget issued Memorandum M‑26‑05, rescinding the Biden‑era mandate that all federal agencies obtain a CISA “Common Form” software attestation. The new memo replaces the one‑size‑fits‑all requirement with a risk‑based, agency‑specific approach while keeping the software inventory and SBOM obligations for cloud providers. Agencies may still voluntarily use the Common Form or NIST guidance, but they are no longer forced to do so. The change aims to shift focus from compliance paperwork to genuine security investments.

Pulse Analysis

The Office of Management and Budget’s latest memorandum marks a decisive pivot in federal software‑supply‑chain policy. Earlier memoranda—M‑22‑18 and M‑23‑16—required every agency to collect a standardized self‑attestation using CISA’s Common Form and, in many cases, a Software Bill of Materials (SBOM). Those directives were criticized for imposing a compliance‑heavy process that often eclipsed actual risk mitigation. By rescinding the blanket requirement, OMB signals a broader governmental shift toward risk‑based governance, aligning procurement practices with the nuanced threat landscape of both software and hardware components.

Under M‑26‑05, each agency must conduct its own risk assessment and define security requirements that reflect its mission‑critical workloads. While the memorandum retains the obligation to maintain a comprehensive software inventory, it introduces a more flexible framework for SBOM requests—particularly for cloud service providers, which must now furnish SBOMs that describe the live production environment rather than just test builds. This nuance acknowledges the growing reliance on cloud‑native services and the need for real‑time visibility into runtime dependencies. Agencies can still elect to use the Common Form or NIST Secure Software Development guidelines, but they are no longer compelled to do so, fostering a market where security controls are tied to actual risk rather than paperwork.

For vendors targeting federal contracts, the policy change translates into both opportunity and uncertainty. Companies must stay alert to divergent agency‑specific security clauses, proactively engage in risk‑assessment dialogues, and be prepared to deliver detailed inventory data and production‑environment SBOMs on demand. The move also encourages investment in adaptable compliance tooling that can satisfy a spectrum of agency requirements without extensive re‑engineering. As the federal government continues to refine its cyber‑risk posture, firms that embed robust, risk‑aligned security practices into their development lifecycles will be best positioned to win contracts and maintain long‑term relationships with government customers.