U.S. flag   An official website of the United States government
Dot gov

Official websites use .gov
A .gov website belongs to an official government organization in the United States.


Secure .gov websites use HTTPS
A lock (Dot gov) or https:// means you've safely connected to the .gov website. Share sensitive information only on official, secure websites.

NCP FAQs - General Users

  1. What is a security checklist?
  2. Why use security configuration checklists?
  3. What is the Special Publication 800-70?
  4. What is the motivation behind the NIST program?
  5. What technologies is the NIST program targeting?
  6. Who creates the security checklists listed by the NIST program?
  7. What are the program's operational environments?
  8. Should home users apply the Specialized Security-Limited Functionality checklists?
  9. How do you create and submit a checklist?
  10. What process does NIST follow to list the checklists?
  11. Who will maintain the checklists?
  12. How does this help agencies in meeting FISMA-related requirements?
  13. What is the checklist program logo?
What is a security checklist?

A security configuration checklist (sometimes referred to as a lockdown guide, hardening guide, or benchmark configuration) is essentially a document that contains instructions or procedures for configuring an IT product to a baseline level of security. Checklists can be developed not only by IT vendors, but also by consortia, academia, and industry, Federal agencies and other governmental organizations, and others in the public and private sectors. A checklist might include any of the following:

  • Configuration files that automatically set various security settings (e.g., executables, security templates that modify settings, scripts)
  • Documentation (e.g., text file) that guides the checklist user to manually configure software
  • Documents that explain the recommended methods to securely install and configure a device
  • Policy documents that set forth guidelines for such things as auditing, authentication security (e.g., passwords), and perimeter security

Not all instructions in a security configuration checklist need to be for security settings. Checklists can also include administrative practices for an IT product that go hand-in-hand with improvements to the product's security. Often, successful attacks on systems are the direct result of poor administrative practices such as not changing default passwords or failure to apply new patches.

Why use security configuration checklists?

There are many threats to users' computers, ranging from remotely launched network service exploits to malicious code spread through e-mails, malicious web sites, and file downloads. Vulnerabilities in IT products are discovered on an almost daily basis, and many ready-to-use exploits are widely available on the Internet. Because IT products are often intended for a wide variety of audiences, restrictive security controls are usually not enabled by default, so many IT products are immediately vulnerable out-of-the-box. It is a complicated, arduous, and time-consuming task for even experienced system administrators to identify a reasonable set of security settings for many IT products.

While the solutions to IT security are complex, one basic yet effective tool is the security configuration checklist. To facilitate the development of security configuration checklists and to meet the requirements of the Cyber Security Act, NIST has developed a program to (a) provide vendors and other groups with guidance for developing standardized, high-quality checklists to secure IT products, (b) establish a formal framework for the submission of checklists to NIST, and (c) assist users by making available a checklist repository.

Some of the benefits that organizations and individuals can achieve by using checklists are as follows:

  • Providing a baseline level of security to protect against common and dangerous local and remote threats and a consistent approach to securing systems
  • Significantly reducing the time required to research and develop appropriate security configurations for installed IT products
  • Allowing smaller organizations to leverage outside resources to implement recommended practice security configurations
  • Preventing public loss of confidence or embarrassment due to compromise of publicly accessible systems.

While the use of security configuration checklists can greatly improve overall levels of security in organizations, no checklist can permit a system or a product to become 100% secure. However, use of checklists that emphasize hardening of systems against flaws or bugs inherent in software will typically result in greater levels of product security and protection from future threats.

What is the Special Publication 800-70?

NIST, with sponsorship from the Cybersecurity & Infrastructure Security Agency (CISA), has produced Special Publication 800-70 Rev 4: National Checklist Program for IT Products – Guidelines for Checklist Users and Developers to facilitate the development and dissemination of security configuration checklists so that organizations and individual users can better secure their IT products.

This publication is intended for users and developers of IT product security configuration checklists. For checklist users, this document gives an overview of the NIST Checklist Program, explains how to retrieve checklists from NIST's repository, and provides general information about threat models and baseline technical security policies for associated operational environments. For checklist developers, the document sets forth the policies, procedures, and general requirements for participation in the NIST Checklist Program.

What is the motivation behind the NIST program?

Many organizations have created various checklists; however, these checklists may vary widely in terms of quality and usability and may have become outdated as software updates and upgrades have been released. Because there is no central checklist repository, they can be difficult to find. They may not be well documented with the result being that one checklist may differ significantly from another in terms of the level of security provided. It may be difficult to determine if the checklist is current, or how the checklist should be implemented. While many existing checklists are of high quality and quite usable , the majority of checklists aren't accessible or directly usable by most audiences. Consequently, the goals of the NIST program are:

  • To facilitate the development and sharing of security configuration checklists by providing a framework for developers to submit checklists to NIST
  • To assist developers in making checklists that conform to common operational environments and associated baseline levels of security
  • To assist developers and users by providing guidelines for making checklists better documented and more usable
  • To provide a managed process for the review, update, and maintenance of checklists
  • To provide an easy-to-use repository of checklists.

NIST's program also serves to assist vendors in the process of making their checklists available to users out-of-the-box. In such cases, it will still be advisable for product users to consult the NIST checklist repository for updates to pre-installed checklists.

What technologies is the NIST program targeting?
The key IT product technology areas include: operating systems, database systems, web servers, e-mail servers, firewalls, routers, intrusion detection systems, file private Networks, biometric devices, smart cards, mobile devices (e.g., PDAs), multi-purpose devices, telecommunication switching devices, and web browsers.
Who creates the security checklists listed by the NIST program?
Ideally, product vendors will create checklists as they release new products. The vendor is often in the best position to create the checklists, however in some cases 3rd-party checklists could be submitted, such as from recognized security groups, state governments, and corporations.
What are the program's operational environments?

The NIST program identifies several broad and specialized operational environments, any one of which should be common to most audiences. By identifying and describing these environments, developers can better target their checklists to the general security baselines associated with the environments. End-users can better select the checklists that are most appropriate for their operating environments. The operational environments are as follows:

  • Standalone or Small Office/Home Office (SOHO) describes small, informal computer installations that are used for home or business purposes. Standalone encompasses a variety of small-scale environments and devices, ranging from laptops, mobile devices, or home computers, to telecommuting systems, to small businesses and small branch offices of a company.
  • Managed or Enterprise are typically large organizational systems with defined, organized suites of hardware and software configurations, usually consisting of centrally-managed workstations and servers protected from the Internet by firewalls and other network security devices.
  • Custom environments contain systems in which the functionality and degree of security do not fit the other environments. Two typical Custom environments are Specialized Security-Limited Functionality and Legacy:
    • Specialized Security-Limited Functionality: A Specialized Security-Limited Functionality environment contains systems and networks at high risk of attack or data exposure, with security taking precedence over functionality. It assumes systems have limited or specialized (not general purpose workstations or systems) functionality in a highly threatened environment such as an outward facing firewall or public web server or whose data content or mission purpose is of such value that aggressive trade-offs in favor of security outweigh the potential negative consequences to other useful system attributes such as legacy applications or interoperability with other systems. Checklists for this environment are not recommended for home users or for large scale general purpose systems. A Specialized Security-Limited Functionality environment could be a subset of another environment.
    • Legacy: A Legacy environment contains older systems or applications that may use older, less-secure communication mechanisms. Other machines operating in a Legacy environment may need less restrictive security settings so that they can communicate with legacy systems and applications. A Legacy environment could be a subset of a Standalone or Managed environment.
Should home users apply the Specialized Security-Limited Functionality checklists?
Almost never. The Specialized Security-Limited Functionality checklists generally reduce the functionality of products and are recommended only for specialized environments. Home users or users that require maximum functionality of a product will find that Specialized Security-Limited Functionality checklists will cause applications to break. For example, applying a Specialized Security-Limited Functionality checklist to a desktop operating system would likely cause installed applications such as home productivity software and games to cease working.
How do you create and submit a checklist?

For specific information on creating and submitting a new or existing checklist, see the FAQ for vendors and checklist developers.

The NIST Checklist Program provides a lifecycle process and guidance for developing checklists in a consistent fashion. For checklist developers, steps include the initial development of the checklist, checklist testing, documenting the checklist according to the guidelines of the program, and submitting a checklist package to NIST. NIST then screens the checklist according to program requirements prior to a public review of the checklist, which typically lasts 30 to 60 days. After the public review period and any subsequent issue resolution, it will be listed on the NIST checklist repository with a detailed description. NIST will periodically ask checklist developers to review their checklists and provide updates as necessary. NIST will retire or archive checklists as they become outdated or incorrect.

What process does NIST follow to list the checklists?
After the checklist information is submitted to NIST, NIST will screen the checklist for adherence to the development criteria and format. After addressing any issues with the checklist submitter, NIST will post the checklist for public review. Issues raised during the review will be addressed by the producer. After all issues are addressed satisfactorily, the checklist or checklist description will be posted on the NIST checklist repository.
Who will maintain the checklists?
Checklist submitters will be responsible for maintaining their associated checklists when new versions of the products appear. When the final checklist is listed, NIST will set a periodic review schedule with the developer. Typically, the timeframe for the review will be one year; however, it could be sooner depending on certain factors such as the discovery of new vulnerabilities. If the developer decides to update the checklist, NIST will announce that the checklist is in the process of being updated. If the checklist contains major changes, it will be accepted as if it were a new submission; it must undergo the same reviews as a new submission.
How does this help agencies in meeting FISMA-related requirements?
FISMA (section 3544(b)(2)(D)(iii)) requires each agency to determine minimally acceptable system configuration requirements and ensure compliance with them. Accordingly, Federal agencies, as well as vendors of products for the Federal government, are encouraged to acquire or develop and share such checklists using the NIST repository. The development and sharing of these checklists can greatly reduce what would otherwise be a reinvention of the wheel for IT products that are widely used in the Federal government, e.g., common operating systems and office applications.
What is the checklist program logo?

Checklist producers, e.g., vendors, will be able to use a checklist program logo on product literature or websites to show participation in the NIST program and ownership of a checklist on the repository. To use the logo, the producer must provide checklist-related assistance. The logo does not convey NIST endorsement of the checklist or IT product.