For two years, software producers selling to the federal government worked from a single assumption: sign the CISA Common Form or the agency cannot use your product. That assumption is no longer correct — and the replacement is harder to track, not easier.
In Memorandum M-26-05, "Adopting a Risk-based Approach to Software and Hardware Security," issued January 23, 2026, the Office of Management and Budget rescinded OMB Memoranda M-22-18 and M-23-16 — the policies that required agencies to obtain a secure software development self-attestation before using third-party software. In their place, OMB directs that "[e]ach agency head is ultimately responsible for assuring the security of software and hardware that is permitted to operate on the agency's network," and that "[t]here is no universal, one-size-fits-all method of achieving that result."
What the Memorandum Actually Says
OMB's stated rationale is blunt. M-22-18, it says, "imposed unproven and burdensome software accounting processes that prioritized compliance over genuine security investments," diverted agencies from developing tailored assurance requirements, and "neglected to account for threats posed by insecure hardware." Both M-22-18 and its companion M-23-16 are rescinded.
Three things survive the rescission, and they are the operative parts for anyone selling software or hardware to the government:
- Agencies must still inventory and still assure. Agencies "shall continue to maintain a complete inventory of software and hardware and develop software and hardware assurance policies and processes that match their risk determinations and mission needs."
- The attestation form is now optional, not obsolete. OMB states that agencies "may choose to use the government-wide secure software development resources developed under M-22-18, such as the Secure Software Development Attestation Form." CISA still publishes the form and the Repository for Software Attestations and Artifacts.
- SBOMs move into contract terms. Agencies "may also choose to adopt contractual terms that require a software producer to provide a current software bill of materials (SBOM) upon request." For a cloud platform, OMB says the term should specify an SBOM of the runtime production environment.
The memorandum points agencies to NIST SP 800-218 (the Secure Software Development Framework), CISA's 2025 Minimum Elements for a Software Bill of Materials (published in draft August 22, 2025), and CISA's Hardware Bill of Materials (HBOM) Framework from September 2023 as reference material.
Why "Less Mandatory" Is Not "Less Work"
A single governmentwide form is a compliance burden, but it is a knowable one. You fill it out once, you know what it asks, and every agency asks the same thing. Replacing it with agency-tailored assurance means the requirement now lives where every other contract cybersecurity requirement lives — in the solicitation, the contract terms, and the agency's own policy documents.
That has three practical consequences.
The requirement moves from policy to contract. If an agency wants an attestation, an SBOM, or a specific set of secure-development practices, it will get there through contractual terms. You will not find it by reading an OMB memo; you will find it by reading your solicitation. This is the same dynamic that makes agency-specific CUI guidance easy to miss — see GSA's move to NIST SP 800-171 Rev. 3 for the parallel on the information-protection side.
Hardware is now explicitly in scope. OMB faulted the prior policy for ignoring hardware risk and cites CISA's HBOM framework. Producers of connected or embedded products should expect agency-specific hardware assurance language — a trend also visible in NIST's draft IoT product requirements for federal buyers.
Whatever you sign still binds you. Optional-by-policy does not mean optional-in-fact. If an agency puts the attestation form or an SBOM term in your contract, it is a contract requirement, and the representation behind it carries the same weight it always did. Product-security misrepresentations have already produced False Claims Act exposure — see the Illumina resolution and the broader pattern on the enforcement page. (A settlement is not an admission of liability.)
What to Do Now
Stop relying on a governmentwide answer. Check each active contract and each pending solicitation for software and hardware assurance language. Find My Requirements is built for that mapping.
Keep your SSDF alignment. NIST SP 800-218 remains the reference OMB points agencies to, and agencies may keep using the form. Maintaining the underlying practices is cheaper than rebuilding them when a customer asks. The frameworks reference explains where SSDF sits.
Get SBOM-ready before it is a contract term. "Upon request" terms are easy for an agency to add and hard to satisfy on short notice — particularly the runtime-environment SBOM for cloud offerings.
Do not update your public claims to say attestation is no longer required. It is no longer governmentwide-mandated. It may still be required of you. Those are different statements, and only one of them is safe to make. The build-a-program guide covers documenting that distinction internally.
Key Takeaways
- OMB Memorandum M-26-05 (January 23, 2026) rescinded M-22-18 and M-23-16, ending the governmentwide requirement that agencies collect a secure software development self-attestation before using third-party software.
- Agencies must still maintain complete software and hardware inventories and adopt assurance policies matched to their own risk determinations; they may still use the CISA attestation form and may add contractual SBOM-on-request terms, including runtime-environment SBOMs for cloud platforms.
- The obligation did not disappear — it moved into agency-specific contract terms, so read each solicitation rather than assuming a single federal standard, and keep SSDF and SBOM capability in place.