On Friday, June 6, President Trump issued an executive order (EO) on national cybersecurity. The order amended and struck several provisions in Executive Orders 13694 and 14144, which were respectively issued by President Obama in 2015 and by President Biden in early 2025. The biggest changes were in the areas of software security, post-quantum cryptography, digital identity, fraud management, and AI. In some cases, Trump’s EO dropped technology specifics for certain guidelines.

Back in January, Forrester detailed the key topics and technology areas in EO 14144. The Trump administration’s new EO does not revoke EO 14144 entirely, but there are changes to several provisions. Here’s what security leaders need to know.

Software Supply Chain Guidance Moves Away From Machine Attestation

The latest EO strikes sections 2(a) and 2(b) listed in EO 14144, whose purpose was to operationalize transparency and security in third-party software applications. These sections recommend federal acquisition contractual language to require that software providers provide: “(A) machine-readable secure software development attestations; (B) high-level artifacts to validate those attestations; and (C) a list of the providers’ Federal Civilian Executive Branch (FCEB) agency software customers.” The sections also mandated a process for CISA to validate the attestations and artifacts and recommend companies with failed attestations to the DOJ. It’s worth noting, however, that:

  • The new EO does not remove all software supply chain requirements. The new EO does not specifically repeal EO 14028 or the OMB M-23-16 update to M-22-18, “Enhancing the Security of the Software Supply Chain through Secure Software Development Practices.” Therefore, federal agencies are presumably still on the hook to obtain a self-attestation from software suppliers and, at their discretion, require evidence in the form of an SBOM artifact. Clarification on this point from CISA, GSA, or OMB is anticipated and necessary.
  • Secure software development framework (SSDF) updates are coming. The new EO retains and sets deadlines for NIST to establish an industry consortium that will provide guidance on how software providers can demonstrate the implementation of the SSDF. A preliminary update to the SSDF with practices, procedures, controls, and implementation examples regarding the secure and reliable development and delivery of software, as well as the security of the software itself, is preserved, with a due date of December 1, 2025, set. In addition, NIST will update Special Publication 800–53 to add “how to securely and reliably deploy patches and updates.”

Post-Quantum Cryptography (PQC) Migration Remains A Priority, Though Some Changes Could Slow Collaboration And Adoption

While the new EO strikes subsection 4(f) from EO 14144, its amended replacement continues to recognize the threat posed by a cryptanalytically relevant quantum computer (CRQC) and upholds the transition to PQC. The amendment also introduces a fixed date of December 1, 2025, for 1) the release of a regularly updated CISA list of product categories that support PQC and 2) NSA (for NSS) and OMB (for non-NSS) to issue requirements for agencies to support TLS 1.3 or a successor version no later than January 2, 2030. Two other notable changes raise some issues, however:

  • PQC support requirements are no longer mandated in product solicitations. The new EO removes certain requirements, including PQC support in product solicitations and adopting PQC or hybrid KEM as soon as practicable. From a procurement and implementation perspective, removing these sections leaves much to the discretion of individual agencies and their risk appetite. This could introduce delays in governmentwide migration to PQC.
  • International collaboration language has been removed. The amendment notably removes the section calling for engaging with foreign governments and industry groups in key countries to encourage transition to NIST’s standardized PQC algorithms. NIST has been a leader in developing new PQC standards, and strong international collaboration has helped to accelerate that work and led many countries to adopt the NIST standards for themselves. If standardized PQC algorithms are found vulnerable or broken in the future (due to CRQC or just because of discovered flaws in the algorithm), new standards will take time to develop, and less international collaboration could slow new standard development and make interoperability more difficult.

Other Changes Address Protocols And Emerging Technologies

The new EO removes a lot of technology-specific language, which may allow for more flexibility in implementation. For example, EO 14144 originally mandated that the federal government “adopt proven security practices from industry” in the IAM realm and pilot deploying the WebAuthn standard. The new EO removes those sections. The new EO also removes the original references to BGP and its potential vulnerabilities in the internet routing section. But these technology specifics could reappear in some of the published department-level guidance that the EO requires. In addition to those examples, be aware that:

  • Fraud and digital identity provisions have been removed. The new EO completely removes Section 5 of EO 14144, titled “Solutions to Combat Cybercrime and Fraud.” Section 5’s removal marks intent to reduce mandates of specific security technologies that federal agencies should use when it comes to managing fraud and digital identities. The new EO also removes initiatives to use digital ID document verification for citizens when using services of the US federal government.
  • Space system cybersecurity is still in orbit, but trajectory is less clear. While the latest EO preserves most cybersecurity requirements for space systems, it notably scales back mandates for space national security systems (NSSes). These systems remain critical to national infrastructure and security, yet the EO no longer requires the Committee on National Security Systems to identify specific requirements for intrusion detection, secure booting via hardware roots of trust, and patch management. Instead, it tasks the committee to identify requirements for cyber defenses broadly. Space cybersecurity is an evolving domain where defense and civilian operators alike are actively seeking government-backed standards to make it easier to cost-effectively maintain space assets. Removing this language may offer more leeway to address broader requirements, but space NSS operators and government agencies will still need to account for the removed components in their existing procurement- and system-lifecycle requirements.
  • AI provisions include a stronger focus on AI software vulnerabilities. This executive order removes many of the provisions related to using AI in the defense of critical infrastructure, including a pilot program on using AI to protect the energy sector. In addition, it recommends that NIST ensure that AI-related software vulnerabilities and compromises are included in agency and interagency vulnerability management processes by November 1, 2025. The same date is also used as a deadline for sharing relevant cyber data with academic institutions for research purposes.

This is the first major instance of changes to previous executive orders and guidelines in the cybersecurity arena. With the new EO requiring published guidance in several areas before the end of the year, security leaders not only in US federal agencies but also those in adjacent and trickle-down organizations will need to stay on top of the latest updates and prepare for more changes. To talk more about the impacts to your organization, schedule a guidance session with any of our authors.