Executive Order 14028, signed in May 2021, set in motion a sequence of OMB memoranda (M-22-18 in September 2022, M-23-16 in June 2023) requiring federal agencies to obtain self-attestation from software producers that the software the agency uses was developed in conformity with NIST's Secure Software Development Framework (SSDF, NIST SP 800-218). CISA published the Secure Software Development Attestation Form (commonly called the CISA Form, OMB Control Number 1670-0052) in final form in March 2024, after a notice-and-comment process that began in April 2023 and produced several substantive revisions. By the second half of 2024, the form was being collected by federal agencies for software that fell within scope, and the producer ecosystem has been adjusting to it ever since.
The form is short — three pages of substantive content — but the obligations behind each attestation are substantial. A producer that signs the form is attesting to four categories of practice (secure development environments, provenance and integrity of third-party components, vulnerability disclosure programs, and trustworthy source-code maintenance), and the attestation has to be made by the CEO or a designated authorized individual with sufficient authority. The signature exposes the company to False Claims Act liability if the attestation turns out to be materially inaccurate, which has concentrated minds in producer legal departments and forced a closer working relationship between security engineering and the people who actually sign federal compliance documents.
What does the form actually attest to?
The CISA Form draws its substantive content from a subset of NIST SP 800-218 practices, narrowed and rephrased into yes/no attestation language. The first attestation block covers the software development environment: that the producer maintains the development environment with documented hardening (separation of environments, MFA, logging, secret management, network protection), that the producer regularly reviews and audits trust relationships, that the producer enforces multi-factor authentication and conditional access for users with administrative privileges, that the producer encrypts sensitive data, and that the producer continuously monitors operations and alerts for cybersecurity events.
The second block covers third-party component management: that the producer makes a good-faith effort to maintain trusted source-code supply chains by employing automated tools or comparable processes to address security vulnerabilities in the software, and that the producer maintains provenance data for internal code and third-party components incorporated into the software. The "provenance data" language is doing real work here — it implicitly requires an SBOM or equivalent inventory, though the form does not use the word SBOM, and it implicitly requires the producer to track the actual origin of the components it ships rather than just listing them.
The third and fourth blocks cover vulnerability disclosure and code maintenance: that the producer employs automated tools to check for security vulnerabilities and operates a vulnerability disclosure program, and that the producer maintains a process to identify, document, and address security vulnerabilities prior to product release. Each of those requirements maps onto a small cluster of SSDF practices, and CISA's published guidance includes a crosswalk between the form items and the underlying NIST practices.
Who has to attest, and when?
The OMB-driven scope is software developed or substantially modified for federal civilian executive branch use. "Software" in this context includes firmware, operating systems, applications, and application services, and "substantially modified" turns on whether the producer has made material changes to the software for the agency. Agencies were directed to start collecting attestations for critical software in 2024 and for all other in-scope software by deadlines that have slid somewhat as agencies have worked through implementation.
Free and open-source software is excluded from the form's scope (because there is no producer to sign), and software developed by the federal agency itself is excluded (there is no third party to attest). Cloud-based services and SaaS offerings are in scope, although CISA published an updated implementation guide in mid-2024 clarifying that SaaS offerings under existing FedRAMP authorization can leverage the FedRAMP package as supporting evidence and submit a single attestation covering the SaaS offering as a whole.
Producers who cannot attest fully to all four blocks have an alternative path: submit a Plan of Action and Milestones (POA&M) describing how they will reach conformity and on what timeline, accompanied by a third-party assessment by an FedRAMP-approved 3PAO or an equivalent independent assessor. The 3PAO alternative has been used more than CISA initially expected, partly because the third-party assessment provides a defensible record and partly because some producers prefer not to expose individual signatories to FCA risk on attestations that depend on operational practices the signatories cannot directly observe.
What are the recurring gotchas?
The most common gotcha across the 2024-2026 rollout has been the "good-faith effort" qualifier in the third-party component block. Producers initially read this as a soft commitment — make a reasonable effort and you are fine — but CISA's implementation guidance and agency feedback have tightened the expectation considerably. A producer that does not maintain a current SBOM, does not have a documented process for evaluating third-party component vulnerabilities, and cannot produce evidence of remediation timelines is unlikely to meet even the good-faith bar. The bar is not strict liability for every vulnerability, but it does require evidence that the program exists and operates.
The provenance data requirement has been a second gotcha. Producers maintaining build pipelines that consume from public registries without verifying signatures, without pinning versions, or without recording build attestations have struggled to attest to provenance with a straight face. The SLSA framework has emerged as the leading reference for what provenance evidence should look like at scale, and producers operating at SLSA Build Level 2 or higher have an easier time articulating their provenance posture to skeptical agency assessors. Software-supply-chain artifacts under in-toto and Sigstore are increasingly cited in producer responses as the underlying evidence base.
The vulnerability disclosure program block has been a smaller gotcha but a real one for producers who maintained ad-hoc disclosure processes rather than published VDPs. ISO 29147 and ISO 30111 alignment is now de facto expected, and producers without an externally facing security.txt and a documented triage process have been pressed to remedy that gap before attesting.
A subtler gotcha has been around the "substantially modified" scoping question. A producer shipping a commercial off-the-shelf product to a federal agency without customization has historically argued that the product is outside the attestation scope. CISA's mid-2024 guidance pushed back on that reading where the agency uses the product in a way that depends on producer-supplied updates and patches — at that point the ongoing producer-agency relationship implicates the attestation regime, and producers have had to revisit their scoping assumptions.
How is the program evolving in 2026?
The form has gone through a renewal cycle with OMB and CISA has signaled that future versions will incorporate lessons from the first two years of operation. Expected refinements include clearer language on SaaS scoping, explicit reference to SBOM as the canonical provenance artifact, and more specific guidance on what "automated tools" satisfy the vulnerability scanning requirement. The renewal has not (and is unlikely to) lower the substantive bar — if anything, agency assessors are getting more comfortable challenging weak attestations.
The interaction with the proposed FAR contractor SBOM rule, with the CMMC final rule, and with FedRAMP continuous monitoring is becoming clearer. Producers selling to federal customers in 2026 should expect that the same engineering posture (continuous SBOMs, KEV-aligned vulnerability management, signed build provenance, published VDP) serves all of these regimes simultaneously, and should not maintain separate compliance datasets for each. The trend across the federal-facing producer ecosystem is consolidation onto a single evidence base, with each regime drawing the artifacts it needs from that base.
The FCA risk has not produced a wave of enforcement actions yet, but the DOJ Civil Cyber-Fraud Initiative announced in October 2021 continues to be active, and the precedent set by United States ex rel. Markus v. Aerojet Rocketdyne (settled February 2022) — establishing that NIST SP 800-171 attestation misrepresentations can ground FCA liability — applies in pattern to SSDF self-attestation. Producers signing the CISA Form should treat the attestation as something a relator might one day examine in detail.
How Safeguard Helps
Safeguard generates the production evidence base the CISA Form implicitly demands. Continuous SBOMs across your build pipeline serve as the provenance record the third-party component block requires, signed build attestations under SLSA satisfy the integrity expectations CISA's guidance points to, and KEV-aligned vulnerability tracking generates the timeline evidence that the vulnerability management block depends on. Griffin AI maps your engineering practices onto the four attestation blocks, drafts the language your signatory needs to sign comfortably, and flags the specific gaps that have grounded FCA risk in adjacent contexts. Policy gates in Safeguard enforce the development-environment expectations the first block names (MFA-protected administrative access, secret management, build isolation) at the workflow level, producing the operational evidence agency assessors increasingly look for. TPRM workflows collect attestations from your own suppliers, so your CISA Form attestation rests on a defensible upstream record rather than on a leap of faith.