To complete the CISA Secure Software Development Attestation Form, download the current version from CISA’s attestation page or take it from the requesting agency, identify your company and the exact software product and version, check only the security-practice boxes your organization genuinely meets, have your CEO or an authorized employee-designee sign it, and submit the signed form through the Repository for Software Attestation and Artifacts (RSAA) portal at softwaresecurity.cisa.gov or by the email address printed on the form. One important piece of context before you start: in January 2026, OMB issued Memorandum M-26-05, which rescinded M-22-18 and M-23-16 and ended the government-wide mandate. Attestation is no longer automatic. Individual agencies now decide whether to require the form based on their own risk assessment, and those that do require it continue to use CISA’s common form. If a solicitation or contract modification asks you for it, everything below applies.
Who Has to File
The form is meant for organizations that develop or significantly modify software used by a federal agency. Under the original scope that many agencies still follow, it covers software developed after September 14, 2022, and existing software modified by a major version change after that date (for example, moving from 2.5 to 3.0 under semantic versioning). SaaS products delivered through continuous delivery pipelines are in scope as well.
Several categories sit outside the requirement, and agencies applying risk-based judgment tend to keep these exemptions in place:
- Software built by federal employees, or by contractors working under direct agency supervision. When the line is unclear, the agency CIO decides.
- Open-source software the agency obtains freely and directly. The agency still has to evaluate its security, but the producer does not attest.
- Proprietary tools offered at no cost and publicly available.
- Third-party components embedded inside attested software. Only the producer of the finished product attests, though that producer must maintain provenance data for the components and scan them with automated tools.
What You Are Attesting To
Every checkbox on the form traces back to a practice in the Secure Software Development Framework, published as NIST Special Publication 800-218. Read the SSDF alongside the form. It groups practices into four buckets:
- Prepare the Organization (PO). Your people, processes, and tools support secure development across the company: training, defined roles, and configured toolchains.
- Protect the Software (PS). Source code repositories, build systems, and distribution channels are protected from tampering and unauthorized access.
- Produce Well-Secured Software (PW). Releases contain minimal vulnerabilities, supported by code review, testing, and secure defaults.
- Respond to Vulnerabilities (RV). You find vulnerabilities in released software, disclose and patch them, and apply lessons learned.
The specific attestation statements ask you to confirm, among other things, that you separate build environments from development environments, maintain provenance data for code and components, use automated tools to scan for vulnerabilities, and operate a vulnerability disclosure process.
Filling Out the Form
The form has three parts: organizational identification, software identification, and the attestation statements.
Under organizational identification, provide your company’s full legal name, address, and point of contact. Under software identification, enter the exact product name and the version number or range you are attesting to. Each product gets its own form. You cannot bundle unrelated products into a single attestation.
The attestation statements are checkboxes. Check a box only if your organization actually follows that practice for the software version listed. If you cannot truthfully check every box, use the POA&M route described below rather than leaving boxes blank without explanation; agencies that see unexplained gaps will generally decline to use the product.
Signature authority is narrow. The form must be signed by your CEO or by a designee who is an employee of the software producer and who has authority to bind the corporation. Contractors, outside counsel, and outside advisors cannot sign. The signer is personally certifying every checked item, which is why most companies route the form through security and legal review before it is signed.
Submitting the Form
CISA offers two submission paths.
The primary path is the RSAA portal at softwaresecurity.cisa.gov. Register for an account, log in, go to the upload section, attach the signed form along with any supporting artifacts the agency has requested, and confirm the submission. The portal keeps the attestation on file so both you and the requesting agency can reference it later.
If the portal is unavailable or the agency tells you to use email, follow the submission instructions printed on the form itself, which include the correct address and any subject-line convention. Either way, save the confirmation you receive. That receipt is your proof of compliance if a contracting officer asks for it during an audit or a renewal.
If You Cannot Check Every Box
A producer that does not yet meet every practice is not automatically disqualified. You can submit a Plan of Action and Milestones (POA&M) instead of a complete attestation. The POA&M identifies which practices you cannot attest to, describes the mitigating controls you have in place today, and sets a timeline for closing the gaps.
The requesting agency reviews the POA&M and decides whether the residual risk is acceptable. If it is, the agency can keep using your software while you work toward full compliance. If it is not, the agency has to stop using the product. With M-22-18 and M-23-16 rescinded, agencies have broader discretion over how they handle these situations than they did under the original rules, which had required them to seek an OMB deadline extension and forward the POA&M.
A POA&M buys time, but it signals risk. When an agency is weighing multiple vendors for the same need, one that can fully attest generally wins over one that is submitting a remediation plan.
SBOM and Other Artifacts
Some agencies ask for a Software Bill of Materials with the attestation. An SBOM is a machine-readable inventory of every component, library, and dependency in your package. Under M-26-05, each agency decides whether to require one and in what format. CISA publishes SBOM and hardware bill of materials templates, but agencies are not required to use them.
Even where an SBOM is not required, having one ready helps. Agencies often ask for it during supply-chain review, and producing one from scratch under deadline is difficult. Most organizations generate the SBOM automatically as part of their CI/CD pipeline, which also supports the attestation item about maintaining provenance data for components.
When You Need to Attest Again
A single attestation does not sit on the shelf indefinitely. Under the original framework, a new form was required at contract renewal and whenever the software went through a major version change. M-26-05 leaves renewal timing to individual agencies, but the same logic tends to apply. If the product you are delivering now looks materially different from the one you attested to before, expect a request for an update.
Routine patches and minor fixes do not usually trigger a new submission. A move from 3.2 to 3.3 is unlikely to prompt one; a move from 3.x to 4.0 almost certainly will. SaaS products with continuous delivery sit in a gray area. If your architecture or security posture shifts materially between contract periods, telling the agency and offering an updated attestation builds credibility.
If you discover after the fact that your organization no longer meets a practice you previously attested to (a build-environment compromise, for example, or a lapse in vulnerability response), notify the contracting agency promptly. Self-reporting almost always produces a better outcome than letting the agency find the gap on its own.
Legal Consequences of a False Attestation
The signed form is a representation to the federal government. Signing it when you know the statements are inaccurate exposes your company to liability under the False Claims Act. Under 31 U.S.C. ยง 3729, anyone who knowingly presents a false claim to the government faces a civil penalty per violation (a base range set by statute and adjusted for inflation) plus damages equal to three times the amount the government lost.1Office of the Law Revision Counsel. 31 USC 3729 – False Claims
A false attestation also puts your federal business at risk through suspension or debarment. Under FAR Subpart 9.4, debarment is a discretionary action agencies use to protect the government’s interest, and a debarred company cannot bid on or receive federal contracts for the length of the debarment, which can run for years.2Acquisition.GOV. Subpart 9.4 – Debarment, Suspension, and Ineligibility Being listed in the government-wide exclusion database can end a company’s federal work for good.
The rule of thumb is simple. If you cannot truthfully check a box, use the POA&M process. The legal exposure of attesting falsely is much larger than the inconvenience of disclosing a gap.