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.
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. In this case, the product developer will treat the open source components as part of their own development process. In other situations, the open source software is a standalone product. In this case, the requirements of the EO still apply. The Government may need to address some of the requirements under Section 4(e) itself if the open source community supporting the product does not or cannot.
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. While Section 4 of the EO does not make a distinction between commercial and GOTS software, the manner in which GOTS software is developed and procured may necessitate differences in the standards, procedures, and criteria that will be developed for critical software under this EO.
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. When developers attest to the security measures under Section 4(e), they can specify which components of their product are EO-critical and meet the security measures in 4(e) and which are not. While this may lead vendors to different interpretations for how to scope their attestations, the objective is to require vendors to be clear about which components are being attested to and which are not.
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.
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. This will allow the Government to purchase software that is EO-critical for these non-operational uses even if the vendor has not implemented or attested to the security measures in 4(e).
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.
No. The definition of EO-critical is based on the functions of the software, not its use. This will enable software vendors to know if their products are EO-critical independent of individual acquisitions and deployments, so they can address the requirements of Section 4(e). This will create clarity in the marketplace. Otherwise, the Government might seek to buy a product, but no vendor anticipated it would be EO-critical, resulting in either no products or a limited number of products available for the Government to purchase. 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.
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: