Improving the Nation's Cybersecurity: NIST’s Responsibilities under the May 2021 Executive Order

Overview:

The President’s Executive Order (EO) on “Improving the Nation’s Cybersecurity (14028)” issued on May 12, 2021, charges multiple agencies – including NIST– with enhancing cybersecurity through a variety of initiatives related to the security and integrity of the software supply chain.

Section 4 of the EO directs NIST to solicit input from the private sector, academia, government agencies, and others and to identify existing or develop new standards, tools, best practices, and other guidelines to enhance software supply chain security. Those guidelines are to include: 

  • criteria to evaluate software security,  
  • criteria to evaluate the security practices of the developers and suppliers themselves, and 
  • innovative tools or methods to demonstrate conformance with secure practices. 

The EO calls for NIST to consult with the National Security Agency (NSA), Office of Management and Budget (OMB), Cybersecurity & Infrastructure Security Agency (CISA), and the Director of National Intelligence (DNI) and then to define “critical software” by June 26, 2021.  

NIST is to publish guidance outlining security measures for critical software by July 11, 2021, after consulting with CISA and OMB. 

Also by July 11, 2021, after consulting with the NSA, NIST will publish guidelines recommending minimum standards for vendors’ testing of their software source code

By November 8, 2021, NIST is to publish preliminary guidelines, based on stakeholder input and existing documents for enhancing software supply chain security. 

By February 6, 2022, after consulting heads of various agencies, NIST will issue guidance that identifies practices that enhance software supply chain security, with references to standards, procedures, and criteria.  

By May 8, 2022, NIST will publish additional guidelines, including procedures for periodically reviewing and updating guidelines. 

The EO also directs NIST to initiate two labeling programs related to the Internet of Things (IoT) and software to inform consumers about the security of their products. Those efforts have initial deadlines of February 6, 2022. Like its other assignments in the EO, NIST will rely heavily on stakeholder ideas and information in carrying out these tasks.


LATEST UPDATES


Critical Software

The Executive Order (EO) on Improving the Nation’s Cybersecurity (14028) assigns NIST with three specific directives relating to critical software.

First, NIST is to consult with the National Security Agency (NSA), Office of Management and Budget (OMB), Cybersecurity & Infrastructure Security Agency (CISA), and the Director of National Intelligence (DNI) and then to define “critical software” by June 26, 2021.  

Second, NIST is to publish guidance outlining security measures for critical software by July 11, 2021, after consulting with CISA and OMB. 
 

Critical Software Definition

Critical Software: Enhancing the Security of the Software Supply Chain

One of NIST’s assignments to enhance the security of the software supply chain called for by May 12, 2021, Presidential Executive Order on Improving the Nation’s Cybersecurity (14028) is to publish a definition of “critical software.”

The executive order (EO) directs the Cybersecurity & Infrastructure Security Agency (CISA) to develop a list of software categories and products in use or in the acquisition process which meet this definition of critical software.

To coordinate the definition with its eventual application, NIST solicited position papers from the community, hosted a virtual workshop to gather input, and consulted with CISA, the Office of Management and Budget (OMB), the Office of the Director of National Intelligence (ODNI), and the National Security Agency (NSA) to develop the definition, the concept of a phased implementation, and a preliminary list of common categories of software that would fall within the scope for the initial phase. Additional guidance on applying this definition for implementing the EO will be forthcoming from CISA and OMB. NIST worked closely with CISA and OMB to ensure that the definition and recommendations are consistent with their plans. 

The specific definition of critical software is included in a NIST white paper.

Critical Software Definition - Introduction

October 13, 2021

Note:
NIST is updating its characterization of critical software to reflect conversations with the National Security Council (NSC) and the Office of Management and Budget (OMB). The definition of critical software applies only to Government management of software (Sections 4i and 4j). The requirements in 4e and 4k related to acquisition apply to all software, not just to critical software. This does not alter the definition of critical software, although it changes NIST’s initial guidance about how the definition should be used.  NIST has modified several FAQs accordingly.

Executive Order (EO) 14028 on Improving the Nation’s Cybersecurity, issued on May 12, 2021, directs the National Institute of Standards and Technology (NIST) to publish a definition of the term critical software.

(g)  Within 45 days of the date of this order, the Secretary of Commerce, acting through the Director of NIST, in consultation with the Secretary of Defense acting through the Director of the NSA, the Secretary of Homeland Security acting through the Director of CISA, the Director of OMB, and the Director of National Intelligence, shall publish a definition of the term “critical software” for inclusion in the guidance issued pursuant to subsection (e) of this section. That definition shall reflect the level of privilege or access required to function, integration and dependencies with other software, direct access to networking and computing resources, performance of a function critical to trust, and potential for harm if compromised.

The EO directs the Cybersecurity & Infrastructure Security Agency (CISA) to use this published definition of critical software to develop a list of software categories and products that are in scope for that definition and thus subject to the further requirements of the EO.

(h)  Within 30 days of the publication of the definition required by subsection (g) of this section, the Secretary of Homeland Security acting through the Director of CISA, in consultation with the Secretary of Commerce acting through the Director of NIST, shall identify and make available to agencies a list of categories of software and software products in use or in the acquisition process meeting the definition of critical software issued pursuant to subsection (g) of this section.           

To coordinate the definition with its eventual application, NIST solicited position papers from the community, hosted a virtual workshop to gather input, and consulted with CISA, the Office of Management and Budget (OMB), the Office of the Director of National Intelligence (ODNI), and the National Security Agency (NSA) to develop the definition, the concept of a phased implementation, and a preliminary list of common categories of software that would fall within the scope for the initial phase. Additional guidance on applying this definition for implementing the EO will be forthcoming from CISA and OMB. NIST worked closely with CISA and OMB to ensure that the definition and recommendations are consistent with their plans.

This webpage starts with background information and context for the term critical and introduces the concept of a phased approach. It defines the term critical software in the context of the EO and provides a preliminary list of software that meets the definition of EO-critical and is recommended to be included in the initial phase of implementation. The webpage concludes with frequently asked questions (FAQs). CISA will provide the final set of software categories for the initial and future implementation phases.

Critical Software Definition - Background & Approach

Background

Recent incidents have demonstrated the need for the Federal Government to improve its efforts to identify, deter, protect against, detect, and respond to malicious cyber actions and actors. In particular, threat actors are exploiting the pervasive use of software and the complexity of the underlying code and software development and distribution practices. One of the goals of the EO is to assist in developing a security baseline for critical software products used across the Federal Government. The designation of software as EO-critical will then drive additional activities, including how the Federal Government purchases and manages deployed critical software. In particular, the EO seeks to limit acquisition to software that has met security measures such as use of a secure development process and integrity checks that are defined in Section 4(e) of the EO.

Given the broad scope of the EO and its potential impact on both government operations and the software marketplace, NIST set the following goals for the definition of critical software:

  • Clarity – The implementation of the program will drive activity across the entire Federal Government, with impacts on the software industry. Having a clear definition that can be used by the software industry and the Government is vital to the successful implementation of the EO.
  • Viability – For the EO to be viable, its implementation must take into consideration how the software industry functions, including product development, procurement, and deployment. The software marketplace is dynamic and evolves continuously. How software is developed, brought into an organization, and used by an organization is changing rapidly. Software is purchased as a product, as part of a product, and as a service. Software is often modular, consisting of many components.

There are many existing definitions and uses of the term critical. Most are based on how technology supports various tasks or processes, such as safety critical or critical infrastructure. The use of the term in the EO is slightly different because it is based not on the context of use, but on the properties of a given piece of software that make it likely to be critical in most use cases. That is, it focuses on critical functions that address underlying infrastructure for cyber operations and security. This is similar to the concept of Federal Civilian Enterprise Essential IT under the High-Value Assets program.

In order to separate the common usage of critical with the definition under the EO, we will use the term EO-critical when it is unclear which usage is being discussed.

Approach

Given the size, scope, and complexity of the software marketplace and the infrastructure needed within the government to implement the EO, NIST has consulted with key agencies regarding the concept of a phased approach for securing the supply chain of EO-critical software. This will allow both the Federal Government and the software industry to implement the EO in an incremental manner, thus providing the opportunity for feedback and improvements to its processes with each additional phase.

Information technology and Cybersecurity

Critical Software - Definition & Explanatory Material

This section provides the definition of EO-critical software. Following that is a table with a preliminary list of software categories recommended for the initial phase along with some explanatory material. At a later date, CISA will provide the authoritative list of software categories that are within the scope of the definition and to be included in the initial phase of implementation. A pointer to that information will be provided here when available.

Finally, there is a set of FAQs at the bottom of the page that provides answers to questions that may arise about the interpretation of the definition, the phased approach, and other related topics.

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.

The definition applies to the 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. Other use cases, such as software solely used for research or testing that is not deployed in production systems, are outside of the scope of this definition. (See FAQ #10 and FAQ #11.)

NIST recommends that the initial EO implementation phase focus on standalone, on-premises software that has security-critical functions or poses similar significant potential for harm if compromised. Subsequent phases may address other categories of software such as:

  • software that controls access to data.
  • cloud-based and hybrid software.
  • software development tools such as code repository systems, development tools, testing software, integration software, packaging software, and deployment software.
  • software components in boot-level firmware; or
  • software components in operational technology (OT).

The table below provides a preliminary list of software categories considered to be EO-critical. This table is provided to illustrate the application of the definition of EO-critical software to the scope of the recommended initial implementation phase described above. As noted previously, CISA will provide the authoritative list of software categories at a later date.

Category of Software

Description

Types of Products

Rationale for Inclusion

Identity, credential, and access management (ICAM)

Software that centrally identifies, authenticates, manages access rights for, or enforces access decisions for organizational users, systems, and devices

  • Identity management systems
  • Identity provider and federation services
  • Certificate issuers
  • Access brokers
  • Privileged access management software
  • Public key infrastructure
  • Foundational for ensuring that only authorized users, systems, and devices can obtain access to sensitive information and functions

Operating systems, hypervisors, container environments

 

 

Software that establishes or manages access and control of hardware resources (bare metal or virtualized/ containerized) and provides common services such as access control, memory management, and runtime execution environments to software applications and/or interactive users

  • Operating systems for servers, desktops, and mobile devices
  • Hypervisors and container runtime systems that support virtualized execution of operating systems and similar environments
  • Highly privileged software with direct access and control of underlying hardware resources and that provides the most basic and critical trust and security functions

Web browsers

Software that processes content delivered by web servers over a network, and is often used as the user interface to device and service configuration functions

  • Standalone and embedded browsers
  • Performs multiple access management functions
  • Supports browser plug-ins and extensions such as password managers for storing credentials for web server resources
  • Provides execution environments for code downloaded from remote sources
  • Provides access management for stored content, such as an access token which is provided to web servers upon request

Endpoint security
 

Software installed on an endpoint, usually with elevated privileges which enable or contribute to the secure operation of the endpoint or enable the detailed collection of information about the endpoint

  • Full disk encryption
  • Password managers
  • Software that searches for, removes, or quarantines malicious software
  • Software that reports the security state of the endpoint (vulnerabilities and configurations)
  • Software that collects detailed information about the state of the firmware, operating system, applications, user and service accounts, and runtime environment
  • Has privileged access to data, security information, and services to enable deep inspection of both user and system data
  • Provides functions critical to trust

Network control

Software that implements protocols, algorithms, and functions to configure, control, monitor, and secure the flow of data across a network

  • Routing protocols
  • DNS resolvers and servers
  • Software-defined network control protocols
  • Virtual private network (VPN) software
  • Host configuration protocols
  • Privileged access to critical network control functions
  • Often subverted by malware as the first step in more sophisticated attacks to exfiltrate data

Network protection

Products that prevent malicious network traffic from entering or leaving a network segment or system boundary

  • Firewalls, intrusion detection/ avoidance systems
  • Network-based policy enforcement points
  • Application firewalls and inspection systems
  • Provides a function critical to trust, often with elevated privileges

Network monitoring and configuration

Network-based monitoring and management software with the ability to change the state of—or with installed agents or special privileges on—a wide range of systems

  • Network management systems
  • Network configuration management tools
  • Network traffic monitoring systems
  • Capable of monitoring and/or configuring enterprise IT systems using elevated privileges and/or remote installed agents

Operational monitoring and analysis

 

Software deployed to report operational status and security information about remote systems and the software used to process, analyze, and respond to that information

  • Security information and event management (SIEM) systems
  • Software agents widely deployed with elevated privilege on remote systems
  • Analysis systems critical to incident detection and response and to forensic root cause analysis of security events
  • Often targeted by malware trying to deactivate or evade it

Remote scanning

Software that determines the state of endpoints on a network by performing network scanning of exposed services

  • Vulnerability detection and management software
  • Typically has privileged access to network services and collects sensitive information about the vulnerabilities of other systems

Remote access and configuration management

Software for remote system administration and configuration of endpoints or remote control of other systems

  • Policy management
  • Update/patch management
  • Application configuration management systems
  • Remote access/ sharing software
  • Asset discovery and inventory systems
  • Mobile device management systems
  • Operates with significant access and elevated privileges, usually with little visibility or control for the endpoint user

Backup/recovery and remote storage

Software deployed to create copies and transfer data stored on endpoints or other networked devices

  • Backup service systems
  • Recovery managers
  • Network-attached storage (NAS) and storage area network (SAN) software
  • Privileged access to user and system data
  • Essential for performing response and recovery functions after a cyber incident (e.g., ransomware)

Software Supply Chain Security

 

The Executive Order (EO) on Improving the Nation’s Cybersecurity (14028) directs NIST to publish a variety of guidance that would enhance software supply chain security. Among other deliverables, NIST published these documents for public comment:

NIST earlier produced other guidance to improve software security:

Recommended Minimum Standards for Vendor or Developer Verification (Testing) of Software Under Executive Order (EO) 14028
Introduction

Executive Order (EO) 14028 on Improving the Nation’s Cybersecurity, May 12, 2021, directs the National Institute of Standards and Technology (NIST) to publish guidelines on vendors’ source code testing.

“Section 4(r) Within 60 days of the date of this order, the Secretary of Commerce acting through the Director of NIST, in consultation with the Secretary of Defense acting through the Director of the NSA, shall publish guidelines recommending minimum standards for vendors’ testing of their software source code, including identifying recommended types of manual or automated testing (such as code review tools, static and dynamic analysis, software composition tools, and penetration testing).”

NIST solicited position papers from the community, hosted a virtual workshop to gather input, and consulted with the National Security Agency (NSA) to develop the recommended minimum standards as well as supplementary material to put the standards in the context of a robust testing program which, in turn, is part of a robust development process. 

NIST has developed a document that recommends minimum standards for vendor or developer verification of software. These guidelines are summarized on this webpage. See FAQ #3 and FAQ #4 for an explanation of why NIST added the terminology developers and verification.

Note that NIST will be developing guidance on software testing tools and attestations under Part 4(e) of the EO. See FAQ #1

This webpage provides background information and context for minimum standards for software verification. It then defines eleven tasks and techniques which comprise the recommended software verification minimums. The twelfth task, fixing critical bugs, is included for completeness.

Recommended Minimum Standards for Vendor or Developer Verification (Testing) of Software Under Executive Order (EO) 14028 - PDF Version

Recommended Minimum Standards for Vendor or Developer Verification (Testing) of Software Under Executive Order (EO) 14028 - Background & Approach

To ensure that software is sufficiently safe and secure, the software must be designed, built, delivered, and maintained in accordance with best practices. Frequent and thorough testing by developers as early as possible in the software development life cycle (SDLC) is one critical practice. At its highest conceptual level, verification is a discipline employed to increase software security. Verification encompasses many static and active assurance techniques, tools, and related processes to identify and remediate security defects while continuously improving the methodology and supporting processes. They must be employed alongside other methods to achieve a high level of software security.

This webpage summarizes the minimum standards recommended for verification by software vendors or developers. No single verification standard can encompass all types of software testing, be specific and prescriptive, and present efficient and effective testing. Thus, this document recommends high-level guidelines for software producers to create their own prescriptive processes.

These guidelines expand on NIST’s Secure Software Development Framework (SSDF) practices.  See especially Produce Well-Secured Software (PW) Practice 7, Review and/or Analyze Human-Readable Code to Identify Vulnerabilities and Verify Compliance with Security Requirements, and PW Practice 8, Test Executable Code to Identify Vulnerabilities and Verify Compliance with Security Requirements. 

Recommended Minimum Standard for Vendor or Developer Verification of Code
The following are recommended minimums for verification of code by developers. Some of the minimums are the precursors to effective testing and some are the logical outcomes of the testing. Each of the techniques is described in the accompanying document.

 

Technique Class

Technique

Description & Reference to Recommended Minimums Document

Threat modeling

Threat modeling helps identify key or potentially overlooked testing targets.

Section 2.1. Threat modeling methods create an abstraction of the system, profiles of potential attackers and their goals and methods, and a catalog of potential threats. Threat modeling can identify design-level security issues and help focus verification.

Automated testing

As testing is automated, it can be repeated often, for instance upon every commit or before an issue is retired.

Section 2.2. Automated testing can run tests consistently, check results accurately, and minimize the need for human effort and expertise. Automated testing can be integrated into the existing workflow or issue tracking system.

Code-based (static) analysis

Use a code scanner to look for top bugs.

Section 2.3. Static analysis tools can check code for many kinds of vulnerabilities and for compliance with the organization’s coding standards. For multi-threaded or parallel processing software, use a scanner capable of detecting race conditions.

Review for hardcoded secrets. 

Section 2.4. Heuristic tools can be somewhat effective checking for hardcoded passwords and private encryption keys since functions or services taking these as parameters have specific interfaces.

Dynamic analysis (i.e., run the program on test cases)

Run with built-in checks and protections.

Section 2.5. Programming languages, both compiled and interpreted, provide many built-in checks and protections.

Create “black box” test cases.

Section 2.6. “Black box” tests can address functional specifications or requirements, negative tests (invalid inputs and testing what the software should not do), denial of service and overload attempts, input boundary analysis, and input combinations.

Create code-based structural test cases.

Section 2.7. Code-based, or structural, test cases are based on the implementation, that is, the specifics of the code. Code-based test cases may also come from coverage metrics.

Use test cases created to catch previous bugs.

Section 2.8. Test cases which have been created to specifically show the presence (and later, the absence) of a bug can be used to identify issues in the absence of more general “first principles” assurance approaches for detecting bugs.

Run a fuzzer.

Section 2.9. Fuzzers can try an immense number of inputs with minimal human supervision. The tools can be programmed with inputs that often reveal bugs, such as very long or empty inputs and special characters. 

If the software might be connected to the Internet, run a web app scanner.

Section 2.10. If there is a network interface, use a dynamic security testing tool (e.g., web application scanner) to detect vulnerabilities.

Check included software

Use similar techniques to gain assurance that included libraries, packages, services, etc. are no less secure than your code.

Section 2.11. Use the verification techniques recommended in this section to gain assurance that included code is at least as secure as code developed locally. The components of your software must be continually monitored against databases of known vulnerabilities; a new vulnerability in existing code may be reported at any time.

Fix bugs

Fix critical bugs that are uncovered.

Correct critical bugs as soon as possible and make process improvements necessary to prevent such bugs in the future, or to at least catch them earlier in the development process.

Cybersecurity Labeling for Consumers: Internet of Things (IoT) Devices and Software

The May 12, 2021, Presidential Executive Order on Improving the Nation’s Cybersecurity (14028) directs NIST to initiate two labeling programs on cybersecurity capabilities of Internet-of-Things (IoT) consumer devices and software development practices. The agency also received several other directives to enhance the security of the software supply chain.

Section 4 of the order directs NIST to take into account existing consumer product labeling programs as it considers efforts to educate the public on the cybersecurity capabilities of Internet-of-Things (IoT) devices and software development practices. NIST also is to consider ways to incentivize manufacturers and developers to participate in these programs.

By February 6, 2022, in coordination with the Federal Trade Commission (FTC) and other agencies, NIST is required to identify:

  • IoT cybersecurity criteria for a consumer labeling program and
  • secure software development practices or criteria for a consumer software labeling program.

NIST is relying heavily on information provided by diverse stakeholders as it carries out these directives. In October, NIST solicited public comments on draft criteria for consumer software cybersecurity and labeling. In August, the agency released for public comment a white paper suggesting a draft set of potential baseline security criteria for IoT devices. In November, NIST solicited public comments on draft criteria for consumer software cybersecurity and labeling.

NIST is identifying key elements of labeling programs in terms of minimum requirements and desirable attributes – rather than establishing its own programs; NIST will specify desired outcomes, allowing providers and customers to choose best solutions for their devices and environments. One size may not fit all, and multiple solutions might be offered by label providers.

Labeling should:

  • Encourage innovation in manufacturers’ consumer oriented IoT and software security efforts, leaving room for changes in technologies and the security landscape.
  • Be practical and not be burdensome to manufacturers and distributors.
  • Factor in usability as a key consideration.
  • Build on national and international experience.
  • Allow for diversity of approaches and solutions across industries, verticals, and use cases – so long as they are deemed useful and effective for consumers.

On September 14-15, 2021, NIST hosted a virtual public workshop on these consumer education-oriented efforts. The workshop included facilitated panel discussions and presentations based on the preliminary feedback on the draft IoT criteria and the consumer software labeling position papers submitted to NIST and on preliminary feedback on potential IoT baseline security criteria. On December 2, 2021, taking public feedback into account, NIST released a further discussion paper: Consumer Cybersecurity Labeling for IoT Products: Discussion Draft on the Path Forward. This paper will be discussed at the upcoming workshop Cybersecurity Labeling for Consumer IoT and Software: Executive Order Update and Discussion - December 9, 2021.

Questions about NIST’s activities related to these efforts should be directed to This email address is being protected from spambots. You need JavaScript enabled to view it..

Information technologyCybersecurity and Internet of Things (IoT) Information technology and Cybersecurity

Workshops on Cybersecurity Labeling of Consumer Products

 

IoT Product Criteria

As part of its assignment under the Presidential Executive Order on Improving the Nation’s Cybersecurity (14028) issued on May 12, 2021, NIST is responsible for a multi-faceted initiative related to cybersecurity labeling for consumers. That includes labeling for Internet of Things (IoT) products. Under the Executive Order, NIST is to publish details about the IoT labeling effort by February 6, 2022. NIST will identify key elements of IoT labeling programs in terms of minimum requirements and desirable attributes – rather than establishing its own program, it will specify desired outcomes, allowing providers and customers to choose best solutions for their products and environments. One size may not fit all, and multiple solutions might be offered by label providers. 

On August 31, 2021, NIST released a white paper with draft criteria for a labeling program on cybersecurity capabilities of Internet of Things (IoT) devices. NIST sought comments on the draft criteria, which suggested a set of potential baseline security criteria for IoT devices. Comments on the draft white paper were due no later than October 18, 2021. Those comments are available here.

On December 2, 2021, taking public feedback into account, NIST released a further discussion paper: Consumer Cybersecurity Labeling for IoT Products: Discussion Draft on the Path Forward. This paper will be discussed at the upcoming workshop Cybersecurity Labeling for Consumer IoT and Software: Executive Order Update and Discussion - December 9, 2021.

Consumer Cybersecurity Labeling for IoT Products: Discussion Draft on the Path Forward


Draft white paper with draft criteria for a labeling program
on cybersecurity capabilities of Internet-of-Things (IoT) devices

Comments received on draft criteria

For questions, contact: This email address is being protected from spambots. You need JavaScript enabled to view it.

Information technologyCybersecurity, and Internet of Things (IoT)

Consumer Software Criteria

As part of its assignment under the Presidential Executive Order on Improving the Nation’s Cybersecurity (14028) issued on May 12, 2021, NIST has released a white paper with draft criteria for consumer software cybersecurity labeling. This is one part of a multi-faceted initiative under the executive order related to cybersecurity labeling for consumers. NIST is seeking comments on the draft criteria, which suggests a set of potential baseline security criteria for consumer software.

Comments on the draft white paper are due no later than December 16, 2021. Under the Executive Order, NIST is to publish details about the consumer software labeling effort by February 6, 2022.

Comments should be submitted to: This email address is being protected from spambots. You need JavaScript enabled to view it.. Receipt of submissions will be acknowledged via email. All comments will be published on this website. Please submit comments only and include your name and organization’s name (if any) and cite “Draft Consumer Software Labeling Criteria.” Personally identifiable information (PII), such as street addresses, phone numbers, account numbers, or Social Security numbers, or names of other individuals, should not be included. Do not submit confidential business information or otherwise sensitive or protected information. 

NIST will identify key elements of labeling programs in terms of minimum requirements and desirable attributes – rather than establishing its own programs; it will specify desired outcomes, allowing providers and customers to choose best solutions for their devices and environments. One size may not fit all, and multiple solutions might be offered by label providers. 

November 1, 2021 - Draft white paper with draft criteria for a labeling program on consumer software

Information technologyCybersecurity, and Internet of Things (IoT)
Main Menu