Official websites use .gov
A .gov website belongs to an official government organization in the United States.
Secure .gov websites use HTTPS
A lock (
) or https:// means you’ve safely connected to the .gov website. Share sensitive information only on official, secure websites.
Critical Software Definition - FAQs
The following FAQs were compiled in consultation with OMB and CISA to provide additional context to the material.
CISA and OMB will monitor the implementation of the program in the initial phase and decide when to include additional software categories.
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.
“Critical to trust” covers categories of software used for security functions such as network control, endpoint security, and network protection.
- Does it matter if the software product is in the cloud or in an on-premises or a hybrid environment?
No. If a product or service provides functions that are part of the definition of EO-critical, then the product or service itself is EO-critical, regardless of its deployment model. Having said that, NIST has recommended that the initial phase of the EO focus on on-premises software. Many on-premises products rely on cloud-based components and services that perform EO-critical functions (e.g., cloud-based access control). In such situations, the on-premises components are in scope if they directly perform EO-critical functions. It is suggested that cloud-based components and systems be addressed in later phases of implementation to allow time to coordinate with other Federal requirements for such systems (e.g., FedRAMP).
Yes. If open source software performs functions that are defined as EO-critical, then it is EO-critical. In practice, open source software is often incorporated into other products.
Yes. The Federal Government develops software both in-house and through contracts. These products are often referred to as GOTS (government-off-the-shelf) software. If GOTS software performs functions included in the definition of EO-critical, then it is EO-critical.
If a product contains functions that are part of the definition of EO-critical, then the product itself is EO-critical. However, some EO-critical software products may contain distinct components that do not have EO-critical attributes or do not directly support the EO-critical functions provided by the product.
If a product performs functions that are part of the definition of EO-critical, then the product itself is EO-critical. When vendors attest to the implementation of the security measures under Section 4(e), they can specify which components of their products are covered. These may include components developed by other parties. For example, if the Government is buying a product that contains an operating system, the product is EO-critical and requires an attestation about the security measures, but the attestation can be limited to the operating system. See FAQ #7.
Section 3 of the EO addresses modernization of FedRAMP. The recommended phased approach starts with on-premises software, with the understanding that some on-premises software which relies on cloud-hosted components may be in scope. CISA will coordinate with FedRAMP to define the scope and applicability of the EO to cloud-based software in later phases of the implementation.
- The definition excludes software that won’t be deployed in production systems for operational purposes. Can you provide more explanation?
There are several use cases where software is owned but is not deployed in a manner that would pose a significant risk of harm if compromised. Examples include software used as the subject of research and software collected for archival purposes.
Section 9 of the EO describes the applicability of the requirements of this EO to National Security Systems.
Yes. If embedded software or firmware performs functions that are defined as EO-critical, then it is EO-critical. Due to the complexities of such products, we recommended that such software not be included in the initial phase of implementation.
- Shouldn’t departments and agencies decide what is EO-critical based on how the software is used to support the agency’s mission?
No. The definition of EO-critical is based on the functions of the software, not its use. The types of software defined by the table are likely to be EO-critical in most situations.
There are many types of safety-critical and other high-assurance systems. Many of them have regulatory or industry-based security requirements. If these systems make use of software that contains EO-critical functions, then that software is EO-critical. Safety-critical and high-assurance software and systems will have additional security requirements. For example, if a high-assurance system contains an operating system, the operating system is EO-critical and must meet the EO-critical requirements in addition to the safety-critical or other system requirements.
- 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.
A High Value Asset (HVA) is information or an information system that is so critical to an organization that the loss or corruption of this information or loss of access to the system would have serious impact to the organization's ability to perform its mission or conduct business. The HVA program focuses on the overarching system and the value it provides to the agency. EO Critical Software security measures are intended to protect the use of deployed EO-critical software in agencies' operational environments on-premises or in the cloud. The EO-Critical Software pinpoints the software that may feed into the HVA systems.
Some additional background on HVA:
An agency may designate Federal information or a Federal information system as an HVA when it relates to one or more of the following categories:
- Informational Value - The information or information system that processes, stores, or transmits the information is of high value to the Government or its adversaries.
- Mission Essential - The agency that owns the information or information system cannot accomplish its Primary Mission Essential Functions (PMEF), as approved in accordance with Presidential Policy Directive 40 (PPD-40) National Continuity Policy, within expected timelines without the information or information system.
- Federal Civilian Enterprise Essential (FCEE) - The information or information system serves a critical function in maintaining the security and resilience of the Federal civilian enterprise.
Previous Sections: