President Biden signed Executive Order 14144, "Strengthening and Promoting Innovation in the Nation's Cybersecurity," on January 16, 2025, four days before the change of administration. The order placed heavy emphasis on software supply chain risk management for the federal government, including machine-readable secure-development attestations submitted to CISA, validation artifacts, customer-of-record lists, and a mandate for CISA to audit a sample. On June 6, 2025, President Trump signed EO 14306, "Sustaining Select Efforts to Strengthen the Nation's Cybersecurity," which preserved some objectives, struck others, and recalibrated the federal supply chain posture. For software suppliers selling into the federal market in 2026, the practical question is not which order is in force — it is what those two orders, read together, expect them to do.
What did EO 14144 require?
The January 2025 order contained more than fifty distinct directives across federal IT, software supply chain, identity, AI, post-quantum cryptography, and operational technology. The supply-chain core was section 2, which directed OMB to require that federal software suppliers submit machine-readable attestations of secure-development practices aligned with NIST SP 800-218 and NIST SP 800-218A. Suppliers were further directed to provide "high-level validation artifacts" supporting those attestations and to submit a list of federal customers using the attested software. CISA was directed to verify completeness, regularly validate sample attestations, and refer false attestations to the Justice Department for potential False Claims Act enforcement. The order also addressed open-source software risk, requiring CISA and OMB to develop guidance and tooling for federal agencies that consume open source.
What did EO 14306 change?
The June 2025 order, EO 14306, amended both EO 13694 and EO 14144. On the supply chain side, EO 14306 removed the requirement that suppliers submit "high-level validation artifacts" supporting their secure-development self-attestations and removed the mandate that CISA actively audit a sample of attestations. The self-attestation requirement itself — that federal software suppliers attest, via the Common Form, to alignment with SSDF practices — remains in place under prior OMB Memorandum M-22-18 and its successors; EO 14306 did not eliminate that base obligation. EO 14306 also reframed several AI and post-quantum directives, tightened timelines for some workstreams, and removed others. The net effect: the self-attestation regime survives, but the auditing apparatus around it is lighter than EO 14144 envisioned.
What does this mean for software suppliers in 2026?
Five concrete implications. First, the OMB Common Form for SSDF self-attestation is still the operative federal mechanism; suppliers cannot deprioritize it on the basis that EO 14144 was amended. Second, CISA still expects suppliers to maintain evidence behind the attestation, even if no formal audit is mandated; agencies and primes are increasingly asking for that evidence in source-selection. Third, AI-specific obligations now flow through NIST SP 800-218A and the streamlined EO 14306 text, not through the original EO 14144 AI sections. Fourth, post-quantum cryptography migration timelines are now defined by EO 14306 and the related OMB memos rather than by EO 14144's stricter clock. Fifth, the cluster of supply chain expectations originally bundled in EO 14144 — provenance, build integrity, SBOMs, attestation — has not gone away; it has been distributed across NIST SSDF, NIST 800-218, NIST 800-218A, FedRAMP 20x, and CMMC 2.0 obligations that all overlap.
How does the SSDF self-attestation work today?
Suppliers submit the Common Form to each agency they sell to, attesting that the software was developed in alignment with specified SSDF practices, including secure development environments, build provenance, vulnerability identification and remediation, and trusted source for third-party components. The attestation must be signed by a CEO or designee. False statements expose the supplier to False Claims Act liability — a real risk even without an EO 14144 audit, because qui tam relators and OIG referrals do not require an executive-order trigger. Suppliers maintain a documented evidence base supporting each attested practice and are expected to refresh the attestation when the underlying software changes materially.
What about open source consumed by federal agencies?
EO 14144's open-source directives were largely preserved through EO 14306. CISA continues to develop guidance and tooling for federal agency consumers of open source, including risk-scoring resources and recommended patterns for governance. The OMB approach treats open-source software as in-scope of the same SSDF expectations as commercial software when it is used in federal mission systems, with the agency consuming the OSS responsible for the equivalent secure-development posture. In practice, that means agencies leaning on commercial distributors that provide curation, signing, and SBOM evidence for the OSS packages they ship.
# SSDF self-attestation evidence map (post EO 14306)
SSDF.PO.1 Define security requirements -> security policy, threat model
SSDF.PS.2 Implement provenance -> SLSA build attestation, signed images
SSDF.PS.3 Verify third-party components -> SBOM, allowlist, license review
SSDF.PW.4 Reuse vetted components -> dependency policy, KEV/CVE gate
SSDF.PW.7 Review software designs -> design review records
SSDF.PW.8 Test executable code -> SAST, DAST, SCA, IAST evidence
SSDF.RV.1 Identify and confirm vulns -> coordinated disclosure policy, PSIRT
SSDF.RV.3 Analyze root cause -> incident retrospectives, CVE records
AI overlay NIST 800-218A practices -> model risk artifacts, dataset hygiene
How does this stack with FedRAMP 20x and CMMC?
FedRAMP 20x's machine-readable OSCAL submissions and KSI-based continuous monitoring are designed to satisfy a significant slice of what EO 14144 originally envisioned, just through a different mechanism. CMMC 2.0 Level 2, mandatory for many CUI-handling DoD contracts starting November 10, 2026 in Phase 2, also incorporates SSDF-aligned practices in its NIST SP 800-171 control set. A federal software supplier that holds FedRAMP 20x authorization and CMMC Level 2 certification, and that maintains a current SSDF self-attestation backed by SBOM and provenance evidence, has effectively answered most of the supply chain expectations that emerged from EO 14144. The work for such suppliers in 2026 is harmonizing the evidence so they are not maintaining three parallel control inventories that drift out of alignment.
How Safeguard Helps
Safeguard produces and maintains SBOMs, build provenance, and SLSA-level attestations as machine-readable evidence aligned with NIST SSDF and SP 800-218A, so the self-attestation underlying the OMB Common Form is backed by real artifacts rather than narrative claims. Griffin AI ties every component in your SBOM to KEV entries, advisories, and reachability evidence, supporting the SSDF.RV practices without separate spreadsheets. TPRM workflows track each federal customer of record for an attested product and flag changes that would require attestation refresh. Policy gates can also enforce SSDF, FedRAMP 20x KSI, and CMMC control evidence at the same release boundary, so suppliers selling into the federal market can answer EO 14144 era expectations and EO 14306 era expectations from one consistent control plane.