CISA's Secure Software Development Attestation Form, explained

CISA's Secure Software Development Attestation Form is the standard form federal software producers used to attest that their development practices followed the NIST Secure Software Development Framework (SSDF, SP 800-218), under a requirement OMB first imposed in September 2022. Since 23 January 2026, that requirement is no longer government-wide or mandatory: OMB Memorandum M-26-05 rescinded the memos that required it, leaving each federal agency to decide for itself whether to still use the form.

Where the requirement came from

The attestation requirement traces back to Executive Order 14028, "Improving the Nation's Cybersecurity" (12 May 2021), which directed NIST to issue software supply chain security guidance and directed OMB to require agencies to comply with it. OMB's resulting memorandum, M-22-18, Enhancing the Security of the Software Supply Chain through Secure Software Development Practices, signed 14 September 2022 by then-Director Shalanda D. Young, stated the core rule directly: "Federal agencies must only use software provided by software producers who can attest to complying with the Government-specified secure software development practices, as described in the NIST Guidance" — meaning NIST SP 800-218 and NIST's companion Software Supply Chain Security Guidance.

M-22-18 gave agencies three ways a producer could satisfy the requirement:

1. Self-attestation — a signed statement covering the producer's name, the products it applies to, and a declaration that the producer follows the practices itemized in the standard form. M-22-18 calls this "the minimum level required."
2. A Plan of Action and Milestones (POA&M) — if a producer could not attest to one or more practices, it could instead "identify those practices to which they cannot attest, document practices they have in place to mitigate those risks," and submit a POA&M; the agency could then still use the software if it found that documentation satisfactory.
3. A third-party assessment — from a FedRAMP-certified Third Party Assessor Organization (3PAO) or one approved by the agency, "acceptable in lieu of a software producer's self-attestation, including in the case of open source software."

OMB Memorandum M-23-16 (9 June 2023) then adjusted the mechanics without changing the underlying requirement: it tied the compliance deadlines to the release of CISA's standard "common form" rather than to M-22-18's original publication date, clarified that agencies do not need to collect attestations for third-party components bundled inside a producer's end product, and exempted no-cost, publicly available proprietary software (such as free web browsers) from attestation collection.

The common form and its deadlines

CISA published the finalized Secure Software Development Attestation Common Form on 11 March 2024. CISA's own announcement describes it as developed "in close consultation with the Office of Management and Budget (OMB)" and "based upon practices established in" NIST SP 800-218, stating the release was "a major step in the implementation of its requirement that producers of software used by the Federal Government attest to the adoption of secure development practices."

Per M-23-16's formula, that publication date started two clocks: critical-software attestations were due "no later than three months after" the form's Paperwork Reduction Act approval, and all-software attestations six months after. CISA also stood up the Repository for Software Attestations and Artifacts (RSAA), an online submission system, shortly after the form's release, as an alternative to emailing attestations directly to agencies.

What changed on 23 January 2026

On 23 January 2026, OMB Director Russell T. Vought issued Memorandum M-26-05, Adopting a Risk-based Approach to Software and Hardware Security. It rescinds the mandate outright: "OMB Memoranda M-22-18 and M-23-16, a companion policy, are hereby rescinded." The memo's stated rationale is that 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 for software."

In place of a single government-wide form, M-26-05 puts the decision back with each agency: "Each agency head is ultimately responsible for assuring the security of software and hardware that is permitted to operate on the agency's network. There is no universal, one-size-fits-all method of achieving that result." Agencies must still "maintain a complete inventory of software and hardware and develop software and hardware assurance policies and processes that match their risk determinations," but using the attestation form itself is now explicitly optional — the memo states 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," and may separately choose to require an SBOM by contract. CISA's own resource page for the form has already been updated to describe it as implementing M-26-05 rather than the rescinded M-22-18, confirming the form itself was not withdrawn — only the mandate to use it.

What M-26-05 does not rescind is notable: it leaves Executive Order 14028 in place, continues to reference NIST SP 800-218 as a resource, and points agencies to CISA's Hardware Bill of Materials (HBOM) Framework and the CISA-led Minimum Elements for an SBOM (see our SBOM Minimum Elements guide) as further optional tools.

What this means in practice

A software producer selling to the US federal government today has no single, government-wide attestation to point to — each agency may now ask for a self-attestation, a POA&M, a third-party assessment, an SBOM on request, all of them, or none, depending on that agency's own risk-based policy. Existing contracts and solicitations written during 2024–2025 may still reference the now-rescinded M-22-18 requirement by name; producers should confirm with the contracting agency whether that clause still reflects current policy rather than assuming it does. For teams that already built an SSDF-aligned development process to satisfy the original mandate, that work is not wasted — NIST SP 800-218 itself was not withdrawn (see our NIST SSDF SP 800-218 guide), and agencies retain the option to request the same attestation form on a case-by-case basis.

SoftWSP can help assess firmware and software development practices against the NIST SSDF baseline that both the old mandate and the new risk-based approach still point to: see device firmware security.

This guide summarises public OMB and CISA publications; it does not constitute legal or compliance advice.