NIST Defines “Critical Software” — What it Means for Software Vendors and Device Manufacturers

by Eric Greenwald, Finite State General Counsel

On Friday, June 25, the National Institute of Standards and Technology (NIST) released their much anticipated definition of “critical software” as it pertains to the Biden Executive Order on Improving US Cybersecurity (EO 14028). Per NIST, EO-critical software is defined as any software that has, or has direct software dependencies upon, one or more components with at least one of these attributes:

• is designed to run with elevated privilege or manage privileges;
• has direct or privileged access to networking or computing resources;
• is designed to control access to data or operational technology;
• performs a function critical to trust; or,
• operates outside of normal trust boundaries with privileged access

They define “direct dependencies” as follows (from their FAQ):

“For a given component or product, we mean other software components (e.g., libraries, packages, modules) that are directly integrated into, and necessary for operation of, the software instance in question. This is not a systems definition of dependencies and does not include the interfaces and services of what are otherwise independent products.”

“For a given component or product, we mean other software components (e.g., libraries, packages, modules) that are directly integrated into, and necessary for operation of, the software instance in question. This is not a systems definition of dependencies and does not include the interfaces and services of what are otherwise independent products.”

They also caveat the scope of the definition as follows (emphasis added): 

“The definition applies to software of all forms (e.g., standalone software, software integral to specific devices or hardware components, cloud-based software) purchased for, or deployed in, production systems and used for operational purposes.”

“The definition applies to software of all forms (e.g., standalone software, software integral to specific devices or hardware components, cloud-based software) purchased for, or deployed in, production systems and used for operational purposes.”

This last clause is meant to exclude research or testing software that is deployed outside of a production environment.

A Phased Approach

NIST has provided a preliminary list with several categories of software that will be subject to the “initial EO implementation phase.” There are two important things to note here: First, the Cybersecurity & Infrastructure Security Agency (CISA) is tasked under the EO with providing an “authoritative” list of software categories; and second, NIST does not define what “the initial phase” is (i.e., when it will start or when the next phase will start).

The preliminary list of software categories is as follows:

• Identity, credential, and access management (ICAM)
• Operating systems, hypervisors, container environments
• Web browsers
• Endpoint security
• Network control
• Network protection
• Network monitoring and configuration
• Operational monitoring and analysis
• Remote scanning
• Remote access and configuration management
• Backup/recovery and remote storage

As expected, there are some categories that many deem critical that are not included in the initial phase of the EO-critical list; however, as we’ve noted before, even if your products do not fall into these categories, your organization should be prepared to follow the NIST guidelines anyway. 

Even if a particular category of software is excluded from the initial phase of EO implementation, agencies still have the discretion to require proof of security, as addressed later in the FAQ section of the NIST guidance:

If I am using a software product that is not included in the EO-critical list, but it is critical for me, can I ask the vendor to provide attestation?
Yes, departments and agencies can leverage the EO-critical security measures defined in Section 4(e) as part of a procurement.

If I am using a software product that is not included in the EO-critical list, but it is critical for me, can I ask the vendor to provide attestation?

Yes, departments and agencies can leverage the EO-critical security measures defined in Section 4(e) as part of a procurement.

In other words, vendors need to be prepared to comply with the EO requirements, as any procurement officer may look at what they are selling and determine that it is critical and needs to meet the EO’s requirements. Further, any vendors who do not comply with the EO will find themselves at a competitive disadvantage when vying for sales (whether government or commercial) when lining up against other vendors who do comply. 

About the Author

Finite State General Counsel Eric Greenwald previously served in the Obama White House as Special Assistant to the President, where he focused on protecting critical infrastructure as Senior Director for Cybersecurity on the National Security Council (NSC). Before his selection to the NSC, Eric was the Principal Deputy Director of the FBI’s National Cyber Investigative Joint Task Force and the Deputy Director of Operations at U.S. Cyber Command. Formerly an associate producer for CBS’s “60 Minutes” and for National Public Radio, Eric is a graduate of Yale University with a law degree from the University of Michigan Law School.