Biden’s Final Cybersecurity Order Proposes Significant Changes, All to Be Implemented by the Incoming Administration

Citing the threats posed by foreign adversaries and criminal organizations, and seeking enhanced accountability for companies that provide software and cloud services to the federal government, the Biden administration has released a new, sweeping Executive Order ("E.O.") on cybersecurity. With mere days left in office, President Biden signed the "Executive Order on Strengthening and Promoting Innovation in the Nation's Cybersecurity" on January 16, 2025. The new E.O. is something of a bookend to Biden's 2021 cybersecurity order with a very similar name, E.O. 14028, with the new E.O. reflecting more ambitious goals and more onerous requirements for government contractors, software developers, and cloud service providers ("CSPs"). In a bit of good news for the technology industry, the E.O. encourages federal agencies to expand acceptance of digital identification, and to deploy commercial artificial intelligence ("AI"), end point detection, encryption, and other tools for use in cyber defense activities.

Below we highlight the major provisions of the E.O. of relevance to software producers and CSPs whose products and services are sold to federal agencies. Although the E.O. comes at the tail end of the current administration, there is strong evidence to suggest the incoming administration is not likely to reject the proposed changes wholesale.

Efforts To Strengthen Software Supply Chain Security

Software Attestation and Artifacts

Beginning in 2024, software developers have been required to complete a secure software development attestation form in order to sell (or have others resell) their software products to the federal government. The E.O. builds on this requirement, and suggests a number of additional requirements to ensure that software providers continue to adopt secure software acquisition and development practices, so as to reduce vulnerabilities and threats to government systems and information. The E.O. suggests that although software providers make commitments to security as part of their contracts and attestations, they "do not fix well-known exploitable vulnerabilities. . .which puts the Government at risk of compromise."

Among the proposed changes to ensure that software developers are following required practices is an expansion of secure software development attestation requirements, to add the obligation that software producers provide accompanying high-level validation artifacts along with their machine-readable attestations, and also a list of federal government customers. The list of customers is to include all civilian agencies that use the software product, but not Department of Defense ("DoD") or intelligence agency customers. All of this information is to be provided to the Cybersecurity and Infrastructure Security Agency ("CISA") via its centralized Repository for Software Attestation and Artifacts ("RSAA"). (We have previously noted that creation of such a centralized repository creates security challenges of its own as the repository would be an obvious target for bad actors and foreign adversaries.)

In addition, the E.O. recommends that CISA develop a review and audit process to verify the completeness and accuracy of all attestations submitted to the RSAA and that the agency regularly validate a sample of completed attestations. The National Cyber Director is to publicly post the validation results and encouraged to refer any attestations that fail validation to the Attorney General and contracting agencies for appropriate action. (This is yet another example of continued government efforts to use the threat of False Claims Act liability to hold software developers to account.)

These requirements are not self-executing. Rather, the Federal Acquisition Regulatory Council ("FAR Council") must first develop and adopt contract language implementing these changes. Interestingly, for the requirement for artifacts and lists of customers, the E.O. suggests rapid action on the part of the FAR Council (within 120 days) and issuance of an interim final rule to amend the FAR versus undergoing the full proposed rule notice and comment period. It remains to be seen whether the Trump administration views this and other proposed changes with the same level of urgency.

Other Secure Software Acquisition Practices

The E.O. directs CISA to update the common software development attestation form based on yet-to-be-provided guidance from the National Institute of Standards and Technology ("NIST") in select areas. For its part, NIST is asked to provide direction to software producers on deploying patches and updates securely and reliably, through a revision to NIST Special Publication 800-53, "Security and Privacy Controls for Information Systems and Organizations." NIST also is tasked with developing "practices, procedures, controls, and implementation examples" of secure and reliable development and delivery through an update to NIST Special Publication 800-218, "Secure Software Development Framework." In a tortured regulatory process, the Office of Management and Budget ("OMB") will incorporate select practices from the two revised NIST publications into a revised version of OMB Memorandum M-22-18, "Enhancing the Security of the Software Supply Chain through Secure Software Development Practices." CISA will conform the common software attestation form to the revised OMB Memorandum.

The E.O. also suggests means for agencies to integrate cybersecurity into the acquisition life cycle, by taking cybersecurity into account in acquisition planning, source selection, responsibility determinations, security compliance evaluations, contract administration, and evaluations of contractor performance. In other words, cybersecurity should become a significant consideration in all procurements and in assessing contractor past performance.

Other recommendations seek guidance from CISA and OMB to agencies on the use of security assessments and patching of open-source software, and best practices for contributing to open-source software projects.

Minimum Cybersecurity Practices for All Federal Contractors

Recognizing that managing cybersecurity risks is now a necessary part of everyday industry practice for all companies, regardless of the product or service they sell, the E.O. directs NIST to provide guidance on common industry cybersecurity practices and security controls within 240 days of the E.O. Based on the resulting NIST guidance, the FAR Council is tasked with amending the FAR to require: (i) that all contractors follow minimum cybersecurity practices, and (ii) that vendors of internet-of-things products (wireless interconnected smart products) sold to the federal government carry United States Cyber Trust Mark labeling. To date, such labeling has been entirely voluntary, so this reflects a new requirement for applicable contractors. The new recommended security practices are likely to go beyond the current 15 minimum security requirements found in FAR 52.204-21, "Basic Safeguarding of Covered Contractor Information Systems," which apply to nearly all government contractors and subcontractors.

New Obligations for Providers of FedRAMP-Authorized Products and Services

Recognizing that private industry may be best positioned to advise on measures to ensure the security of government information, and that such information is often in the hands of CSPs, the E.O. directs the head of the Federal Risk and Authorization Management Program ("FedRAMP"), which authorizes cloud products for use by the government, to develop policies and practices that incentivize or require FedRAMP CSPs "to produce baselines with specifications and recommendations for agency configuration of agency cloud-based systems." In addition, the E.O proposes that FedRAMP security requirements be updated to incorporate guidelines for the secure management of access tokens and cryptographic keys. Providers of FedRAMP-authorized solutions will need to address these new requirements to maintain their authorizations, and companies seeking authorization in the future will also need to take additional requirements into account in assessing the security postures of their products and services.

Opportunities for the Tech Industry

Several sections of the E.O. emphasize that the federal government must adopt proven commercial practices and products to fortify government networks. The government cannot do this without purchasing and implementing commercial solutions in areas of AI, endpoint detection and response, credentialing, phishing-resistance, threat hunting, muti-factor authentication, among others. In particular, the E.O. calls out needed improvements with respect to civil space systems and federal communications networks (including internet routing, email, voice, and video conferencing).

With respect to AI, the E.O. calls for the development of pilot programs to use advanced AI models for cyber defense and for the sharing of government data sets with the academic community to advance AI cyber defense research.

The E.O. encourages expanded use of digital identification documents, including mobile driver's licenses. It suggests that such documents be accepted as proof of identification for federal benefits programs, and proposes that agencies consider awarding grants to states to assist in the more rapid adoption of such technologies.

In sum, the E.O. as envisioned presents opportunities for future sales of commercial cybersecurity products and services to government agencies. Technology companies should think strategically about how they can best position their products to be the options of choice throughout the federal government.

Miscellaneous Provisions of Note

Section 8 of the E.O. focuses on specific concerns that relate to "national security systems" and "debilitating impact systems," as designated by the DoD and intelligence community. These may present additional opportunities for contractors.

Another section of the E.O. suggests that NIST, CISA, and OMB work together to establish a pilot program of a "rules-as-code approach" for machine-readable versions of policy and guidance that OMB, NIST, and CISA publish and manage regarding cybersecurity. "Rules-as-code approach" is defined as "a coded version of rules (for example, those contained in legislation, regulation, or policy) that can be understood and used by a computer." This is an intriguing concept that could ease regulatory compliance for agencies and contractors.

The final section of the E.O. expands on a 2015 Obama E.O. that allows for the seizure of assets of persons engaging in malicious cyber-enabled activities. The expansion covers persons operating outside the United States who use technology to create "a threat to the national security, foreign policy, or economic health of financial stability of the United States." A long list of examples of prohibited activities falling within this prescription follows.

Key Takeaways

As noted above, it is not clear whether the recommendations and, in some cases, sweeping policy changes proposed in this E.O. will be implemented by the Trump administration. One expects that this much effort would not have been expended to release an eleventh hour E.O. if it did not have ongoing support. Other sources have reported that the transition team was consulted as the E.O. was finalized. It is also noteworthy that in recent days the FAR Council has announced that certain proposed regulations likely to be reversed by the Trump administration have been abandoned, including those relating to greenhouse gas emissions reporting and pay equity for government contractors. Altogether this suggests that the E.O. has at least some support going forward.

In any event, the E.O. is not enforceable on its own, and various agencies and the FAR Council will need to further develop and implement its recommendations. The rulemaking process may very well alter the final product, although it seems there may not be a period of notice and comment for all suggested regulatory changes.

As always in the ever-changing cybersecurity regulatory environment, companies that provide software and cloud services to the government must be vigilant in understanding the rules that apply and the potential exposure for failure to meet requirements.

Public link

Please use the above public link if you want to share this noodl on another website.