US Federal Cybersecurity Executive Orders Guide: EO 14028, 14144 and 2025 Amendments

US federal cybersecurity requirements for software, logging and cryptography flow from executive orders and OMB memoranda that have been amended, struck and rescinded several times since 2021, so many compliance programmes are still working to instructions that no longer apply. This guide traces what Executive Order 14028 (2021), Executive Order 14144 (January 2025), Executive Order 14306 (June 2025) and Executive Order 14412 (June 2026) actually require today, and which OMB memoranda now carry the detail. It is written for federal security teams, software and cloud suppliers to federal agencies, and GRC leads who need a single current view. AI-specific executive orders are out of scope. Status checked on 27 October 2026 against the Federal Register, the White House and OMB; executive orders and memoranda change often, so recheck the primary text before relying on any deadline.

Key takeaways

• EO 14028 still stands as the base order. Signed on 12 May 2021 (86 FR 26633), it set the programme for threat sharing, zero trust, software supply chain security, the incident response playbook, EDR and logging; later orders amended the follow-on orders rather than revoking it.
• EO 14306 removed the hard edges of EO 14144. The June 2025 order struck the software attestation validation regime, the digital identity section and most BGP and email detail, while keeping and re-dating the SSDF update, post-quantum and TLS 1.3 work.
• Secure software attestation is no longer mandatory government-wide. OMB M-26-05 (23 January 2026) rescinded M-22-18 and M-23-16; agencies may still use the CISA attestation form, but each agency now sets risk-based software and hardware assurance.
• Logging moved from M-21-31 to M-26-14. The May 2026 memo rescinded M-21-31 and sets minimums of six months searchable and one year retrievable, plus a staged maturity timeline tied to a CISA Logging Reference Architecture.
• Post-quantum migration now has its own order. EO 14412 (22 June 2026) and OMB M-26-15 set PQC key establishment for high value assets and high impact systems by 31 December 2030 and PQC signatures by 31 December 2031.

Scope: who and what is covered

Executive orders bind executive branch agencies, not private companies directly. Suppliers feel them through procurement: Federal Acquisition Regulation (FAR) clauses, agency contract terms, FedRAMP authorisation and the evidence agencies ask for before software is allowed on their networks. That is why a software vendor with no federal contract today still meets these requirements through a federal customer tomorrow.

EO 13694 (the 2015 sanctions order for malicious cyber activity) is also touched: EO 14306 changed "any person" to "any foreign person" in subsections 1(a)(ii) and 1(a)(iii), narrowing sanctions designations to foreign persons.

Key obligations

EO 14028: the 2021 baseline

• Section 2, threat information sharing: OMB was to review FAR contract language so IT and OT service providers report incidents to agencies, with the most severe incidents reported within three days of initial detection. The FAR rulemaking that implements this is a separate process: check the current FAR before quoting a reporting clock to a supplier.
• Section 3, modernising federal cybersecurity: zero trust architecture plans, cloud security strategy, FedRAMP modernisation, and multi-factor authentication plus encryption at rest and in transit within 180 days. See the NIST SP 800-207 Zero Trust Architecture Guide.
• Section 4, software supply chain: NIST guidance on secure software development, the definition of "critical software", minimum SBOM elements, and consumer IoT and software labelling criteria. This is where the SSDF (NIST SP 800-218) became the federal reference. See the NIST Secure Software Development Framework (SSDF, SP 800-218) Guide.
• Section 5, Cyber Safety Review Board: a DHS board convened after significant incidents.
• Section 6, standard playbook: CISA's incident response playbook for agencies, updated annually.
• Section 7, detection: endpoint detection and response across FCEB agencies, with CISA threat-hunting access.
• Section 8, logging: OMB logging and retention policy, which became M-21-31 and has now been replaced by M-26-14.

EO 14144 as amended by EO 14306: what remains

OMB memoranda that carry the detail now

• M-26-05, software and hardware assurance: agencies must keep a complete inventory of software and hardware, set assurance policies matching their own risk determinations, and validate provider security against secure development principles. The memo states there is "no universal, one-size-fits-all method". Agencies may still use the CISA Secure Software Development Attestation Form and may contract for a current SBOM on request; for cloud platforms the SBOM should cover the runtime production environment. No compliance deadlines are set. See the CISA Secure by Design Pledge and Secure Software Attestation Form Guide.
• M-26-14, logging: two objectives, Continuous Event Monitoring (CEM) and Threat Hunting, Investigation, Response and Forensics (THIRF). Logs need accurate timestamps from a traceable time source, must be available to the top-level agency SOC, and must cover identity, network and session data, object access and changes, privilege changes, infrastructure changes, security tool alerts and indicators of compromise. Minimum retention is six months actively searchable and one year retrievable. Logs go to CISA and the FBI on request during a known or suspected compromise.
• M-26-15, post-quantum migration: a PQC migration plan to OMB and ONCD within 120 days, automated and continuously updated cryptographic inventory (ideally feeding a Cryptographic Bill of Materials), TLS 1.3 support no later than 2 January 2030, PQC requirements in procurement using CISA's product categories, and PQC responsibilities agreed with FedRAMP-authorised cloud providers.

EO 14412: post-quantum cryptography

• 30 days: each agency names a PQC migration lead.
• 90 days: OMB guidance requiring agencies to review high value asset and high impact system inventories and move them to PQC key establishment by 31 December 2030 and PQC digital signatures by 31 December 2031.
• 180 days: NIST migration pilot (to finish by 31 December 2027), NSA report on National Security Systems, faster Cryptographic Module Validation Program, and a proposed FAR rule requiring covered contractors to comply with NIST FIPS, including PQC algorithms, by 31 December 2030.
• 270 days: CISA and NIST minimum elements for a cryptographic bill of materials, and a proposed FAR rule on contractor vulnerability disclosure programmes that covers cryptographic vulnerabilities.

See the Post-Quantum Cryptography Migration Guide and the Cryptographic Inventory and CBOM Guide.

Timeline and current status

FedRAMP is a statute-backed programme, not an executive order: the FedRAMP Authorization Act of December 2022 established it in law, OMB M-24-15 (July 2024) is the current policy, and the 20x pilots issued their first Moderate authorisations on 6 March 2026. FedRAMP states that it stops accepting new Rev5 certifications on 11 June 2027. See the FedRAMP Guide.

Enforcement and penalties

Executive orders state that they create no enforceable rights and are implemented subject to law and appropriations. There is no fine schedule in any of these orders. Enforcement runs through other channels:

• Contract terms: once a FAR clause or agency clause is in a contract, failure to meet it is a contract performance issue, with remedies under that contract.
• Market access: an agency head is now personally responsible under M-26-05 for "assuring the security of software and hardware that is permitted to operate on the agency's network". In practice that means an agency can decline software it cannot assure.
• False statements: attestations and security representations made to the government carry the general legal risk of any statement to a federal agency. The EO 14144 provision encouraging referral of failed attestations to the Attorney General was struck by EO 14306, but that does not remove other legal exposure. Take legal advice on this point.
• Sanctions: EO 13694 as amended allows sanctions on foreign persons responsible for significant malicious cyber activity.

What it means for AI agents and non-human identities

The orders rarely say "machine identity", but almost every remaining requirement lands on non-human identities.

• Logging scope includes machines: M-26-14 requires identity and privilege change logging. Service accounts, workload identities and API tokens generate most of that activity, so the log plan must attribute actions to a specific non-human identity, not to a shared account. See the Non-Human Identity (NHI) Guide.
• PQC migration is a certificate and key problem: TLS 1.3 and PQC key establishment change every mTLS certificate, workload identity token signing key and code signing key. The cryptographic inventory that M-26-15 asks for is mostly an inventory of machine credentials. See the Post-Quantum Migration for NHIs Guide.
• Software assurance covers build identities: SSDF practices on protecting the build environment translate into controls on CI/CD service accounts, signing keys and pipeline tokens.
• AI vulnerability management: the EO 14306 task to bring AI software vulnerabilities and compromise indicators into existing vulnerability processes means AI agents and their credentials belong in the same asset and vulnerability inventories as other software.

Compliance steps

1. Rebuild the requirements register. Remove references to M-22-18, M-23-16 and M-21-31 as active mandates; add M-26-05, M-26-14, M-26-15 and EO 14412. Keep EO 14028 and EO 14144 as amended.
2. Suppliers: keep SSDF evidence ready. Attestation is now agency-specific, so expect varied requests. Maintain an SSDF practice mapping, the CISA form completed and signed, and SBOMs per release that you can produce on request.
3. Agencies: write the assurance policy. Define risk tiers for software and hardware, the evidence each tier needs (attestation, SBOM, third-party assessment, HBOM), and who signs off.
4. Prepare the logging plan. Map log sources to the M-26-14 categories, confirm time synchronisation, and check six-month searchable and one-year retrievable retention. Plan the Basic, Intermediate and Advanced milestones from the CISA Logging Reference Architecture release date.
5. Start the cryptographic inventory now. Prioritise high value assets and high impact systems, record algorithms, key sizes, certificate owners and protocol versions, and flag anything not on TLS 1.3.
6. Contractors: plan for FIPS and PQC clauses. The proposed FAR rule under EO 14412 targets FIPS compliance including PQC by 31 December 2030; product roadmaps need hybrid or PQC key establishment before then.
7. Track the open items. The final SSDF revision, the CISA Logging Reference Architecture, the FAR rules on PQC and vulnerability disclosure, and the Cyber Trust Mark FAR change will each alter detail.

Framework mapping

Common failure patterns

• Quoting rescinded memos: contract templates and policies still cite M-21-31 or M-22-18 as mandatory. Both are rescinded.
• Assuming attestation is gone so evidence is not needed: agencies can still require the CISA form, SBOMs and more under their own policies, and many will.
• Logging humans only: logging plans that attribute actions to people but leave automation behind shared service accounts cannot meet identity and privilege change coverage.
• Treating PQC as a 2030 problem: migration plans were due in October 2026 and the inventory phase runs 2026 to 2027.
• Reading the original EO 14144: many summaries describe the January 2025 text. Always read it as amended by EO 14306.

Practitioner checklist

• Update the requirements register to the October 2026 set of orders and memoranda.
• Keep a current SSDF mapping, CISA attestation form and release SBOMs ready for agency requests.
• Agencies: publish a risk-based software and hardware assurance policy under M-26-05.
• Map log sources to M-26-14 categories and confirm 6-month searchable and 1-year retrievable retention.
• Attribute every logged action to a named human or non-human identity.
• Build an automated cryptographic inventory covering certificates, keys and TLS versions.
• Plan TLS 1.3 support before 2 January 2030 and PQC key establishment for HVAs by 31 December 2030.
• Watch for the final SSDF revision, the CISA Logging Reference Architecture and the EO 14412 FAR rules.

Standards and references

• Federal Register: Executive Order 14028, Improving the Nation's Cybersecurity
• Federal Register: Executive Order 14144, Strengthening and Promoting Innovation in the Nation's Cybersecurity
• The White House: Executive Order 14306, Sustaining Select Efforts to Strengthen the Nation's Cybersecurity
• The White House: Executive Order 14412, Securing the Nation Against Advanced Cryptographic Attacks
• OMB: M-26-05, Adopting a Risk-based Approach to Software and Hardware Security
• OMB: M-26-14, Agency Logging and Network Visibility
• OMB: M-26-15, Execution of the Migration to Post-Quantum Cryptography
• CISA: Secure Software Development Attestation Form

Related NHI Mgmt Group resources: NIST Secure Software Development Framework (SSDF, SP 800-218) Guide · OMB M-21-31 Logging Maturity Guide · FedRAMP Guide · Post-Quantum Cryptography Migration Guide. This guide summarises US federal cybersecurity executive orders and OMB memoranda as of 27 October 2026 and is not legal advice.