Is the Secure Software Development Attestation Form Still Required?

Not by OMB. M-26-05 rescinds M-22-18 and "M-23-16, a companion policy," which together required agencies to get an attestation from a software producer before using its software. It replaces that rule with agency discretion: agencies "may choose" to keep using the form. M-22-18 had said the FAR Council planned rulemaking on a uniform form, and M-26-05 does not mention it, so check each solicitation for a FAR, supplement or agency clause that asks for one.

OMB gives its reasoning in two sentences. It says M-22-18 "imposed unproven and burdensome software accounting processes that prioritized compliance over genuine security investments" and "neglected to account for threats posed by insecure hardware." In its place, the memo says each agency head "is ultimately responsible for assuring the security of software and hardware" on the agency's network and should validate provider security "based on a comprehensive risk assessment."

Two things did not become optional. Agencies "shall continue to maintain a complete inventory of software and hardware," and they must develop software and hardware assurance policies "that match their risk determinations and mission needs." For a producer, the question to ask is whether this agency's policy or this solicitation requires an attestation.

M-22-18, dated September 14, 2022, carried out Executive Order 14028's direction that OMB require agencies to follow the NIST guidance issued under Section 4(e). Its core sentence: "Federal agencies must only use software provided by software producers who can attest to complying with the Government-specified secure software development practices." That covered software developed after the memo's date and existing software that went through a major version change, and it excluded software agencies built themselves. The common form adds software delivered through continuous changes, such as software as a service.

It also set an exception path and deadlines. A producer that could not attest to every practice could list the gaps, document its mitigations and submit a plan of action and milestones (POA&M), and the agency could accept that. A FedRAMP third-party assessment organization (3PAO) assessment could stand in for the self-attestation. As originally written, it gave agencies 270 days to collect attestations for "critical software" and 365 days for everything else in scope, with extensions and waivers requested from OMB. M-23-16, issued June 9, 2023, updated the memo. MeriTalk reports that the government-wide form was approved in March 2024 and that CISA then announced its Repository for Software Attestation and Artifacts for submitting forms. M-26-05 does not mention the repository, so ask the agency where a requested form should go.

The common form (Version 1.0) must be signed by the chief executive officer or a designee "who must be an employee of the software producer and have the authority to bind the corporation." The signer attests that the company "presently makes consistent use" of four groups of practices, each mapped in the form's appendix to a subsection of Executive Order 14028 and to tasks in NIST SP 800-218, the Secure Software Development Framework (SSDF):

1. Developing and building software in secure environments, including separated environments, logged and audited trust relationships, multi-factor authentication and encrypted credentials (Section 4(e)(i)).
2. A good-faith effort to maintain trusted source code supply chains with automated tools or comparable processes (Section 4(e)(iii)).
3. Maintaining provenance for internal code and third-party components "to the greatest extent feasible" (Section 4(e)(vi)).
4. Checking for vulnerabilities on an ongoing basis and before each release, with a policy to address them and a vulnerability disclosure program (Section 4(e)(iv)).

Two lines deserve attention before anyone signs. The signer also attests that the producer "will notify any agency to which it has submitted this form if and when the producer ceases to make consistent use of the practices." And the form's Privacy Act statement warns that "Willfully providing false or misleading information may constitute a violation of 18 U.S.C. § 1001, a criminal statute." The form's instructions and its "extension or waiver" option still cite M-22-18 and M-23-16 as authority, so an agency that keeps using it may need its own instructions or addendum.

The M-22-18 column reflects that memo's original text, before the M-23-16 update.

As a contract term, at the agency's choice. A software bill of materials (SBOM) is a list of the components and dependencies that make up a piece of software, which lets an agency check whether a newly disclosed vulnerability affects a product it runs. M-26-05 says agencies may require "a current software bill of materials (SBOM) upon request," and a footnote says agencies adopting that term for a cloud platform "should specify that the producer must provide an SBOM of the runtime production environment upon request." That is a different artifact from the build SBOM many producers generate for shipped code, so cloud providers should know whether their tooling can produce one.

As references for "additional information and options," the memo lists CISA's 2025 Minimum Elements for an SBOM, "published in draft form on Aug. 22, 2025," along with NIST SP 800-218 and CISA's HBOM framework from September 2023. M-22-18, by contrast, required SBOMs to use the formats in the National Telecommunications and Information Administration's (NTIA) minimum elements report or CISA successor guidance. Before writing a specific version into a contract, confirm which one is current on CISA's site.

A new version is in draft. NIST released the initial public draft of SP 800-218 Rev. 1, SSDF version 1.2, on December 17, 2025, "per Executive Order 14306," and the comment period closed January 30, 2026. As of November 7, 2026, NIST's project page still lists it as a draft. Version 1.1, released February 3, 2022, is the final version, and it was the only final version when the attestation form, with its task references (PO.5.1, PW.4.4, RV.1.1 and the rest), was published. If an agency asks a producer to map its practices to the SSDF, it helps to say which version.

For agencies, M-26-05 removes the default, so the evidence has to be named. Decide in your software assurance policy which software needs which evidence (a signed form, a 3PAO assessment, an SBOM on request, proof of a vulnerability disclosure program) and say so early in the solicitation. If an awarded contract already includes an attestation or SBOM requirement, the contracting officer decides whether it stays or changes; the memo does not address existing contracts.

For producers, keep a current attestation ready even if no one has asked this year. Forms you signed earlier include a promise to notify agencies if the listed practices lapse; ask counsel whether those submissions still carry that commitment. Know whether you can deliver a runtime SBOM for cloud products, and check each solicitation for agency-specific addenda. Our DevSecOps services page describes how we build security checks into delivery pipelines.

The form's line on multi-factor authentication applies to development and build environments, not to the product's users; federal requirements for user sign-in are covered in our post on phishing-resistant MFA.