Back every SSDAF attestation with evidence you can stand behind

It is a common form, released by CISA in March 2024, on which software producers attest to US federal agencies that their software was built using secure development practices. The practices come from the NIST Secure Software Development Framework and cover secure build environments, trusted source code supply chains, provenance of code and components, and checking for and handling vulnerabilities. A senior officer, normally the CEO or a designee, signs it on behalf of the company.

Not government-wide. OMB memo M-26-05, issued on 23 January 2026, rescinded M-22-18 and M-23-16, which had required agencies to collect the form from their software suppliers. Agencies now set their own software assurance policies based on risk and may still ask for a self-attestation, the form itself or a software bill of materials. Producers should check each contract and agency request rather than assume the form is no longer needed.

Software producers whose software is used by a federal agency sign the form when an agency asks for it. It applies to the producer, not a reseller, and covers software developed after 14 September 2022 or earlier software that has since had major version changes or is delivered through continuous changes. The form must be signed by the CEO or a designee who can legally bind the organisation.

Section III contains four attestations. The software is developed and built in secure environments, a good-faith effort is made to maintain trusted source code supply chains, provenance is maintained for internal code and third-party components, and automated tools or comparable processes check for security vulnerabilities. The first and fourth statements are broken into detailed practices such as multi-factor authentication, logging, encryption of sensitive data and running a vulnerability disclosure programme.

A producer that cannot confirm one or more practices can document the gaps and submit a plan of action and milestones (POA&M) explaining how and when they will be addressed. The agency then decides whether to accept it. Signing an attestation that is not true creates legal risk, including potential liability under the False Claims Act, so every statement should be backed by evidence before signing.

Each attestation maps to tasks in NIST SP 800-218, the Secure Software Development Framework, so the SSDF is the best reference for what good looks like. SOC 2 and ISO 27001 cover many supporting controls, such as access control, MFA, logging and vulnerability management, but they do not replace the form. Evidence gathered for those programmes can be reused to support the attestation.

Yes. Instead of self-attesting, a producer can provide a third-party assessment from a FedRAMP third-party assessment organisation (3PAO) or an assessor approved by the agency, using the NIST SSDF as the baseline. This was set out in OMB guidance under M-22-18 and M-23-16, and individual agencies may still accept it under their own policies following M-26-05.

The SSDAF is mapped in OneClickComply's control library and is available on request. It links each attestation to controls you may already operate for ISO 27001, SOC 2 or NIST frameworks, and automated evidence collection and continuous monitoring help you hold current evidence for each statement. OneClickComply does not sign or certify attestations; your signing officer remains responsible for them.