CISA SSDAF

CISA Secure Software Development Attestation Form — CISA (US Department of Homeland Security)

Also known as: Secure Software Development Attestation Form, SSDAF, Secure Software Attestation

At a glance

Current version
Secure Software Development Attestation Form (Version 1.0)
Published 11 March 2024. source
Status
In force
Next deadline
in 142 days
Expiration date of the form's current OMB approval (OMB control number 1670-0052) source
Who must comply
Producers of software used by US federal agencies, when the buying agency asks for an attestation. Since January 2026 using the form is the agency's choice, not a government-wide requirement. source
Written by
CISA (DHS) publishes the common form (OMB control number 1670-0052). OMB M-26-05 rescinded the memoranda that made it mandatory; agencies may still use it. source
Last change
None recorded yet

The single form on which a software producer tells a federal buying agency, over a signature, that it follows the secure development practices of NIST SP 800-218. Federal agencies may still ask for it, but it is no longer a government-wide requirement: it is a statement an officer of the company is answerable for when an agency does ask.

Recent changes

No changes recorded yet — we are watching, and nothing has been published.

  1. in 142 days Expiration date of the form's current OMB approval (OMB control number 1670-0052)
  2. OMB M-26-05 rescinds M-22-18 and M-23-16; agencies may still use the attestation form but are not required to
  3. CISA's Repository for Software Attestation and Artifacts opens for online submission of attestation forms
  4. Final attestation form released by CISA and OMB
  5. OMB M-23-16 updates M-22-18 on software attestation (rescinded January 2026)
Show 1 earlier date
  1. OMB M-22-18 requires attestation for software used by federal agencies (rescinded January 2026); software developed after this date was in scope

Version history

  1. Secure Software Development Attestation Form (Version 1.0) Major versionCurrent

    Final common form released by CISA and OMB after stakeholder engagement. source

    More
    • The producer's CEO or a designee attests that the software is built in secure environments, that the producer maintains trusted source code supply chains and provenance, and that it checks for security vulnerabilities on an ongoing basis.
  2. Common form, second request for comment Draft

    Revised draft of the common form published in the Federal Register for public comment. source

  3. Common form, first request for comment Draft

    First draft of the common form published in the Federal Register for public comment. source

Who it applies to

M-26-05 rescinded M-22-18 and M-23-16 on 23 January 2026; agencies may still choose to use the form.

In scope
Under M-22-18 as amended, attestation covered software developed after 14 September 2022, older software with a major version change after that date, and continuously delivered software such as SaaS. source
Out of scope
Out of scope were agency-built software, open source obtained directly by an agency, third-party components inside a product, and freely available software. source
Rescinded
M-26-05 rescinded M-22-18 and M-23-16 on 23 January 2026. source
Where it still matters
Agencies may still choose to use the Secure Software Development Attestation Form. source

How compliance is assessed

The form is a self-attestation signed by the CEO or a designee who can bind the company.

Who signs
The form is a self-attestation signed by the CEO or a designee who can bind the company. source
Coverage
It can cover the whole company, one product or several versions, and stays binding for future versions until the producer says its practices no longer conform. source
Third-party assessment
Instead of signing, a producer may attach a third-party assessment by a FedRAMP-certified or agency-approved 3PAO. source
Gaps
A producer that cannot attest to some practices may submit a plan of action and milestones (POA&M). source
Submission
Forms can be submitted online through CISA's repository. source

Enforcement and penalties

If a producer does not provide the requested information, the agency may stop using the software.

Missing information
If a producer does not provide the requested information, the agency may stop using the software. source
False statements
Wilfully false or misleading statements may violate 18 U.S.C. § 1001, a criminal statute. source
Since M-26-05
Since M-26-05, each agency chooses whether to use the form, with assurance policies that match its own risk determinations. source

Documents

  1. Template Secure Software Development Attestation Form with instructions (PDF)
  2. Guidance CISA resource page for the attestation form (with Spanish translation)
  3. Guidance Repository for Software Attestations and Artifacts (RSAA) User Guide
  4. Law text OMB M-26-05 – Adopting a Risk-based Approach to Software and Hardware Security

Frequently asked questions

Is the CISA secure software attestation form still required?

Not government-wide. OMB M-26-05 (23 January 2026) rescinded M-22-18 and M-23-16. Each agency now sets its own risk-based software assurance policy and may choose to use the attestation form. source

Who must sign the secure software development attestation form?

The software producer's CEO or a designee who is an employee of the producer and has authority to bind the company. source

Does open source software need an attestation?

Open source software freely and directly obtained by a federal agency, and third-party open source components inside a product, are out of scope. Producers using third-party components must still attest to steps they take to reduce the risk from them. source

Verified against official sources on 18 October 2026. We monitor the official sources for this framework. Watching since 20 September 2026. Subscribe to CISA SSDAF (RSS)