EO 14028 and CISA Secure Software Attestation: What Software Producers Need to Know

Secure software attestation is a requirement, rooted in Executive Order 14028, that producers of software used by the U.S. federal government formally attest that they follow secure development practices from the NIST Secure Software Development Framework (SSDF). Software producers self-certify using CISA’s Secure Software Development Attestation Form. Strong code-signing and cryptographic-inventory evidence helps back up those attestations.

Secure software attestation is the U.S. government’s way of making sure the software it buys was built securely. Stemming from Executive Order 14028, it requires software producers selling to federal agencies to formally attest that they follow secure development practices based on the NIST Secure Software Development Framework (SSDF), using a standard CISA form. Good code-signing and inventory practices provide the evidence behind the attestation.

Key Takeaways

• Executive Order 14028 (May 2021) launched federal software supply chain security requirements, including secure software attestations.
• Software producers selling to the U.S. government must self-attest that they follow secure development practices from the NIST SSDF (NIST SP 800-218), using CISA’s Secure Software Development Attestation Form.
• The form is signed by a CEO or an authorized company designee; a FedRAMP third-party assessor (3PAO) is an alternative to self-attestation.
• The policy has shifted: a June 2025 executive order rolled back the enhanced artifact and validation requirements added in early 2025, reverting to the core self-attestation regime. The exact requirements continue to evolve.
• Strong code-signing (secure keys, signed builds, provenance) and cryptographic and component inventory are practical evidence that supports these attestations.

What Is Secure Software Attestation?

Secure software attestation is a formal statement, made by a software producer, that its software was developed following recognized secure development practices. The goal is to protect the software supply chain: after high-profile supply chain attacks, the U.S. government moved to require that any software it uses be built in a secure environment, with controls that reduce the risk of tampering or hidden vulnerabilities. Rather than inspecting every vendor’s process directly, the government requires vendors to attest, on the record and with executive accountability, that they meet a defined baseline of secure practices.

Executive Order 14028: Where It Started

In May 2021, Executive Order 14028, Improving the Nation’s Cybersecurity, set in motion a broad set of federal cybersecurity initiatives, including a focus on software supply chain security. It directed the National Institute of Standards and Technology (NIST) to develop secure software development guidance, which became the Secure Software Development Framework (SSDF), NIST SP 800-218. It also set the stage for requiring software producers to attest that they follow those practices. The Office of Management and Budget (OMB) then issued memoranda (M-22-18 and M-23-16) directing federal agencies to collect these self-attestations from their software vendors.

The CISA Secure Software Development Attestation Form

To standardize how vendors attest, CISA (with OMB) created the Secure Software Development Attestation Form, sometimes called the Common Form. Its final version was published in March 2024, along with a repository for submissions. Key points about the form:

• What it covers: The producer attests that its software is developed in line with specific secure practices drawn from the NIST SSDF, covering the development environment, protecting code integrity, and disclosing known vulnerabilities.
• Who signs: The form must be signed by the software producer’s CEO or an authorized designee who can bind the company, putting accountability at the executive level.
• Self-attestation or third party: A producer can either self-attest, or engage a certified FedRAMP third-party assessor organization (3PAO) to confirm conformance with the SSDF.
• What software is covered: It applies to software used by federal agencies, including newly developed software, major version updates, and software delivered via continuous updates (such as SaaS).

The Secure Software Development Framework (SSDF)

The SSDF (NIST SP 800-218) is the substance behind the attestation. It is a set of secure software development practices grouped into four areas. In plain terms:

SSDF group	What it means
Prepare the Organization	Make sure people, processes, and technology are ready to develop software securely.
Protect the Software	Protect all components of the software from tampering and unauthorized access, including safeguarding code integrity and signing.
Produce Well-Secured Software	Design, build, and test software to minimize vulnerabilities before release.
Respond to Vulnerabilities	Identify, disclose, and remediate vulnerabilities on an ongoing basis.

Important: This Policy Is Evolving

Secure software attestation has been a moving target. Executive Order 14028 (2021) and the OMB memoranda remain in effect, and the CISA self-attestation form is still in use. In January 2025, a further executive order (EO 14144) sought to strengthen the regime, adding machine-readable attestations, supporting artifacts, and validation by CISA. In June 2025, a subsequent executive order removed those enhancements, reverting to the core self-attestation approach without the mandatory artifact and validation layer. Meanwhile, a Federal Acquisition Regulation (FAR) rule to formalize the requirement has been in progress, and NIST has been directed to update the SSDF.

The practical takeaway: the requirement to attest to secure development is alive and expected to continue, but the specific mechanics (artifacts, validation, FAR language) are still settling. Software producers should build the underlying secure practices regardless, since those are what every version of the policy is built on. Always confirm the current requirements with official CISA, OMB, and FAR sources before relying on any specific detail.

How Code Signing and Cryptographic Inventory Support Attestation

A crucial point often missed: an attestation is a claim, and claims are stronger when you can back them with evidence. Several SSDF practices, especially those under ‘Protect the Software’, map directly to code signing and cryptographic and component inventory. Being able to demonstrate these makes attestation defensible rather than aspirational:

• Code integrity and provenance: The SSDF calls for protecting the integrity of code and verifying software has not been tampered with. Signing your builds and releases, with keys protected in an HSM, provides cryptographic proof of integrity and origin, and trusted timestamping keeps those signatures valid over time.
• Protecting the signing process: Secure development requires that signing keys are protected and signing happens in a controlled, auditable environment, not on developer laptops. Centralized, policy-governed signing produces the audit trails that evidence this.
• Knowing your components: The SSDF and related guidance emphasize knowing what is in your software. A software bill of materials (SBOM) and a cryptographic bill of materials (CBOM) inventory your components and the cryptography you use, supporting vulnerability disclosure and (increasingly) quantum-readiness expectations.
• Ongoing evidence: Attestation is not one-and-done. Continuous signing, inventory, and monitoring produce the ongoing evidence that supports your attestation as software changes.

How Encryption Consulting Helps

Encryption Consulting helps software producers turn secure-development requirements into demonstrable practice. CodeSign Secure secures your signing keys in an HSM, centralizes and automates code signing across build pipelines with policy enforcement and full audit trails, and applies trusted timestamping, directly supporting the SSDF’s code-integrity practices behind an attestation. CBOM Secure provides cryptographic discovery and inventory, giving you visibility into the cryptography and components across your software, which supports vulnerability management, supply chain transparency, and post-quantum readiness. Together they give you the evidence base to attest with confidence. Backed by ISO/IEC 27001:2022 and SOC 2 certified practices.

Frequently Asked Questions

What is EO 14028?

Executive Order 14028, ‘Improving the Nation’s Cybersecurity,’ was issued in May 2021. It set in motion a broad set of U.S. federal cybersecurity initiatives, including a major focus on software supply chain security. Among other things, it directed NIST to create secure software development guidance, which became the Secure Software Development Framework (SSDF, NIST SP 800-218), and set the stage for requiring producers of software used by the federal government to attest that they follow secure development practices. It remains the foundation of federal secure software attestation requirements.

What is the CISA secure software development attestation form?

It is a standardized form, sometimes called the Common Form, that producers of software used by U.S. federal agencies use to attest that they follow secure development practices from the NIST SSDF. CISA published the final version in March 2024, together with a repository for submissions. The form must be signed by the producer’s CEO or an authorized designee, placing accountability at the executive level. As an alternative to self-attestation, a producer can use a certified FedRAMP third-party assessor (3PAO) to confirm SSDF conformance.

Who has to comply with secure software attestation?

The requirement applies to producers of software used by U.S. federal agencies. It covers newly developed software, major version updates to existing software, and software delivered through continuous updates such as software-as-a-service. If a company sells software to the federal government, or plans to, the attestation is effectively a condition of doing business, since agencies must obtain it to use the software. Even organizations not selling to the government often adopt the same practices, because they reflect broadly recognized software supply chain security expectations.

Is secure software attestation still required in 2026?

The core requirement to attest to secure development, rooted in EO 14028 and the OMB memoranda, remains in place, and the CISA form is still used. However, the specifics have shifted: a January 2025 executive order added enhanced requirements (machine-readable attestations, artifacts, and CISA validation), and a June 2025 executive order removed those enhancements, reverting to the core self-attestation approach. A formal FAR rule is still pending. Because the mechanics continue to evolve, always confirm current requirements with official CISA, OMB, and FAR sources.

What is the SSDF?

The Secure Software Development Framework (SSDF), published by NIST as SP 800-218, is a set of recommended secure software development practices. It is organized into four groups: prepare the organization, protect the software, produce well-secured software, and respond to vulnerabilities. The SSDF is the substance behind the federal attestation requirement, when a producer attests, it is attesting to following practices derived from the SSDF. NIST periodically updates the framework, so producers should track the current version.

How does code signing help with secure software attestation?

Code signing provides concrete evidence for several SSDF practices, particularly those about protecting software integrity. Signing builds and releases with keys secured in an HSM gives cryptographic proof that software is authentic and unaltered, and trusted timestamping keeps those signatures valid over time. Centralized, policy-governed signing with audit trails also demonstrates that signing happens in a controlled environment rather than on individual developer machines. Combined with a software and cryptographic bill of materials, this turns an attestation from a bare claim into a defensible, evidence-backed one.

Build the Evidence Behind Your Attestation

Secure software attestation rests on practices you can prove. Explore Encryption Consulting’s CodeSign Secure and CBOM Secure to secure your signing, protect your keys, and inventory your cryptography and components, so you can attest to secure development with evidence to back it.