NIST public full text Public Domain

NIST SP 800-70r5 ipd: National Checklist Program for IT Products: Guidelines for Checklist Users and Developers

Stephen Quinn (NIST); Blair Heiserman (NIST) · National Institute of Standards and Technology (NIST)

NIST · Standards · License: Public Domain

access-control computer-security cryptography cybersecurity identity incident-response nist privacy

Conceptio Open Archive

Analyze & explore related research in Conceptio

Connect this record directly into your research workflow or AI agent. Explore citations across open repositories, query full text, and export structured proof bundles.

Explore in Search →Connect via MCP / API ↗

Withdrawn Draft Warning Notice The attached draft document has been withdrawn and is provided solely for historical purposes. It has been followed by the document identified below. Withdrawal Date May 8, 2026 Original Release Date December 9, 2025

The attached draft document is followed by: Stage Final Series/Number NIST SP 800-70r5 Title National Checklist Program for IT Products: Guidelines for Checklist Users and Developers Publication Date May 2026 DOI https://doi.org/10.6028/NIST.SP.800-70r5 CSRC URL https://csrc.nist.gov/pubs/sp/800/70/r5/final Additional Information

NIST Special Publication 800 NIST SP 800-70r5 ipd

National Checklist Program for IT Products Guidelines for Checklist Users and Developers Initial Public Draft Stephen D. Quinn Blair Heiserman

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-70r5.ipd

NIST Special Publication 800 NIST SP 800-70r5 ipd

National Checklist Program for IT Products Guidelines for Checklist Users and Developers Initial Public Draft Stephen D. Quinn

Computer Security Division Information Technology Laboratory

Blair Heiserman

Information Technology Security & Networking Division Office of Information Systems Management

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-70r5.ipd December 2025

U.S. Department of Commerce Howard Lutnick, Acting Secretary of Commerce National Institute of Standards and Technology Craig Burkhardt, Acting Under Secretary of Commerce for Standards and Technology and Acting NIST Director

NIST SP 800-70r5 ipd (Initial Public Draft) December 2025

National Checklist Program for IT Products: Guidelines for Checklist Users and Developers

Certain equipment, instruments, software, or materials, commercial or non-commercial, are identified in this paper in order to specify the experimental procedure adequately. Such identification does not imply recommendation or endorsement of any product or service by NIST, nor does it imply that the materials or equipment identified are necessarily the best available for the purpose. There may be references in this publication to other publications currently under development by NIST in accordance with its assigned statutory responsibilities. The information in this publication, including concepts and methodologies, may be used by federal agencies even before the completion of such companion publications. Thus, until each publication is completed, current requirements, guidelines, and procedures, where they exist, remain operative. For planning and transition purposes, federal agencies may wish to closely follow the development of these new publications by NIST. Organizations are encouraged to review all draft publications during public comment periods and provide feedback to NIST. Many NIST cybersecurity publications, other than the ones noted above, are available at https://csrc.nist.gov/publications. Authority This publication has been developed by NIST in accordance with its statutory responsibilities under the Federal Information Security Modernization Act (FISMA) of 2014, 44 U.S.C. § 3551 et seq., Public Law (P.L.) 113-283. NIST is responsible for developing information security standards and guidelines, including minimum requirements for federal information systems, but such standards and guidelines shall not apply to national security systems without the express approval of appropriate federal officials exercising policy authority over such systems. This guideline is consistent with the requirements of the Office of Management and Budget (OMB) Circular A-130. Nothing in this publication should be taken to contradict the standards and guidelines made mandatory and binding on federal agencies by the Secretary of Commerce under statutory authority. Nor should these guidelines be interpreted as altering or superseding the existing authorities of the Secretary of Commerce, Director of the OMB, or any other federal official. This publication may be used by nongovernmental organizations on a voluntary basis and is not subject to copyright in the United States. Attribution would, however, be appreciated by NIST. NIST Technical Series Policies Copyright, Use, and Licensing Statements NIST Technical Series Publication Identifier Syntax Publication History Approved by the NIST Editorial Review Board on YYYY-MM-DD [Will be added to final publication.] Supersedes NIST Series XXX (Month Year) DOI [Will be added to final publication, if applicable.] How to Cite this NIST Technical Series Publication Quinn SD, Heiserman B (2025) National Checklist Program for IT Products: Guidelines for Checklist Users and Developers. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) NIST SP 8000-70r5 ipd. https://doi.org/10.6028/NIST.SP.800-70r5.ipd Author ORCID iDs Stephen Quinn: 0000-0003-1436-684X Blair Heiserman: 0009-0003-8779-6231

NIST SP 800-70r5 ipd (Initial Public Draft) December 2025

National Checklist Program for IT Products: Guidelines for Checklist Users and Developers

Public Comment Period December 9, 2025 – January 16, 2026 Submit Comments checklists@nist.gov National Institute of Standards and Technology Attn: Computer Security Division, Information Technology Laboratory 100 Bureau Drive (Mail Stop 8930) Gaithersburg, MD 20899-8930 Additional Information Additional information about this publication is available at https://csrc.nist.gov/pubs/sp/800/70/r5/ipd, including related content, potential updates, and document history. All comments are subject to release under the Freedom of Information Act (FOIA).

NIST SP 800-70r5 ipd (Initial Public Draft) December 2025

National Checklist Program for IT Products: Guidelines for Checklist Users and Developers

Abstract

2 3 4 5 6 7 8 9 10 11

A security configuration checklist is a document or technical content that contains instructions or procedures for securely configuring an IT product to match an operational environment’s risk tolerance, verifying that the product has been configured properly, and/or identifying unauthorized changes to the product. Using these checklists can minimize the attack surface, reduce vulnerabilities, lessen the impact of successful attacks, and identify changes that might otherwise go undetected. NIST established the National Checklist Program (NCP) to facilitate the generation of security checklists from authoritative sources, centralize the location of checklists, and make checklists broadly accessible. This publication explains how to use the NCP to find and retrieve checklists and describes the policies, procedures, and general requirements for participation in the NCP.

Keywords

13 14 15

benchmark; change detection; checklist; information security; National Checklist Program (NCP); Security Automation; secure configuration; security configuration checklist; Security Content Automation Protocol (SCAP); software configuration; vulnerability.

Reports on Computer Systems Technology

17 18 19 20 21 22 23 24 25 26

The Information Technology Laboratory (ITL) at the National Institute of Standards and Technology (NIST) promotes the U.S. economy and public welfare by providing technical leadership for the Nation’s measurement and standards infrastructure. ITL develops tests, test methods, reference data, proof of concept implementations, and technical analyses to advance the development and productive use of information technology. ITL’s responsibilities include the development of management, administrative, technical, and physical standards and guidelines for the cost-effective security and privacy of other than national security-related information in federal information systems. The Special Publication 800-series reports on ITL’s research, guidelines, and outreach efforts in information system security, and its collaborative activities with industry, government, and academic organizations.

NIST SP 800-70r5 ipd (Initial Public Draft) December 2025

National Checklist Program for IT Products: Guidelines for Checklist Users and Developers

Document Conventions

29 30 31 32 33

This document was created for current and potential checklist developers and users in both the public and private sectors. Checklist developers include IT vendors, consortia, industry, government organizations, and others in the public and private sector. Checklist users include end users, system administrators, and IT managers within government agencies, corporations, small businesses, and other organizations, as well as private citizens.

34 35

It is assumed that readers of this document are familiar with general computer security concepts.

Trademark Information

37 38

All names are registered trademarks or trademarks of their respective companies, as denoted in this document.

NIST SP 800-70r5 ipd (Initial Public Draft) December 2025

National Checklist Program for IT Products: Guidelines for Checklist Users and Developers

Call for Patent Claims

41 42 43 44 45 46 47

This public review includes a call for information on essential patent claims (claims whose use would be required for compliance with the guidance or requirements in this Information Technology Laboratory (ITL) draft publication). Such guidance and/or requirements may be directly stated in this ITL Publication or by reference to another publication. This call also includes disclosure, where known, of the existence of pending U.S. or foreign patent applications relating to this ITL draft publication and of any relevant unexpired U.S. or foreign patents.

48 49

ITL may require from the patent holder, or a party authorized to make assurances on its behalf, in written or electronic form, either:

50 51

a) assurance in the form of a general disclaimer to the effect that such party does not hold and does not currently intend holding any essential patent claim(s); or

52 53 54

b) assurance that a license to such essential patent claim(s) will be made available to applicants desiring to utilize the license for the purpose of complying with the guidance or requirements in this ITL draft publication either:

55 56

under reasonable terms and conditions that are demonstrably free of any unfair discrimination; or

57 58

ii.

without compensation and under reasonable terms and conditions that are demonstrably free of any unfair discrimination.

59 60 61 62 63

Such assurance shall indicate that the patent holder (or third party authorized to make assurances on its behalf) will include in any documents transferring ownership of patents subject to the assurance, provisions sufficient to ensure that the commitments in the assurance are binding on the transferee, and that the transferee will similarly include appropriate provisions in the event of future transfers with the goal of binding each successor-in-interest.

64 65

The assurance shall also indicate that it is intended to be binding on successors-in-interest regardless of whether such provisions are included in the relevant transfer documents.

Such statements should be addressed to: checklists@nist.gov

iii

NIST SP 800-70r5 ipd (Initial Public Draft) December 2025

National Checklist Program for IT Products: Guidelines for Checklist Users and Developers

Table of Contents

Executive Summary............................................................................................................................1

1. Introduction ...................................................................................................................................2

71 72 73

2. NIST National Checklist Program .....................................................................................................7

74 75 76 77 78

3. Operational Environments for Checklists ......................................................................................11

79 80 81 82

3.3.1. Specialized Security-Limited Functionality Environment ........................................................... 12

3.3.2. Legacy Environment ................................................................................................................... 12

4. Checklist Usage ............................................................................................................................14

85 86 87 88 89 90

5. Checklist Development .................................................................................................................22

91 92 93 94 95 96 97 98 99 100 101

References.......................................................................................................................................29

102

Appendix A. Checklist Program Operational Procedures....................................................................30 iv

NIST SP 800-70r5 ipd (Initial Public Draft) December 2025

National Checklist Program for IT Products: Guidelines for Checklist Users and Developers

103 104 105 106 107 108 109

Appendix B. Participation and Logo Usage Agreement Form .............................................................36

110

Appendix C. Automating NIST CSF 2.0 ...............................................................................................39

111 112 113 114 115 116 117

Appendix D. List of Symbols, Abbreviations, and Acronyms...............................................................42

118

Appendix E. Glossary........................................................................................................................45

119

Appendix F. Change Log ...................................................................................................................48

120

List of Tables

121

Table 1. Checklist Description Form Fields ........................................................................................24

122

List of Figures

123

Fig. 1. Checklist user process overview .............................................................................................14

124 125

NIST SP 800-70r5 ipd (Initial Public Draft) December 2025

National Checklist Program for IT Products: Guidelines for Checklist Users and Developers

126

Executive Summary

127 128 129 130 131

A security configuration checklist (also called a lockdown, hardening guide, or benchmark) is a series of instructions or procedures for securely configuring an IT product to a particular risk tolerance for an operational environment, verifying that the product has been configured properly, and/or identifying unauthorized changes to the product. The checklist may be for a commercial, open-source, or government-off-the-shelf (GOTS) IT product.

132 133 134 135 136

Checklists can comprise a mix of templates, automated scripts, patch information, Extensible Markup Language (XML) files, and other procedures. Typically, checklists are created by IT vendors for their own products; however, checklists are also created by other organizations, such as academia, consortia, and government agencies. The use of well-written, standardized checklists can markedly reduce the attack surface and vulnerability exposure of IT products.

137 138 139 140 141 142 143

NIST maintains the National Checklist Repository, which is a publicly available resource of security configuration checklists for IT products. The repository is located at https://checklists.nist.gov/ and contains metadata describing each checklist. The repository links to the website where a checklist is hosted. Users can browse and search the repository to locate a particular checklist using a variety of criteria. Having a centralized checklist repository makes it easier for organizations to find current, authoritative versions of security checklists and to determine which ones best meet their needs.

144 145 146 147 148

This document is intended for users and developers of security configuration. For checklist users, this document makes recommendations on how they should select checklists from the NIST National Checklist Repository, evaluate and test checklists, and apply them to IT products. For checklist developers, this document sets forth the policies, procedures, and general requirements for participation in the NIST National Checklist Program (NCP).

149 150

Major recommendations made in this document for checklist users and developers include the following:

151 152 153

•

Organizations should apply checklists to operating systems and applications to reduce the number of vulnerabilities that attackers can attempt to exploit and to lessen the impact of successful attacks.

154 155

•

When selecting checklists, users should carefully consider each checklist’s degree of automation, source, use of standards, and other relevant characteristics.

156 157

•

Checklist users should customize and test checklists before applying them to production systems.

158 159

•

Checklist users should consider their operational environments when selecting checklists.,.

160 161

•

Checklist creators are encouraged to adopt a “catalog of controls” approach for products to facilitate custom checklist re-use.

162 163

•

NIST strongly encourages IT product vendors to develop security configuration checklists for their products and contribute them to the NIST National Checklist Repository. 1

NIST SP 800-70r5 ipd (Initial Public Draft) December 2025

National Checklist Program for IT Products: Guidelines for Checklist Users and Developers

164

1. Introduction

165 166 167 168 169 170 171 172 173

There are many threats to users’ computers, and new vulnerabilities in IT products (e.g., operating systems, applications) are discovered daily. Patches may not be immediately available for new vulnerabilities, causing the need to rapidly deploy temporary mitigations through product reconfiguration until patches are available. Moreover, restrictive security settings in IT products may be disabled by default to ensure maximum functionality and interoperability for a wide variety of users, which means that many IT products may be immediately vulnerable in their default configuration. It is a complicated, arduous, and timeconsuming task to define a reasonable set of security settings for IT products, even for experienced system administrators.

174 175 176 177

One simple yet effective tool is the security configuration checklist (also called a lockdown, hardening guide, or benchmark). NIST developed the NCP for IT products to facilitate the development of security configuration checklists and meet the requirements of the Cyber Security Research and Development Act of 2002 (Public Law 107-305) (CSRDA) [3].

178 179 180 181 182 183 184 185 186 187

There is no checklist that can make a system or product completely secure, and using a checklist does not eliminate the need for ongoing security maintenance, such as patch installation. However, using a checklist that emphasizes hardening systems against software flaws (e.g., by applying patches and eliminating unnecessary functionality) and securely configuring systems will typically reduce the number of ways in which the systems can be attacked, resulting in greater levels of product security and protection from future threats. Checklists can be particularly helpful to small organizations and individuals with limited resources for securing their systems. Organizations should use a risk-based approach, and checklists should be tailored by each organization to meet its particular security and operational requirements.

188

Mapping and Acquisition Considerations

189 190 191 192

Checklists can also verify the configuration state of technical security controls for system assessments, such as confirming compliance with certain Federal Information Security Modernization Act (FISMA) requirements, security frameworks (e.g., the NIST Cybersecurity Framework), and security controls.

193 194 195

According to the Federal Acquisition Regulation (FAR) Part 39, Federal agencies are required to use appropriate security configuration checklists from the NCP. Specifically, paragraph (c) of section 39.101 states,

196 197 198 199 200 201

In acquiring information technology, agencies shall include the appropriate information technology security policies and requirements, including use of common security configurations available from the National Institute of Standards and Technology’s website at https://checklists.nist.gov. Agency contracting officers should consult with the requiring official to ensure the appropriate standards are incorporated. [1]

202 203

FISMA also requires each federal agency to determine minimally acceptable system configuration requirements and ensure compliance with them [2]. Federal agencies and

NIST SP 800-70r5 ipd (Initial Public Draft) December 2025

National Checklist Program for IT Products: Guidelines for Checklist Users and Developers

204 205 206 207

vendors of products for the Federal Government should create and share checklists using the NCP. NIST encourages checklist developers to map the security controls delineated in NIST Special Publication (SP) 800-53 to IT product technical controls, which facilitates FISMA compliance checking for federal agencies. 1

208

Selecting Checklists

209 210

Organizations should consider and prioritize product selection based on the availability of security configuration checklists during their IT product selection processes.

211 212 213 214

Organizations are encouraged to tailor checklists to reflect their operational context and risk posture. Any deviation from checklist settings should be accompanied by a documented justification with risk acceptance, recognizing that checklists serve as guidance rather than a universal prescription.

215 216 217 218 219 220 221 222 223

NIST recognizes that some checklists are more automated and standards-based than others. For example, non-automated checklists provide prose-based descriptions of how a person can manually alter a product’s configuration, while automated checklists are generally machineexecutable. The NIST open-source macOS Security Compliance Project (mSCP) is an example of a well-automated checklist package that focuses on standards-based formats to provide security configuration guidance to organizations more quickly and in a machine-consumable format. The mSCP continuously curates and updates machine-consumable macOS guidance to address the continuous release cycle of the vendor. The latest macOS security baseline content is maintained and updated on the mSCP GitHub page.

224 225 226 227 228 229 230 231 232

Checklist developers, like the mSCP program, take a programmatic approach to generating and using security configuration baselines. Projects like these can be used to create customized security baselines of technical security controls by leveraging a library of rules that are each mapped to requirements in one or more existing security standards, regulations, or frameworks. This approach provides versioning, consistency, and the generation of checklists in standardized formats that are either native to the platform or in widely accepted security configuration standard formats. Unifying, standardizing, and updating security guidance is simplified and radically accelerated, even as new features and versions of the operating system or application are introduced.

233 234 235 236 237 238 239

Not all checklist generation requires this degree of programmatic sophistication. Automated checklists may be a Group Policy Object (GPO), stand-alone OVAL file, kickstart script, shell script, or simple utility that assesses the security settings on a system. No matter the format, developers of automated checklists are encouraged to use the constructs that are most germane to the platform being configured, be transparent regarding their methods, and assign Common Configuration Enumeration identifiers (CCEs) (i.e., globally unique identifiers) to their individual configuration settings.

240 241 242

Another example of an automated checklist is one that fully adheres to the Security Content Automation Protocol (SCAP). These checklists are often referred to as SCAP content and include mappings between low-level security settings and high-level security requirements. These 1 Organizations are also encouraged to include information in their checklists that supports mapping to other sets of requirements, such as the

Health Insurance Portability and Accountability Act (HIPAA).

NIST SP 800-70r5 ipd (Initial Public Draft) December 2025

243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271

National Checklist Program for IT Products: Guidelines for Checklist Users and Developers

checklists have undergone syntactic testing to ensure adherence to the SP 800-126 SCAP specification using the NIST SCAP Content Validation Tool (SCAPVal) located at GitHub usnistgov/scapval. o Automated checklists When multiple checklists are available for a particular product, organizations should consider the degree of automation and use of standards for each checklist. Generally, automated checklists can be used more consistently and efficiently than others. There may be other significant differences among checklists; for example, one checklist may include software bundled with an operating system (e.g., web browser, email client), while another addresses the operating system only. Another example is the assumptions on which the checklists are based (e.g., operational environment). A user should identify such differences and determine which checklists seem appropriate and merit further analysis. Checklists can be tailored to suit the risk tolerance of the environment in which they are used. o Government Checklist Precedence Checklist source is particularly important for users from federal civilian agencies, who should first search for government-authorized or mandated checklists (e.g., mandated by Part 39 of the FAR [1]). In general, these users should search for NIST-produced checklists, which are tailored for civilian agency use. If no NIST-produced checklist is available, then agency-produced checklists from the Defense Information Systems Agency (DISA), the National Security Agency (NSA), or the Cybersecurity and Infrastructure Security Agency (CISA) should be used. If formal government-authorized checklists do not exist, organizations are encouraged to use vendor-produced checklists. If vendor-produced checklists are not available, other checklists that are posted on the NCP website may be used. Although government-sourced checklists generally consider the necessary compliance criteria (e.g., use of FIPS-140 based encryption when encryption is necessary, access control criteria), they may need further tailoring to fit the specific operational and risk-based needs of the environment in which they are used.

272

Checklist Considerations

273 274 275 276 277 278 279 280 281 282 283

A checklist should be considered a starting point for an organization. Checklists should be customized to match an organization’s risk posture and requirements, including specific deviations with documented justifications, risk acceptance, and compensating controls. Checklist settings are recommended to prevent security threats and vulnerabilities, but they cannot address organization-specific security and operational requirements and the presence of existing security controls and other factors that may necessitate changes to an organizational checklist. Organizations should carefully evaluate the checklist settings and then make any changes necessary to adapt the settings to the organization’s environment, requirements, policies, risk tolerance, and security objectives. This is particularly true for checklists that are intended for an environment with significantly different security needs. For example, producers of checklists in the military can harmonize on the specific types of hardware and software used

NIST SP 800-70r5 ipd (Initial Public Draft) December 2025

National Checklist Program for IT Products: Guidelines for Checklist Users and Developers

284 285 286 287 288 289 290

in their environment, which can allow for more stringent settings. These security configuration settings generally represent a high-water mark rather than a baseline for civilian agencies attempting to use this guidance. The wholesale adoption of a high-water mark in a civilian environment may lead to unintended consequences, and each setting should be specifically tested and validated before widescale deployment. All deviations from the checklist settings should be documented for future reference and include the reason behind each deviation and the impact of deviating from the setting.

291 292 293 294 295 296

All checklists should be tested in non-production environments before use in production environments. Each checklist in the NIST repository has been tested by its developer, but there are often significant differences between a developer’s testing environment and an organization’s operational environment. Security control modification can negatively impact a product’s functionality, usability, and security controls. Testing and documentation can help organizations address significant issues.

297 298 299 300 301 302 303

Checklists are significantly more useful when they can run in common operational environments. The NCP has identified several broad and specialized operational environments (e.g., Stand-Alone, Managed), and at least one of the environments should be common to most audiences. Thoroughly identifying and describing these environments will make it easier for users to select the security checklists that are most appropriate for their operating environments and enable developers to better target their checklists to the general security characteristics associated with their operating environments.

304 305 306 307 308 309 310 311 312 313

Organizations that create content, particularly security baselines, should adopt a risk-based approach for selecting the appropriate settings and defining values that consider the context under which the baseline will be utilized. Checklist content can leverage a library of rules that are each mapped to requirements in one or more existing security standards, regulations, or frameworks to create multiple customized security baselines. This approach provides versioning and consistency of the content. Generally, the technical security settings in products do not drastically change between releases. By pursuing a rules-based approach, rules that remain applicable can be reused and incorporated into guidance for the latest release. This enables quicker adoption of new security features that are not offered in prior versions. Settings that are no longer applicable can be retired by specifying a maximum version.2

314 315 316

NIST encourages IT product vendors to develop security configuration checklists for their products, since vendors have the most expertise on possible security configuration settings and their relationships.

317 318 319 320 321 322

Vendors that create security configuration checklists should submit them for inclusion in the National Checklist Repository through the NCP. The NCP provides a 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 NCP, and submitting a checklist package to NIST. NIST then screens the checklist according to program requirements and releases the checklist for a 30-day public 2 The mSCP is an open-source project that provides a programmatic approach to generating and using macOS security configuration baselines that adopt this recommendation.

NIST SP 800-70r5 ipd (Initial Public Draft) December 2025

National Checklist Program for IT Products: Guidelines for Checklist Users and Developers

323 324 325 326

review. After the public review period and subsequent resolution of issues, the checklist is listed on the NIST checklist repository with its information. Checklist maintenance may potentially be performed by the vendor, resulting in the release of updated checklists. NIST retires or archives checklists as they become outdated or incorrect.

327

1.1. Purpose and Scope

328 329 330

This document describes the use, benefits, and management of checklists and checklist control catalogs as well as the policies, procedures, and general requirements for participation in the NIST National Checklist Program (NCP).

331

1.2. Document Organization

332

Section 2 provides an overview of checklists and the advantages of the NCP.

333 334 335 336

Section 3 provides additional details on predefined checklist operational environments that are used in the NCP to help developers create checklists that are consistent with security practices. The material presented in Sec. 3 can also help checklist users select the checklists that best match their own operational environments.

337 338 339 340

Section 4 contains information for potential checklist users. It describes how to use the NCP to find and retrieve checklists that best match their identified needs. It also provides guidance on how to implement checklists, including how to analyze the specific operating environment and then tailor checklists as applicable.

341 342 343

Section 5 provides guidance for current and prospective checklist developers, including procedures for preparing and submitting a checklist to NIST for inclusion in the checklist repository.

344

The 29 section lists the documents cited throughout this document.

345 346

Appendix A describes the programmatic and legal requirements that must be satisfied to participate in the NCP.

347

Appendix B provides the NCP participation and logo usage agreement form.

348

Appendix C contains steps for automating the frameworks with checklists.

349

Appendix D lists the acronyms used in this document.

350

Appendix E presents a glossary of the terms used in this document.

351 352

Appendix F provides a log of changes made since the last version of this document was published.

353

NIST SP 800-70r5 ipd (Initial Public Draft) December 2025

National Checklist Program for IT Products: Guidelines for Checklist Users and Developers

354

2. NIST National Checklist Program

355 356

This section provides an overview of the NCP and the contents of security configuration checklists, which improve the base level of security for an organization.

357

2.1. Overview of the NCP

358 359 360 361 362

Organizational checklists can vary widely in terms of purpose, quality, usability, and the level of security they provide. They may also become outdated as software updates and upgrades are released. Without a central checklist repository, finding security checklists can be difficult. NIST established the NCP to facilitate the development of security checklists for IT products and to make checklists more organized and usable. The NCP’s broad goals are to:

363 364

•

Facilitate the development and sharing of checklists by providing a formal framework for vendors and other checklist developers to submit checklists to NIST

365 366

•

Provide guidance to developers to help them create standardized, high-quality checklists that conform to common operational environments

367

•

Help developers and users by providing guidelines for documentation and usability

368

•

Encourage software vendors and other parties to develop checklists

369

•

Provide a managed process for the reviewing, updating, and maintaining checklists

370

•

Provide an easy-to-use repository of checklist information

371

•

Provide checklist content in a standardized format

372

•

Encourage the use of automation technologies for applying checklists.

373 374 375 376 377 378 379 380 381 382

Federal agencies are required to use security configuration checklists from the NCP when available. In January 2017, Part 39 of the Federal Acquisition Regulation (FAR) was updated. Paragraph (c) of section 39.101 states, In acquiring information technology, agencies shall include the appropriate information technology security policies and requirements, including use of common security configurations available from the National Institute of Standards and Technology’s website at https://checklists.nist.gov. Agency contracting officers should consult with the requiring official to ensure the appropriate standards are incorporated. [1]

383

2.2. Security Configuration Checklists

384 385

A security configuration checklist 3 (or simply, “checklist”) is a document that contains instructions, procedures, or machine-automated content to configure an IT product to a specific 3 This may also be referred to as a lockdown guide, a hardening guide, a security guide, secure configuration, security technical implementation

guide (STIG), or a benchmark.

NIST SP 800-70r5 ipd (Initial Public Draft) December 2025

National Checklist Program for IT Products: Guidelines for Checklist Users and Developers

386 387 388 389

risk posture for an operational environment, verify that the product has been configured properly, identify unauthorized configuration changes to the product, and/or produce artifacts showing the security posture of the product. The IT product may be commercial, open source, government-off-the-shelf (GOTS), or developed in-house.

390 391 392 393

Using well-written, standardized configuration checklists can reduce the vulnerability exposure of IT products and help secure systems. Checklists can be developed by IT vendors and other organizations with technical competence in IT product security. A security configuration checklist might include any of the following:

394 395

•

Automated content that sets or verifies security-related settings (e.g., executables, scripts, security templates, SCAP XML files) 4

396

•

Documentation that guides the checklist user to manually configure an IT product

397 398

•

Documents that explain the recommended methods to securely install and configure a device

399 400 401

•

Rule files that use policy and programmatic documents to define recommended settings for technical controls, such as auditing, authentication mechanisms (e.g., multi-factor authentication, passwords), and firewall security

402 403 404

Not all instructions in a security configuration checklist need to solely address security settings. Checklists can also include administrative practices, such as enabling energy-saving features or specialized security functions (e.g., looking for indicators of compromised artifacts on a host).

405 406 407 408 409 410

Typically, a checklist is deployed as part of enterprise management to apply settings across all systems. When done manually, a system administrator or end user follows the instructions in the checklist to configure or verify that a product or system has implemented the security controls in the checklist. Through enterprise or local implementation, the system administrator may need to include modifications or deviations to the checklist to ensure that the local security policy enables the risk posture needed for the purpose of the device.

411

Security checklists are intended for a variety of devices and software, including:

412

•

General-purpose operating systems and mobile operating systems

413 414

•

Common applications, such as email clients, web browsers, word processors, personal firewalls, and antivirus software

415 416 417 418

•

Infrastructure devices, such as software-as-a-service (SaaS) providers, infrastructure-asa-service (IaaS) providers, platform-as-a-service (PaaS) providers, virtualization platforms, routers, switches, firewalls, virtual private network (VPN) gateways, intrusion detection systems (IDSs), wireless access points, and telecommunication systems

419 420 421

•

Application servers, such as Domain Name System (DNS), Dynamic Host Configuration Protocol (DHCP), proxy and web servers, Simple Mail Transfer Protocol (SMTP), and database servers

4 More information about SCAP can be found at https://scap.nist.gov/ and SP 800-126 [4].

NIST SP 800-70r5 ipd (Initial Public Draft) December 2025

National Checklist Program for IT Products: Guidelines for Checklist Users and Developers

422 423

•

Other network devices, such as Internet of Things (IoT) devices, scanners, printers, and copiers

424 425

•

Artificial intelligence (AI) systems, including hardware and software components comprising the stack

426

2.3. Benefits of Using Security Checklists

427 428 429 430 431 432

Security checklists help users configure IT products securely so that they have more protection than default settings. Applying checklists to operating systems and applications can reduce the number of vulnerabilities that attackers attempt to exploit and lessen the impacts of successful attacks. Using checklists improves the consistency and predictability of system security, particularly in conjunction with user training and awareness activities and other supporting security controls. Additional benefits associated with using checklists include:

433 434

•

Providing a base level of security to protect against common local and remote threats (e.g., malware, denial-of-service attacks, unauthorized access, inappropriate usage)

435 436 437 438

•

Verifying the configuration of technical security controls specified by the checklist for system assessments, such as confirming compliance with certain Federal Information Security Modernization Act (FISMA) requirements, and understanding the exposure caused by misconfigurations

439 440 441

•

Providing artifacts of compliance from the verified implementation of controls at the endpoint to support a near real-time understanding of technical security posture and risk

442 443 444

•

Creating catalogs of product technical controls, which significantly reduces the time required to research and develop appropriate security configurations for installed IT products

445 446

•

Allowing smaller organizations to implement recommended practice security configurations

447 448

•

Reducing the likelihood of public loss of confidence or embarrassment resulting from a compromise of systems (e.g., a major breach of personally identifiable information [PII])

449 450 451 452 453 454 455

Using security checklists for security compliance purposes can significantly improve overall levels of security in organizations, but using a checklist cannot make a system or product completely secure. Using checklists that emphasize the hardening of systems will typically result in greater levels of product security and potential protection from future threats (e.g., zero-day vulnerabilities). IT vendors that configure their products using checklists that adhere to the FISMA-associated security control requirements5 will provide more consistency in configuration settings within federal agencies. Applying checklists establishes minimum configuration

5 See the NIST Cybersecurity and Privacy Reference Tool at

https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_2_0/home.

NIST SP 800-70r5 ipd (Initial Public Draft) December 2025

National Checklist Program for IT Products: Guidelines for Checklist Users and Developers

456 457

settings, even if the agencies must tailor the checklists for their specific risk tolerances and operational environments.

458

2.4. Types of Checklists Listed by NCP

459 460 461 462 463

The NCP deals with checklists that are tied to specific IT products, such as a checklist for a specific operating system version. Some checklists may also incorporate the use of other checklists. For example, a checklist for a database product may reference a checklist for the operating system on which the database product runs. The NCP includes two major groups of checklists:

464 465 466 467

•

Automated. An automated checklist is machine-executable and usable by one or more tools that automatically alter or verify settings based on the contents of the checklist. Checklists can be written in product-native scripting languages, such as shell scripts, PowerShell, Group Policy Objects, Jumpstart scripts, XML, and others.

468 469 470

•

Non-automated. As the name implies, a non-automated checklist is one that is designed to be used manually, such as prose instructions that describe the steps an administrator should take to secure a system or verify its security settings.

471 472 473 474 475 476 477 478 479

Security configuration checklists in the NCP can help organizations comply with FISMA, which requires federal agencies to determine minimally acceptable system configuration requirements and ensure compliance with them. Checklists can also map specific technical control settings to the corresponding SP 800-53 controls and other existing security standards, regulations, or frameworks, which makes the verification of compliance more consistent and efficient. Federal agencies and vendors of products for the Federal Government are encouraged to develop and share such checklists using the NIST repository. This helps reduce silos of effort to identify sufficiently secure settings for IT products that are widely used in the Federal Government, such as common operating systems, servers, and client applications.

480 481 482 483 484 485

The NIST checklist repository (located at https://checklists.nist.gov/) provides information on automated and non-automated checklists that have been developed and screened to meet the requirements of the NCP. The repository hosts copies of checklists, primarily those developed by the Federal Government, and points to other submitted checklist locations. Users can browse checklist descriptions to locate and retrieve a particular checklist using a variety of different fields.

NIST SP 800-70r5 ipd (Initial Public Draft) December 2025

National Checklist Program for IT Products: Guidelines for Checklist Users and Developers

486

3. Operational Environments for Checklists

487 488 489 490 491 492 493

To ensure that as many users as possible receive value from checklists, authors should create catalogs of controls from which checklists can be generated for specific operational environments and risk postures. The NCP identifies several broad and specialized operational environments, at least one of which should be common to most audiences. Identifying and describing these environments allows developers to better target their checklists to the general security requirements and risk postures of those environments and allows end users to select the most appropriate checklists.

494 495 496 497 498

This section describes the operational environments defined for the NCP and the general threat description and fundamental technical security practices for each environment. The two broad operational environments are referred to as Stand-Alone (or small office/home office [SOHO]) and Managed (or Enterprise). Three typical Custom environments that could be subsets of the broader environments are Specialized Security-Limited Functionality (SSLF) and Legacy.

499 500 501 502 503 504 505 506

IT product users may find it useful to consult this section of the document when initially identifying their own security requirements and needs (see Sec. 4). Developers may find this section useful when building and tailoring security compliance checklists for diverse products while still adhering to the uniform technical security practices and settings associated with the environments (see Sec. 5). Before submitting a checklist to NIST, developers should ensure that they have the most recent version of this document because updates to the criteria for operational environments may occur periodically. The most recent version is available as a separate file at https://checklists.nist.gov/.6

507

3.1. Stand-Alone Environment

508 509 510 511 512

The Stand-Alone environment describes individually managed devices (e.g., desktops, laptops, smartphones, tablets). It focuses on functionality and are typically the least secure. Stand-Alone checklists should be relatively simple for home users or novice system administrators to understand and implement. They are an entry point to defining a configuration for reuse across a handful of systems and improving from the base vendor security posture.

513

3.2. Managed Environment (Enterprise)

514 515 516 517 518

The Managed environment (also referred to as Enterprise) is based on centrally managed IT products and devices (i.e., many devices managed by a single organization), including cloud SaaS providers, IaaS providers, PaaS providers, virtualization platforms, servers, desktops, laptops, smartphones, tablets, and IoT. The Managed environment provides more security but less functionality than the Stand-Alone environment.7 It also tends to implement several layers 6 As new information becomes available, NIST may update the criteria and information for the operational environments as well as other criteria contained in this document. 7 Checklists should be customized within Managed environments to meet organizational risk tolerance and requirements (regulatory, security standards and frameworks). For example, making exceptions for groups of users (or devices) with a specific need to deviate from a checklist setting or settings, rather than deviating the setting across the entire enterprise. Tailored deviations, based on documented justification of the needs of a subset of users (or devices) is preferred to preventing users from performing their duties as long as the risk is accepted by an authorizing official.

NIST SP 800-70r5 ipd (Initial Public Draft) December 2025

National Checklist Program for IT Products: Guidelines for Checklist Users and Developers

519 520

of defense (e.g., firewalls, endpoint detection and response, automated patch management systems, email protections).

521 522 523 524

Managed checklists are intended for advanced end users and system administrators. The nature of a typical Managed environments gives administrators centralized control over settings on devices. Authentication, account, and policy management can be administered centrally to maintain a consistent security posture across an organization.

525

3.3. Custom Environments

526 527 528

A Custom environment contains systems in which the functionality and degree of security do not fit the other types of environments. There are typically two types: Specialized SecurityLimited Functionality (SSLF) and Legacy.

529

3.3.1. Specialized Security-Limited Functionality Environment

530 531 532 533 534 535 536 537 538 539 540

SSLF is a Custom environment that is highly restrictive, secure, and usually reserved for systems with the highest threats and associated impacts, such as outward-facing web servers, other publicly accessed systems, and firewalls. It also encompasses computers that contain confidential information (e.g., central repository of personnel records, medical records, or financial information) or that perform vital organizational functions (e.g., accounting, payroll processing, air traffic control). These systems might be targeted by third parties for exploitation or by trusted parties inside of the organization. Because systems in an SSLF environment are at high risk of attack and data exposure, security takes precedence over functionality. The system’s 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.

541 542 543 544 545 546

An SSLF environment could also be a subset of another environment. For example, three desktops in a Managed environment that hold the organization’s confidential employee data could be thought of as an SSLF environment within a Managed environment. In addition, a laptop used by a mobile worker might be an SSLF environment in a Stand-Alone environment. An SSLF environment might also be a self-contained environment outside of any other environment, such as a government security installation that processes sensitive data.

547 548 549 550 551

SSLF checklists are intended for experienced security specialists and system administrators who understand the impact of implementing strict technical security practices. If home users and other users who do not have security expertise attempt to apply SSLF checklists to their systems, they may experience unwanted limitations on system functionality and potentially cause irreparable system damage.

552

3.3.2. Legacy Environment

553 554 555

A Legacy environment is another example of a Custom environment and contains older systems or applications that are unable to be secured against modern threats. They often use older, less secure communication mechanisms that cannot be patched but need to be able to 12

NIST SP 800-70r5 ipd (Initial Public Draft) December 2025

556 557 558 559

National Checklist Program for IT Products: Guidelines for Checklist Users and Developers

communicate with other systems. Non-legacy systems operating in a Legacy environment may need less restrictive security settings so that they can communicate with Legacy systems and applications. They require significant compensating and mitigating controls for ongoing use. Legacy environments may also be subsets of other environments.

560

NIST SP 800-70r5 ipd (Initial Public Draft) December 2025

National Checklist Program for IT Products: Guidelines for Checklist Users and Developers

561

4. Checklist Usage

562 563 564 565 566 567 568

This section describes a high-level process for retrieving and using checklists. Although all checklist users have their own specific requirements, the process described will apply to most situations. This section includes guidance on conducting an initial analysis of local environment threats and risks and lists the potential impacts of such attacks. It also describes a process for selecting and retrieving checklists through the NIST checklist repository and recommends steps for analyzing, tailoring, and applying the checklist. Figure 1 shows the general process for using checklists.

569 570

Fig. 1. Checklist user process overview

571

The general steps involved in acquiring and using checklists are:

572 573 574

1. Users gather their local requirements (e.g., IT products, the operating environment, associated security needs) and then acquire or purchase the IT product that best suits their needs.

575 576 577

2. Users browse the checklist repository to retrieve checklists that match their operational environment and security requirements. If a product is intended to be secure by default, it is still important to check the NIST checklist repository for updates to that checklist.

578 579 580 581

3. Users review the checklists and select one that best meets their requirements. They then tailor and document the checklist as necessary to consider local policies and functional requirements, test the checklist on a non-production system, and provide feedback to NIST and checklist developers.

NIST SP 800-70r5 ipd (Initial Public Draft) December 2025

582 583

National Checklist Program for IT Products: Guidelines for Checklist Users and Developers

4. Users prepare to deploy the checklist (e.g., make configuration or data backups) and then apply the checklist in production.

584

The following sections detail the activities included in each of these steps.

585

4.1. Determining Local Requirements

586 587 588 589 590

Organizations usually conduct a requirements analysis before selecting and purchasing a particular IT product. Such an analysis would include identifying the needs of the organization (i.e., what the product must do) and the security requirements for the product (e.g., relevant security policies or regulations). It is best to assess requirements early in the process of incorporating security into IT operations, regardless of size.

591 592 593 594 595 596 597 598 599

When planning security, it is essential to first define the threats that must be mitigated. Organizations that use checklists should conduct risk assessments to identify the specific threats against their systems, determine the effectiveness of existing security controls in counteracting those threats, and perform risk mitigation to decide whether any additional measures should be implemented, as discussed in SP 800-37r1 [6]. Performing risk assessments and mitigation helps organizations better understand their needs and decide whether they need to modify or enhance selected checklists. Tailoring for specific users or devices may be required to facilitate work across the organization, such as different settings for developers, kiosks, and specialty devices.

600

The risk mitigation methodology includes the following simple steps:

601 602 603 604

•

Identify functional needs. What must the product do? Identifying the end user’s requirements (e.g., remote access for telecommuters, a web server to make internal information available to employees) is necessary to ensure that the security solution and controls allow the system to meet its functional requirements.

605 606 607 608 609

•

Identify threats and vulnerabilities. A threat is the potential for a particular threat source to successfully exploit an information system vulnerability. A vulnerability is a weakness that can be intentionally exploited or accidentally triggered. The goal of this step is to identify potential threat sources that are applicable to the IT product or system as well as vulnerabilities that could be exploited by the potential threat sources.

610 611 612 613 614

•

Identify security needs. The goal of this step is to determine the controls needed to minimize or eliminate the likelihood (or probability) of a threat exploiting a product or system vulnerability. It answers the question, “What security features must the product provide?” Armed with this information, the organization can make wiser choices about which IT product best meets its needs.

615 616 617 618

NIST has written several documents and guides to help federal agencies select, acquire, and use information security products. Additionally, the Cybersecurity and Privacy Platform (CPP)8 provides a search engine for identified application, system, and vendor vulnerabilities and information on patches or fixes that are available to correct the vulnerabilities. 8 See https://nvd.nist.gov/.

NIST SP 800-70r5 ipd (Initial Public Draft) December 2025

National Checklist Program for IT Products: Guidelines for Checklist Users and Developers

619

4.2. Browsing and Retrieving Checklists

620 621 622 623 624 625 626 627 628 629

After determining local requirements and identifying an IT product, a checklist user is ready to browse the NIST checklist repository. The checklists are categorized by content type (i.e., degree of automation and standardization) and authority (i.e., the organization responsible for producing the original security configuration guidance represented by the checklist). Users can browse the checklists based on the content type, IT product, or authority and through a keyword search of the checklist name and summary for user-specified terms. The search results show the detailed checklist information and link to content and any supporting resources associated with the checklist. Selecting a particular checklist will show a description template that includes extensive information to help users decide whether the checklist will suit their specific purposes.

630 631 632 633 634 635 636 637

Some checklists address more than one application or operating system, such as several products from a single organization. To help users navigate the site from the checklist detail page, there is a Checklist Group link that represents the grouping of checklists based on a common source material. For example, the Defense Information Systems Agency (DISA) Office 365 Checklist contains configuration settings for multiple products, including desktop publishing and email applications. The NCP decomposes the checklist information according to these individual targets but keeps them conveniently linked to the same source document via the Checklist Group.

638 639 640 641 642 643 644

In some cases, multiple checklists are available for a particular version of a product. Such checklists are often similar, but they have important differences, such as the degree of automation provided, the intended audience (e.g., providing general recommendations versus complying with federal agency-specific requirements), and the checklist purpose (e.g., reconfiguring a product versus identifying a successful compromise of the product). To help users identify major differences among checklists, NIST has categorized checklists by content type, such as:

645 646

•

Prose. Prose checklists provide narrative descriptions of how a person can manually alter a product’s configuration.

647 648 649

•

Automated. Automated checklists document their security settings in a standard or proprietary machine-readable format, such as shell scripts, Group Policy Objects (GPOs), SCAP content, kickstart files, .inf files, executables, and XCCDF files.

650 651 652 653 654 655

A standards-based example of an automated checklist includes SCAP. SCAP checklists adhere to the SCAP specification detailed in the SP 800-126 for documenting security settings in machine-readable standardized SCAP formats. SCAP content that is available on the National Checklist Program repository has been evaluated with the NIST SCAP Content Validation Tool (SCAPVal). 9 This evaluation ensures that the checklist conforms to the SCAP specification. The SCAPVal tool does not evaluate the checklist for logic

9 SCAPVal is available for download for each SCAP version on the SCAP specification website at https://scap.nist.gov/revision/index.html. This

tool validates the correctness of the SCAP data stream according to the SCAP version specified in the corresponding version of SP 800-126 [4].

NIST SP 800-70r5 ipd (Initial Public Draft) December 2025

National Checklist Program for IT Products: Guidelines for Checklist Users and Developers

656 657

errors, such as the use of an “equal to” operator when “equal to or greater than” should have been used.

658 659 660 661 662 663 664 665 666 667 668 669

An example of a comprehensive checklist-generating package is the mSCP content hosted on the NIST NCP, which uses a catalog of controls approach to checklist generation. This approach is used by the mSCP to curate a library of rules with each rule mapped to requirements in one or more existing security standards, regulations, or frameworks. The rule library can be used to create multiple customized security baselines by leveraging the technical security controls and settings that do not drastically change from release to release. By pursuing a rules-based approach, rules that remain applicable can be reused and incorporated into guidance for the newest product version. This enables quicker adoption of new security features that are not offered in prior versions. mSCP allows a user to create a checklist in various machinereadable formats, including shell scripts and SCAP based on the policies and requirements selected.

670 671 672 673 674 675 676 677 678 679 680

When multiple checklists are available for a particular product, organizations should consider the degree of automation and standards in each checklist. Generally, automated checklists or checklists generated from a technical rules library can be used more consistently and efficiently than others. There may be other significant differences among checklists. For example, one checklist may include software bundled with an operating system (e.g., web browser and email client), while another checklist addresses that operating system only. Another example is the assumptions on which the checklists are based (e.g., operational environment and risk tolerance). A checklist user should identify such differences and determine which checklists seem appropriate and merit further analysis. Checklists should also be evaluated as a starting point for tailoring to match their operating environment and risk tolerance (e.g., a civilian government baseline versus a military baseline).

681 682 683 684 685 686 687

Users from federal civilian agencies should first search for government-authorized or mandated checklists, such as NIST-produced checklists that are tailored for civilian agencies. If no NISTproduced checklist is available, then agency-produced checklists from DISA, the National Security Agency (NSA), or CISA should be used, if available. If formal government-authorized checklists do not exist, organizations are encouraged to use vendor-produced checklists. If vendor-produced checklists are not available, other checklists that are posted on the NCP website may be used.

688 689 690 691 692 693 694 695 696 697

Organizations often submit checklists with associated alphanumeric version identifiers (e.g., R1.2.0). Unfortunately, these identifiers do not have universal meanings. Some organizations may change the version number when new checks are added, old technology is deleted, patches are added, or simply based on a review date. Conversely, other organizations may update their checklist and not change the version numbers. To clarify updates to checklists, NCP uses Checklist Revisions to indicate that something has changed, even if the version identifier did not change. For example, if the organization does not change the version number on the document, but the content has been updated (e.g., patches were added for a given month), the current checklist will be listed as archived and the checklist with the updated patch content will show as the current checklist. Likewise, if the submitting organization updates the version

NIST SP 800-70r5 ipd (Initial Public Draft) December 2025

National Checklist Program for IT Products: Guidelines for Checklist Users and Developers

698 699 700

identifier, then the NCP will list the current checklist as archived and link to the new checklist. From the checklist detail page, a user can navigate to the checklist history via the “Archived Revisions” link.

701

4.3. Reviewing, Customizing, Documenting, and Testing Checklists

702 703 704 705 706

Checklist users should download all documentation for the checklist and review it carefully. The documentation should explain any required preparatory activities, such as backing up a system. Because a checklist may not exactly match a user’s specific requirements, reviewing a checklist is useful in determining whether the checklist may need to be tailored 10 and whether the system or product will require further changes after applying the checklist.

707 708 709 710 711 712 713 714 715 716 717 718 719

The user’s review can identify the impact on an organization’s current policies and practices if a given security checklist is used. An organization may determine that some aspects of the checklist do not conform to certain organization-specific security and operational needs and requirements. Organizations should carefully evaluate the checklist settings and give them considerable weight, then make any changes necessary to adapt the settings to the organization’s environment, requirements, policies, and security objectives. This is particularly true for checklists that are intended for an environment with significantly different security needs. Organizations should tailor the checklists to reflect local rules, regulations, and mandates; for example, federal civilian agencies would need to ensure that checklists reflect compliance with encryption requirements in Federal Information Processing Standards Publication (FIPS) 140, Security Requirements for Cryptographic Modules. Because the checklist may be used many times within the organization, the checklist itself might need to be modified. This is especially likely if the checklist includes a script or template to be applied to systems.

720 721 722 723 724 725 726

At this point, all deviations from the settings in the checklist should be documented for future reference. The documentation should include the justification behind each deviation, including the impact of retaining the setting and the impact of deviating from the setting. This documentation helps in managing changes to the checklist over the life cycle of the product being secured. Feedback on the checklist can be sent to NIST and the checklist developers. Feedback is especially important to developers in gauging whether the checklist is well-written and the settings are applicable to the targeted environment.

727 728 729 730 731 732 733 734 735

Before applying a checklist that will be used to alter product settings, users should first test it on non-production systems, preferably in a controlled non-operational or virtual environment. Each checklist in the NIST checklist repository has been tested by its developer, but there are often significant differences between a developer’s testing environment and an organization’s operational environment that may affect checklist deployment and impact systems. The testing configuration of the IT product should match the deployment configuration. Security control modification can have a negative impact on a product’s functionality and usability, other products, and interactions with other security controls. For example, installing a patch could inadvertently break another patch, or enabling a firewall could inadvertently block software 10 If multiple checklists are available for the same product, the checklist user should compare the settings or steps in the selected checklist to see which settings or steps differ to determine if these alternate recommendations should be used.

NIST SP 800-70r5 ipd (Initial Public Draft) December 2025

National Checklist Program for IT Products: Guidelines for Checklist Users and Developers

736 737 738 739 740

from updating or disrupt patch management software. It is important to perform testing to determine the impact on system security, functionality, and usability; to document the results of testing; and to take appropriate steps to address any significant issues. Section 4.4 contains recommendations for performing backups and other suggestions to prevent or recover from potential damage or unwanted effects that could occur when applying an untested checklist.

741 742 743 744 745 746

Before using a checklist to verify product settings without altering them, users should test. If the checklist is automated, users should also test the tool or tools that will be used with the checklist to ensure that they do not inadvertently disrupt the functionality of the system or alter the configuration of the product. Checklist testing should be performed to identify discrepancies between the expected and actual settings, which could indicate errors in the checklist, such as environment-specific characteristics for which the checklist was not modified.

747

4.4. Applying Checklists to IT Products

748 749

A checklist can be applied to an IT product in one of two ways: modifying the product’s settings or verifying the existing settings.

750

•

Setting Modification

751 752

o Even after reviewing and testing a checklist, users should handle deployment carefully to minimize any issues that might arise from applying the checklist.

753 754 755 756 757 758 759 760

o For users who are unable to test a checklist in a non-operational environment (e.g., home users), it is important to carefully review the checklist documentation and determine whether an initial backup is required. The Rollback Capability field in the checklist description will indicate whether the results of applying the checklist can be reversed to return the product to its original configuration. Regardless of this setting, it is strongly recommended that a user back up the IT product’s configuration before installing the checklist recommendations.

761 762 763 764 765 766 767

o At a minimum, users should back up all critical data files in their computing environment. If possible, the user should make a full backup of the system to ensure that it can be restored to its pre-checklist state if necessary.11 Large organizations should also follow this procedure. If possible, use a test system to validate the impact of the checklist in the operational environment. After all pilot deployment groups are complete with a cooling off period to assess residual impact reports, deploy the settings enterprise-wide.

768 769 770 771 772

•

Setting Verification o Even after reviewing and testing a checklist, users should handle verification carefully to ensure that product settings are not inadvertently altered.

After initially applying a checklist, an organization may need to acquire and apply revised versions of the checklist in the future. Depending on the product being secured, a checklist may 11 Making a full backup is recommended before making any major system change, not only when implementing a checklist.

NIST SP 800-70r5 ipd (Initial Public Draft) December 2025

National Checklist Program for IT Products: Guidelines for Checklist Users and Developers

773 774 775 776 777 778

be updated periodically based on a set schedule or updated as needed, frequently or infrequently. An organization that acquires an updated checklist would perform the same steps already described in this section while taking advantage of knowledge gained and documented from applying previous versions of the checklist. Checklist versions should be compared against each other to find the delta in the configuration settings. Assess the risk of those changes to the existing deployment and any sets of small group deviations applied within the environment.

779

4.5. Providing Feedback on Checklists

780 781 782

NIST welcomes all “bug” reports, comments, and suggestions from checklist users regarding individual checklists or the repository itself. Such feedback should be directed to checklists@nist.gov. 12

783 784

Some of the questions that checklist users may want to consider when evaluating a checklist include the following:

785

•

Documentation

786

o Does it explain the security objectives?

787 788

o Does it contain a complete, clear, and concise description of the checklist settings?

789

•

Recommended Practices

790

o Are the checklist settings consistent with recommended practices?

791

o Do the checklist settings consider recent vulnerabilities?

792

•

Impact of Settings

793 794 795

o Has the checklist developer tested the checklist settings on the product in an operationally realistic environment and determined that the application of the checklist meets the security objectives of the checklist?

796 797

o Do any of the checklist settings cause the product to become inoperable or unstable?

798 799

o Do any of the checklist settings reduce product functionality? If so, is this documented?

800

•

Ease of Implementation

801

o Is the checklist straightforward to apply?

802

o Are the instructions concise, sound, and complete?

803

o Is the required skill level identified?

804

o Are there procedures to verify that the installation was successful? 12 Checklist users who want to publish their own version of a checklist may act in a checklist developer role and submit it to the NIST checklist repository, provided that there are no intellectual property restrictions on the original checklist.

NIST SP 800-70r5 ipd (Initial Public Draft) December 2025

National Checklist Program for IT Products: Guidelines for Checklist Users and Developers

805 806

o Is there guidance for uninstalling the checklist or restoring the product to the state before installation?

807 808

o If the checklist cannot be rolled back, does the documentation recommend other preparatory measures, such as backups?

809

•

Assistance

810

o Is checklist-related help available?

811

o Is there a repository or website for the checklist?

812 813

o Does the documentation contain information for troubleshooting if errors occur or if the checklist settings cause the product to operate incorrectly?

814

o Is assistance available for qualified users of the product?

815 816 817

o If the checklist developer is NOT the IT product’s vendor, does the documentation indicate whether the checklist has been sponsored or endorsed by the IT product’s vendor?

818

NIST SP 800-70r5 ipd (Initial Public Draft) December 2025

National Checklist Program for IT Products: Guidelines for Checklist Users and Developers

819

5. Checklist Development

820 821 822 823 824 825 826

This section describes the general process for developing security configuration checklists and submitting them to the NCP. It includes an overview of the process that NIST will follow to screen the checklist submissions, and publish them in its repository, and update or to archive the checklist. The appendices of this document provide administrative requirements for participation in the NCP. Before submitting a checklist to NIST, developers should ensure that they have the most recent version of this document, which is available as a separate file at https://nvd.nist.gov/ncp/participation.

827

The checklist life cycle comprises the following steps:

828 829 830

1. Initial Checklist Development: The developer 13 becomes familiar with the procedures and requirements of the checklist program and develops an initial version of the checklist, including selection of a target environment.

831 832

2. Checklist Testing: Test the checklist in the target environment, and correct any problems with the checklist.

833

3. Checklist Documentation: Document the checklist according to the NCP guidelines.

834 835

4. Checklist Submitted to NIST: Submit the checklist and documentation package to NIST for screening and public review.

836 837

5. NIST Screening: NIST screens the checklist package’s information and addresses any issues with the developer prior to public review.

838 839

6. Public Review and Feedback: NIST holds a 30-day public review of the candidate checklist. The developer addresses comments as necessary.

840 841

7. Final Listing on Checklist Repository: NIST lists the checklist on the repository as final and announces its availability.

842 843 844

8. Checklist Maintenance and Archival: Anyone can provide feedback on the checklist throughout its life. The developer updates the checklist periodically, as necessary. The checklist is archived when it is no longer being maintained or is no longer needed.

845 846 847

Each step should be carried out to ensure that the checklist is accurate, tested, and documented during its development and subsequent publication, update, or archival. The following sections describe considerations for each step.

848

5.1. Developer Steps for Creating, Testing, and Submitting Checklists

849 850 851

The first four steps in the development methodology listed above involve the developer creating, testing, documenting, and submitting checklists. Sections 5.2 through 5.5 describe each of these steps in greater detail.

13 For simplicity, the rest of this document uses the term “developer” to refer to the entities developing a checklist.

NIST SP 800-70r5 ipd (Initial Public Draft) December 2025

National Checklist Program for IT Products: Guidelines for Checklist Users and Developers

852

5.2. Initial Checklist Development

853 854 855 856 857 858 859 860 861 862

During initial checklist development, a developer familiarizes themselves with the requirements of the checklist program and all procedures involved during the checklist life cycle, as described throughout this section. The developer agrees to the requirements for participation in the NCP before continuing to develop the checklist. The participation requirements are described in this document but presented in administrative and programmatic terms in Appendix A, which is intended for those in organizations who must formally agree to NCP requirements. The participation agreement is contained in Appendix B. 14 After agreeing to the NCP requirements, the developer identifies which operational environments (see Sec. 3) the checklist should be implemented for and builds the checklist accordingly. The output of this step is an initial checklist for the product.

863 864 865 866 867 868

NIST recognizes that detailed checklist development cannot be covered extensively in this document. Developers may find publications on commonly accepted technical security principles and practices, as catalogued in SP 800-53 [7] and SP 800-160 [5], to be helpful when developing a checklist. Additional examples of checklists are available in the National Checklist Program repository. The mSCP has also documented their process for developing checklists for macOS and iOS at https://pages.nist.gov/macos_security/.

869 870 871

In terms of vulnerability coverage, security objectives should consider the most up-to-date vulnerabilities and generally be consistent with recognized sources of vulnerability-related information, including the NIST’s NVD and CISA’s Known Exploited Vulnerabilities (KEV). 15

872 873 874 875 876 877 878

Developers of checklists for products that are used by the Federal Government should consult FISMA-associated security control requirements. SP 800-53 [7] provides a catalog of security controls with assigned ratings that match the low, moderate, and high impact levels specified in FIPS 199 [9]. Developers of IT products used in federal information systems are encouraged to help federal agencies meet the requirements in FISMA by creating checklists that can be used in a variety of operational environments or for information systems with differing impact levels, as described in FIPS 199 and SP 800-53.

879

5.3. Checklist Testing

880 881 882 883 884

Before a checklist is submitted to NIST, it should be fully tested in the target environment and platform. The checklist should be tested with a variety of applications and hardware platforms to fully understand the impact of applying it. Ideally, at least some testing should be performed in a production or mirrored production environment. The testing data does not need to be submitted to NIST, but the developer should retain the data for review.

885 886 887 888

Selecting the most appropriate set of security controls can be a daunting task because many security controls limit system functionality and usability. In some cases, a security control can negatively impact other security controls. For example, installing a patch could inadvertently break another patch. It is important to perform testing for all security controls to determine 14 The latest updates to these sections and this document are available at https://nvd.nist.gov/ncp/participation. This updated material should

be consulted before formally agreeing to participate in the program. 15 The NVD is at https://nvd.nist.gov/. CISA’s website is https://www.cisa.gov/.

NIST SP 800-70r5 ipd (Initial Public Draft) December 2025

National Checklist Program for IT Products: Guidelines for Checklist Users and Developers

889 890 891

what impact they have on system security, functionality, and usability and to document potential impacts of applying a given setting. Users of the checklist will be able to take appropriate steps to address any significant issues caused by well-documented settings.

892 893 894

SP 800-115 [8] helps administrators test systems for vulnerabilities and configuration problems. Although this publication focuses on testing systems rather than testing individual IT products, it may be useful to checklist developers.

895

5.4. Checklist Documented

896 897 898 899 900 901 902 903 904 905

The quality of checklist documentation often makes a major difference in the checklist’s effectiveness. The checklist documentation should clearly explain how to use the checklist with concise, sound, and complete instructions. The skill level required to use the checklist should be identified, as well as the targeted environment. The documentation should also explain the significance of individual settings, including any changes to product functionality. If applicable, the documentation should also include procedures to verify that the checklist installation is successful, as well as guidance for uninstalling the checklist or restoring the product to its state before installation of the checklist. If it is not possible to roll back checklist settings, the checklist documentation should recommend alternative procedures (e.g., backups, system restoration) as applicable.

906 907 908 909 910

The testing methodology, such as how the checklist was tested and what platforms were used, should be documented. The checklist documentation should also contain information for troubleshooting if errors occur or if the checklist settings limit the product’s functionality, which may cause the product to not operate as desired. Ideally, assistance should be available for (registered) users of the product if there are problems.

911 912 913 914 915

Checklist developers are encouraged to contact NIST at cce@nist.gov to be assigned a set of CCE identifiers (i.e., globally unique identifiers) for their configuration settings. Although CCE is often associated with SCAP content, it can also be used apart to ensure globally unique identification for individual security settings in a checklist. See Appendix C regarding the use of CCEs to demonstrate connected paths from requirements to actual settings on the IT product.

916 917

Checklist developers must complete an online checklist description form for each checklist. 16 Table 1 shows the fields in the checklist description form that developers are to complete.

918

Table 1. Checklist description form fields Field Name

Checklist Name Version Publication Date Product Category

Description

The name of the checklist. The version or release number of the checklist. The date when the actual checklist document was published in the format MM/DD/YYYY. The main product category of the IT product (e.g., firewall, IDS, operating system, web server).

16 An offline version of the checklist description form can be downloaded from the NCP Participation Materials site on the checklist repository at

https://nvd.nist.gov/ncp/participation.

NIST SP 800-70r5 ipd (Initial Public Draft) December 2025

National Checklist Program for IT Products: Guidelines for Checklist Users and Developers

Field Name

Target CPE Name Checklist Role Checklist Summary Known Issues Audience Target Operational Environment Checklist Type Checklist Installation Tools FIPS 140-2/140-3 Compliance

Compliance

Authority

Author

Rollback Capability Testing Information Comments, Warnings, Miscellaneous Disclaimer Product Support

Description

The set of specific IT systems or applications for which a checklist has been created. The CPE representation of a specific Target. The primary use or function of the IT product as described by the checklist (e.g., client desktop host, web server, bastion host, network border protection, intrusion detection). The purpose of the checklist and its settings. Summary of issues that may arise after application of the checklist to help users pinpoint any functional and operational problems caused by the checklist. The intended audience that should be able to install, test, and use the checklist, including suggested minimum skills and knowledge required. The IT product’s operational environment (i.e., Stand-Alone, Managed, or Custom) with descriptions (e.g., Specialized Security-Limited Functionality, Legacy). Generally only applicable for security compliance/vulnerability checklists. The type of checklist (e.g., Compliance, Vulnerability, Specialized). The functional tools required to use the checklist to configure the system if they are not included with the checklist. Whether the product can operate in a FIPS 140-2/140-3 validated mode (yes or no). Whether the checklist or controls within the checklist are consistent with various regulations and standards, such as HIPAA, Gramm-Leach-Bliley Act (GLBA), FISMA (e.g., mappings to SP 800-53 controls), ISO 27001, Sarbanes-Oxley, the Department of Defense (DoD), Federal Risk and Authorization Management Program (FedRAMP), Control Objectives for Information and Related Technologies (COBIT), and the NIST Cybersecurity Framework (CSF). The organization responsible for producing the original security configuration guidance represented by the checklist. Authorities are ranked according to their “Authority Type.” On the NCP website, authorities are grouped with their authority types with the syntax Authority Type: Authority. The organization responsible for creating the checklist in its current format. In most cases, an organization will represent both the author and authority of a checklist, but this is not always true. For example, if an organization produces validated SCAP content for a NIST publication, the organization that created the SCAP content will be listed as the author, but NIST will remain the authority. Whether the changes in product configuration made by applying the checklist can be rolled back and, if so, how to roll back the changes. Platforms on which the checklist was tested. Can include additional testing-related information, such as a summary of the testing procedures used. Should specify any operational testing performed in production or mirrored production environments. Any additional information that the checklist developer wishes to convey to users. Legal notice pertaining to the checklist. Whether the vendor will accept support calls from users who have applied this checklist on their IT product; warranty for the IT product has not been affected. Required to use the NCP logo if the submitter is the product vendor. If the submitter is not the product vendor, the submitter should describe any agreement that they may have with the product vendor.

NIST SP 800-70r5 ipd (Initial Public Draft) December 2025

National Checklist Program for IT Products: Guidelines for Checklist Users and Developers

Field Name

Point of Contact Sponsor Licensing Automated Content Supporting Resource Dependency/Requirement References

Description

An email address, website, or repository where questions, comments, suggestions, and problem reports can be sent in reference to the checklist. The point of contact should be a location that the checklist developer monitors for reported issues. States the name of the IT product manufacturer organization and individuals who sponsor the submitted checklist if it is submitted by a third-party entity. States the license agreement (e.g., the checklist is copyrighted, open source, Creative Commons, General Public License [GPL], free software, shareware). A link to machine-readable content that represents the configuration guidance. A link to any supporting information or content related to the guidance. This field can hold data ranging from an English prose representation of the actual guidance to configuration scripts that apply guidance-specific settings on a target. Indicates that another checklist or guide is required to properly use and implement the current checklist. Any supporting references chosen by the developer that were used to produce the checklist or checklist documentation.

919 920

The developer needs to complete the fields as indicated to accurately describe the checklist and minimize user confusion about what the checklist accomplishes.

921

In summary, well-structured checklist documentation includes the following, as appropriate:

922 923

•

Statement of the security objectives, including the expected behavior of the product after applying the checklist

924 925

•

The intended audience (e.g., end user, system administrator) and the level of technical skill required to use the checklist

926 927

•

Explanation of the checklist settings, including each setting’s effect on the operation of the product and any functionality that the settings enable or disable

928

•

Backup procedures or any other initial steps required before applying the checklist

929 930

•

As appropriate, step-by-step instructions for applying the checklist (e.g., screen shots, illustrated procedures) and verifying that the installation is successful

931

•

Troubleshooting instructions or other information and references

932

5.5. Checklist Submitted to NIST

933 934

After the checklist developer has completed, tested, and documented the checklist, they may submit the package of materials to NIST. The package includes the following:

935

•

Checklist and configuration files, templates, and scripts

936

•

Completed checklist description

937

•

Checklist documentation

938

•

Identification of the developer point of contact

939

•

Signed participation agreement

NIST SP 800-70r5 ipd (Initial Public Draft) December 2025

National Checklist Program for IT Products: Guidelines for Checklist Users and Developers

940 941

The participation agreement and other requirements are outlined in detail in Appendix A, which also includes the appropriate NIST contact information.

942 943 944 945 946 947

Checklist packages are submitted to NIST through the NCP Submission website. The website allows checklist developers to view the checklists they have submitted, see tasks that have been assigned to them (e.g., fixing errors on a previously submitted checklist), update existing checklists, and perform other actions. NIST also provides web services for submitting, fetching, and maintaining checklists. To request access to the NCP Submission website or associated web services, email checklists@nist.gov.

948

5.6. NIST Steps for Reviewing and Finalizing Checklists for Publication

949 950

The NIST process for screening and publishing a checklist, which corresponds to steps 5 through 8 in the checklist life cycle, is described in the following sections.

951

5.7. NIST Screening of the Checklist Package

952 953 954 955

This step involves determining whether the checklist materials are ready for public review. NIST screens the checklist information for completeness and accuracy and ensures that checklist content is well-formed if it is SCAP-expressed. NIST may contact the developer with questions about the submitted materials during the screening period.

956

5.8. Public Review and Feedback for the Candidate Checklist

957 958 959 960 961 962

After the checklist package has been screened and the developer has addressed any issues, NIST will post it as a candidate draft and announce it for public review for a period of 30 days. This allows the public to review and test the checklist and to provide the checklist developers and NIST with comments and feedback. Information from comments and feedback may be incorporated in a revision of the checklist to improve its quality. When a candidate checklist has completed the review process, its information is added to the checklist repository.

963 964 965 966

A checklist reviewer emails checklists@nist.gov to provide comments on the reviewer’s test environment, procedures, and other relevant information. Depending on the review, the checklist developer may need to respond to comments. NIST may also consult independent expert reviewers as appropriate. Typical reasons for using independent reviewers include:

967 968

•

NIST may decide that it does not have the expertise to determine whether the comments have been addressed satisfactorily.

969 970

•

NIST may disagree with the proposed issue resolutions and seek reviews from third parties to get additional perspectives.

971 972

At the end of the public review period, NIST will give the developer 30 days to respond to comments.

NIST SP 800-70r5 ipd (Initial Public Draft) December 2025

National Checklist Program for IT Products: Guidelines for Checklist Users and Developers

973

5.9. Final Listing on Checklist Repository

974 975 976 977

After any outstanding issues are addressed, NIST lists the final checklist on the repository and announces its availability. At this time, the developer (e.g., IT product vendor) may be eligible to use the checklist logo on the IT product’s promotional material if they plan to provide assistance for the checklist. Requirements for use of the logo are described in Appendix B.

978

5.10. Checklist Maintenance and Archival

979 980 981 982 983 984 985

Throughout a checklist’s life cycle, anyone can provide comments or ask questions regarding the checklist by emailing checklists@nist.gov, and NIST will pass feedback to the checklist developer. Depending on the product and how frequently updates occur, NIST may maintain an email list for the associated checklists. Users who subscribe to the email list can receive announcements of updates or other issues connected with a checklist. The selected checklist’s description (on the checklist repository) will contain instructions for subscribing to the email list.

986 987 988 989 990

After the final checklist is listed, NIST will periodically review the checklist to determine whether it is still relevant or requires changes. NIST will make an announcement if the developer decides to update the checklist at any time. If the revised checklist contains major changes, it will be treated as a new submission and will be required to undergo the same review process as a new submission.

991 992 993 994

At the discretion of NIST or the developer, the checklist can be removed from the repository or marked as an archive. Typical reasons for such actions would be that the product is no longer supported or is obsolete or if the developer no longer wishes to provide support for the checklist.

995

NIST SP 800-70r5 ipd (Initial Public Draft) December 2025

National Checklist Program for IT Products: Guidelines for Checklist Users and Developers

996

References

997 998 999 1000 1001 1002 1003 1004 1005 1006 1007 1008 1009 1010 1011 1012 1013 1014 1015 1016 1017 1018 1019 1020 1021 1022 1023 1024

[1] Part 39 of the Federal Acquisition Regulation (FAR). Available at https://www.acquisition.gov/far/part-39 [2] Federal Information Security Modernization Act (FISMA) of 2014, Public Law 113-283. Available at https://www.congress.gov/113/plaws/publ283/PLAW-113publ283.pdf [3] Cyber Security Research and Development Act of 2002, Public Law 107-305, 116 Stat. 2367. Available at http://www.gpo.gov/fdsys/pkg/PLAW-107publ305/pdf/PLAW-107publ305.pdf [4] Waltermire D, Quinn S, Booth H, Scarfone K, Prisaca D (2018) The Technical Specification for the Security Content Automation Protocol (SCAP): SCAP Version 1.3. (National Institute of Standards and Technology, Gaithersburg, MD) NIST Special Publication (SP) NIST SP 800126r3. https://doi.org/10.6028/NIST.SP.800-126r3 [5] Ross R, Winstead M, McEvilley M (2022) Engineering Trustworthy Secure Systems. (National Institute of Standards and Technology, Gaithersburg, MD) NIST Special Publication (SP) NIST SP 800-160v1r1. https://doi.org/10.6028/NIST.SP.800-160v1r1 [6] Joint Task Force (2018) Risk Management Framework for Information Systems and Organizations: A Security Life Cycle Approach for Security and Privacy. (National Institute of Standards and Technology, Gaithersburg, MD) NIST Special Publication (SP) NIST SP 80037r2. https://doi.org/10.6028/NIST.SP.800-37r2 [7] Joint Task Force (2020) Security and Privacy Controls for Information Systems and Organizations. (National Institute of Standards and Technology, Gaithersburg, MD) NIST Special Publication (SP) NIST SP 800-53r5. https://doi.org/10.6028/NIST.SP.800-53r5 [8] Scarfone K, Souppaya M, Cody A, Orebaugh A (2008) Technical Guide to Information Security Testing and Assessment. (National Institute of Standards and Technology, Gaithersburg, MD) NIST Special Publication (SP) NIST SP 800-115. https://doi.org/10.6028/NIST.SP.800-115 [9] National Institute of Standards and Technology (2004) Standards for Security Categorization of Federal Information and Information Systems. (Department of Commerce, Washington, DC), Federal Information Processing Standards Publication (FIPS) NIST FIPS 199. https://doi.org/10.6028/NIST.FIPS.199

NIST SP 800-70r5 ipd (Initial Public Draft) December 2025

1025

National Checklist Program for IT Products: Guidelines for Checklist Users and Developers

Appendix A. Checklist Program Operational Procedures

1026 1027

Operational Procedures

1028

for

1029

The NIST National Checklist Program

1030

for Information Technology Products

1031

Version 1.4

1032 1033 1034

This document sets forth the policies, procedures, and general requirements for the NIST National Checklist Program for Information Technology Products. This document is intended for those individuals in organizations who need to formally agree to the program’s requirements.

1035

This document is organized as follows:

1036

•

Section 1 — General considerations for the NIST National Checklist Program

1037

•

Section 2 — Procedures for the initial screening of a checklist prior to public review

1038

•

Section 3 — Procedures for the public review of a candidate checklist

1039

•

Section 4 — Final acceptance procedures

1040

•

Section 5 — Maintenance and delisting procedures

1041

•

Section 6 — Record keeping

1042

The following terminology is used in this appendix:

1043

•

Candidate is a checklist that has been screened and approved by NIST for public review.

1044 1045

•

FCL refers to the final checklist list, which is the listing of all final checklists on the NIST repository.

1046 1047 1048

•

Final is a checklist that has completed public review, has had all issues addressed by the checklist developer and NIST, and has been approved for listing on the repository according to the procedures of this section.

1049

•

Checklist refers to a checklist for a specific product and version.

1050 1051

•

Checklist Developer or Developer is an individual or organization that develops and owns a checklist and submits it to the National Checklist Program.

1052 1053

•

Independent Qualified Reviewers are tasked by NIST with making a recommendation to NIST regarding the public review or listing of the checklist. They work independently of

NIST SP 800-70r5 ipd (Initial Public Draft) December 2025

1054 1055

National Checklist Program for IT Products: Guidelines for Checklist Users and Developers

other reviewers and are considered experts in the technology represented by the checklist.

1056

•

Logo refers to the NIST National Checklist Program logo.

1057 1058

•

National Checklist Program, Program, or NCP is used in place of the NIST National Checklist Program for Information Technology Products.

1059 1060 1061

•

NIST Checklist Repository or Repository refers to the website that maintains the checklists, the descriptions of the checklists, and other information regarding the National Checklist Program.

1062 1063

•

Public Reviewer is any member of the general public who reviews a candidate checklist and sends comments to NIST.

1064 1065

•

Operational Environments refer to the operational environments outlined in this document.

1066

References to documents that form a basis for the requirements of this program are as follows:

1067 1068

•

FIPS 199, Standards for Security Categorization of Federal Information and Information Systems, https://doi.org/10.6028/NIST.FIPS.199

1069 1070

•

SP 800-160v1r1, Engineering Trustworthy Secure Systems, November 2022, https://doi.org/10.6028/NIST.SP.800-160v1r1

1071 1072

•

SP 800-126, The Technical Specification for the Security Content Automation Protocol (SCAP): SCAP Version 1.4

1073 1074

•

SP 800-126A, SCAP 1.3 Component Specification Version Updates: An Annex to NIST Special Publication 800-126 Revision 4

1075 1076 1077

•

SP 800-53r5, Security and Privacy Controls for Federal Information Systems and Organizations, September 2020 (updated September 2025) https://doi.org/10.6028/NIST.SP.800-53r5

1078 1079

•

SP 800-219r1, Automated Secure Configuration Guidance from the macOS Security Compliance Project (mSCP), https://doi.org/10.6028/NIST.SP.800-219r1

1080 1081

•

SP 800-128, Guide for Security-Focused Configuration Management of Information Systems

1082 1083

•

SP 800-70r5, National Checklist Program for IT Products — Guidelines for Checklist Users and Developers

1084

A.1. Overview and General Considerations

1085

This section focuses on general considerations for all parts of the National Checklist Program.

1086 1087 1088

a) Checklist Life Cycle Overview: 1. Checklist developers inquire about the program and download a submission package. The developer subsequently contacts NIST with a tested checklist, 31

NIST SP 800-70r5 ipd (Initial Public Draft) December 2025

National Checklist Program for IT Products: Guidelines for Checklist Users and Developers

1089 1090

supporting information, and a signed agreement to the requirements of the NCP. Checklist submission requirements and procedures are discussed in Sec. 2.

1091 1092 1093 1094

2. NIST verifies that all information is complete and performs a high-level screening of the checklist package. Checklists that meet the requirements for listing receive further consideration and are referred to as “candidate checklists.” Section 2 discusses screening criteria and procedures.

1095 1096

3. NIST lists the candidate checklist on the repository for public review for a period of 30 days, as discussed in Sec. 3.

1097 1098 1099

4. NIST forwards comments from public reviewers to the developer. The developer addresses the issues as appropriate, and the checklist is listed on the FCL, as discussed in Sec. 4.

1100 1101

5. NIST periodically reviews each final checklist to determine whether its listing should continue, be updated, or be archived, as discussed in Sec. 5.

1102 1103

b) Intellectual Property Rights: Developers retain intellectual property rights to their checklists.

1104 1105 1106 1107

c) Confidential Information: NIST does not anticipate the need to receive confidential information from checklist developers. If it becomes necessary to disclose confidential information to NIST, NIST and the developer must enter into a separate confidentiality agreement prior to such disclosure.

1108 1109 1110 1111 1112 1113

d) Independent Qualified Reviewers: NIST may decide to seek technical advice from independent qualified experts who will review checklist submissions to determine whether they meet program requirements. The reviewers are tasked with making a recommendation to NIST regarding a subsequent public review or final listing of the checklist. Typical but not exclusive of the reasons for employing independent reviewers include the following:

1114 1115

1. NIST does not possess the expertise to determine whether issues have been addressed satisfactorily.

1116

2. NIST disagrees with proposed issue resolutions.

1117 1118 1119 1120 1121

e) Terminating Consideration of a Checklist Submission: NIST or the developer may terminate the consideration of checklist submissions at any time. If NIST terminates consideration, the points of contact are asked to respond within 10 business days. Typical but not exclusive of the reasons for terminating the consideration of checklist submissions include the following:

1122

1. The submission package does not meet the screening criteria.

1123

2. The developer fails to address issues raised at other times.

1124

3. The developer violates the terms and conditions of participation in the program.

NIST SP 800-70r5 ipd (Initial Public Draft) December 2025

National Checklist Program for IT Products: Guidelines for Checklist Users and Developers

1125

A.2. Checklist Submission and Screening

1126 1127 1128 1129

This section outlines the procedures and requirements for submitting checklists to NIST and the process by which NIST determines whether checklists are suitable for public review. When checklists meet the screening criteria, they receive further consideration in a public review and are referred to as “candidate checklists.” NIST then follows the subsequent procedures.

1130 1131 1132

a) Notification of Checklist Program Requirements: NIST maintains a complete set of information for developers on the repository. The information outlines the requirements for participation in the program and describes materials and time frames.

1133

b) Materials Required From the Developer:

1134 1135 1136 1137 1138

1. Contact information for an individual from the submitting organization who will serve as the point of contact for questions and comments pertaining to the checklist, as well as contact information for a backup or deputy point of contact. The information must include a postal address, a direct telephone number, and an email address.

1139

2. The checklist, documentation, and description template.

1140 1141 1142

3. The participation agreement, which must be printed, signed, and sent to NIST. NIST accepts emailed PDF copies of the participation agreement, facsimiles, or copies via regular mail.

1143 1144 1145

4. Participation fees. Currently, there is no fee for checklist developers, though NIST reserves the right to charge fees for participation in the future. Fees are not retroactive.

1146 1147 1148 1149 1150

c) Preliminary Screening Checklist Contents: NIST performs a preliminary screening to verify that checklist packages meet basic program requirements. NIST will not typically perform an in-depth analysis of the content of the checklist (e.g., its reflection of recommended security and engineering practices), though NIST reserves the right to do so.

1151

A.3. Candidate Checklist Public Review

1152

NIST follows the subsequent procedures when listing candidate checklists for public review:

1153 1154 1155 1156

a) Public Review Period: NIST lists candidate checklists for a 30-day public comment period. NIST reserves the right to extend the review cycle, particularly for long or complicated checklists. NIST provides the following disclaimer in conjunction with candidate checklists:

1157 1158 1159

NIST does not guarantee or warrant the checklist’s accuracy or completeness. NIST is not responsible for loss, damage, or problems that may be caused by using the checklist.

NIST SP 800-70r5 ipd (Initial Public Draft) December 2025

National Checklist Program for IT Products: Guidelines for Checklist Users and Developers

1160 1161 1162

b) Accepting Comments from Reviewers: Public reviewers email checklists@nist.gov to provide comments about the test environment, procedures, and other relevant information. The contents of these emails are considered public records.

1163 1164 1165

c) Maintaining Records: NIST may maintain copies of correspondence and feedback between the public and developers by creating a unique email address for each checklist. If so, NIST will archive the information.

1166 1167

d) Addressing Comments: After the end of the public review period, the developer has 30 days to respond to comments.

1168

A.4. Final Checklist Listing

1169 1170 1171

After NIST determines that a checklist and the associated developers have met all requirements for final listing, NIST lists checklists in the FCL and refers to them as “final checklists.” NIST then follows the subsequent procedures:

1172 1173

a) Finalizing Checklists: NIST lists the checklist in the FCL. NIST may send announcements to various email lists maintained by NIST or other organizations.

1174 1175 1176 1177 1178

b) Handling Comments: NIST continues to accept comments about final checklists by maintaining a central email address on the repository at checklists@nist.gov. NIST lists the procedures to be followed when contacting the developer as well as the contact information for the developer (e.g., email address, URL). If the point of contact changes, NIST must be notified immediately.

1179

A.5. Final Checklist Update, Archival, and Delisting

1180

NIST follows these procedures for periodic update, archival, and delisting of final checklists:

1181 1182 1183 1184

a) Periodic Reviews: NIST periodically reviews each checklist to identify changes in its status. NIST may contact developers to determine whether there are changes in the status of a checklist. Developers have 30 days to respond and indicate whether checklists should be updated, archived, or delisted.

1185 1186 1187

b) Updates: NIST may indicate on the FCL when checklists are under review. Developers have 60 days after the review to submit the updated material to NIST. Depending on the magnitude of updates, NIST may screen the checklist and schedule a public review.

1188 1189 1190 1191

c) Archival: A checklist may be archived for a variety of reasons. For example, a developer may no longer want to provide support for the checklist, or a product may no longer be supported. At the discretion of the developer or NIST, the checklist can remain in the repository but be reclassified as an archive.

1192 1193 1194 1195

d) Delisting: When delisting occurs (e.g., when a developer fails to respond to inquiries from NIST about the status of a checklist), NIST removes the checklist from the FCL. NIST may send announcements to various email lists maintained by NIST or other organizations.

NIST SP 800-70r5 ipd (Initial Public Draft) December 2025

National Checklist Program for IT Products: Guidelines for Checklist Users and Developers

1196

A.6. Record Keeping

1197 1198

NIST maintains information associated with the program and requires that participants in the checklist program also maintain certain records, as follows:

1199 1200 1201

a) NIST Records: After a checklist has been submitted to NIST, while a checklist is listed on the FCL as a final or archived checklist, and for three years after the most recent update to the checklist, NIST will maintain the following:

1202

1. The checklist description template, as listed on the repository

1203

2. The checklist and its description, as listed on the repository

1204

3. All comments submitted as part of the public review

1205

4. All comments submitted to NIST regarding the checklist

1206 1207 1208

b) Developer Records: After a checklist has been submitted to NIST and while a checklist is listed on the FCL as a final or archived checklist, the developer will maintain the following:

1209

1. The checklist description template, as listed on the repository

1210

2. The checklist and checklist description, as listed on the repository

1211

3. Test reports and other evidence of checklist testing

1212

NIST SP 800-70r5 ipd (Initial Public Draft) December 2025

National Checklist Program for IT Products: Guidelines for Checklist Users and Developers

1213

Appendix B. Participation and Logo Usage Agreement Form

1214 1215 1216 1217 1218

This appendix contains the terms and requirements for participation in the NIST National Checklist Program (NCP) and for use of the NIST National Checklist Program logo. Prior to submission of a checklist to NIST, developers should ensure that they have the most recent version of this appendix, which is available as a separate file at https://nvd.nist.gov/ncp/participation.

1219 1220

Participation and Logo Usage Agreement Form

1221

for

1222 1223

The NIST National Checklist Program for Information Technology Products

1224

Version 1.5

1225 1226 1227 1228 1229 1230 1231

The phrase “NIST National Checklist Program for Information Technology Products” and the NIST National Checklist Program logo are intended for use in association with specific versions of information technology (IT) products for which a checklist has been created and has met the requirements of the National Institute of Standards and Technology (NIST) National Checklist Program for Information Technology Products for final listing on its checklist repository. You may participate in the NIST National Checklist Program and use the phrase and logo provided that you agree in writing to the following terms and conditions:

1232 1233 1234

1. You will follow the rules and requirements of the program as outlined in the NIST Operational Procedures for the NIST National Checklist Program (Appendix B of NIST SP 800-70 Revision 5).

1235 1236 1237

2. You will respond to comments and issues raised by a public review of your checklist submission within 30 days of the end of the public review period. Any comments from reviewers and your responses may be made publicly available.

1238 1239 1240

3. You agree to maintain the checklist and provide a response within 10 business days to requests from NIST for information or assistance with regard to the contents of the checklist.

1241 1242 1243

4. You agree to maintain checklist-related records according to the requirements of the NIST National Checklist Program, as listed in Appendix B of NIST SP 800-70 Revision 5, item 6.b.

1244 1245

5. You will hold NIST harmless in any subsequent litigation involving the checklist submission.

NIST SP 800-70r5 ipd (Initial Public Draft) December 2025

National Checklist Program for IT Products: Guidelines for Checklist Users and Developers

1246 1247 1248 1249 1250 1251

6. You may terminate your participation in the NIST National Checklist Program at any time. You will provide two business weeks’ notice to NIST of your intention to terminate participation. NIST may terminate its consideration of a checklist submission or your participation in the NIST National Checklist Program at any time. NIST will contact you two business weeks prior to its intention to terminate your participation. You may appeal the rejection and provide supporting evidence within one business week.

1252 1253 1254 1255 1256 1257 1258 1259

7. You may not use the name of NIST or the Department of Commerce on any advertisement, product, or service that is directly or indirectly related to this agreement other than attribution of the content source. By accepting this agreement, NIST does not directly or indirectly endorse any product or service provided or to be provided by you, your successors, assignees, or licensees. You may not in any way imply that this agreement is an endorsement of any such product or service. You may not combine use of the logo with other marks, phrases, or logos in such a way that would imply endorsement by NIST.

1260 1261 1262 1263 1264

8. The phrase “NIST National Checklist Program for Information Technology Products” and the NIST National Checklist Program logo are Registered Marks of NIST, which retains exclusive rights to their use. NIST reserves the right to control the use of the phrase “NIST National Checklist Program for Information Technology Products” and the NIST National Checklist Program logo.

1265 1266 1267 1268

9. Your permission to advertise participation in the NIST National Checklist Program and use of the logo is conditional on and limited to those products and the specific product versions for which a checklist is made currently available by NIST through the NIST National Checklist Program on its Final Checklist List.

1269 1270 1271 1272 1273

10. Your permission to advertise participation in the NIST National Checklist Program and use of the logo is conditional on and limited to those checklist developers who provide assistance to users of the checklist regarding proper use of the checklist and that the warranty for the product and the specific product versions is not changed by use of the checklist.

1274 1275 1276

11. Your use of the logo on product reports, letterhead, brochures, marketing material, and product packaging must be accompanied by the following: “TM: a Registered Mark of NIST, which does not imply product endorsement by NIST or the U.S. Government.”

1277 1278

12. The dimensional requirements for the size, placement, color, and other aspects of the logo are specified in NIST SP 800-70 Revision 5.

1279 1280

13. NIST reserves the right to charge a participation fee in the future. No fee is required at present. No fees will be made retroactive.

1281 1282 1283

14. NIST may terminate the NIST National Checklist Program at its discretion. NIST may terminate your participation in the program for any violation of the terms and conditions of the program or for statutory or regulatory reasons.

1284

By signature below, the developer agrees to the terms and conditions contained herein.

NIST SP 800-70r5 ipd (Initial Public Draft) December 2025

1285 1286 1287 1288 1289 1290 1291 1292 1293 1294 1295 1296 1297 1298 1299 1300

National Checklist Program for IT Products: Guidelines for Checklist Users and Developers

Organization or company name:

Name and title of organization authorized person:

Signature:

Date:

1301

NIST SP 800-70r5 ipd (Initial Public Draft) December 2025

National Checklist Program for IT Products: Guidelines for Checklist Users and Developers

1302

Appendix C. Automating NIST CSF 2.0

1303 1304 1305 1306 1307 1308 1309 1310

This overview illustrates how the NCP facilitates traceable and automatable connections among CSF 2.0 outcomes, SP 800‑53r5 controls, CCE items, and executable technical checks, such as SCAP (XCCDF/OVAL), PowerShell, Intune, shell/Ansible, GPO templates, and mSCP for macOS. This mapped pathway enables evidence-ready conformance from policy objectives to individual system settings and checks. Although the CSF 2.0 is used as an example in this appendix, any high level can be substituted, such as those mapped to the CSF 2.0 on the NIST Online Informative References (OLIR) program page.

1311 1312 1313 1314 1315 1316 1317

CCE provides stable, globally unique identifiers for low-level configuration settings so that individual checklist rules can be referenced unambiguously across tools and documents. In the NCP context, automated checklists are encouraged to include CCE identifiers. CCE allows for mappings between low-level settings and high-level requirements to be explicit, enabling repeatable verification and evidence generation. CCEs can be obtained from NIST by sending a request to cce@nist.gov. See https://ncp.nist.gov/cce for more details regarding CCE usage in checklists in the NCP.

1318

C.1. How the Path Connects Policy to Automation

1319 1320 1321

•

Organizational risk strategy objectives and policy are expressed through CSF outcome statements that are addressed with security and privacy controls (i.e., from SP 80053r5).

1322 1323 1324 1325

•

Those controls are implemented and verified through system-specific identifiers (i.e., CCEs) as device-specific configuration statements that automated scanners can interpret, which ensures that checklist rules can be referenced consistently across tools and documents.

1326 1327

•

Automated checklists incorporate CCE IDs expressed in SCAP to link policies, system settings, and high-level requirements with clear, repeatable verification.

1328

C.2. Implementation and Traceability

1329 1330

•

CSF 2.0 Subcategories (e.g., PR.AA-01) record desired outcomes (e.g., through a CSF Profile).

1331 1332 1333

•

OLIR maps these outcomes to SP 800‑53r5 controls or enhancements (e.g., AC-02, AC14, IA‑02) that are then mapped to CCE identifiers, anchoring requirements to concrete configuration objects.

NIST SP 800-70r5 ipd (Initial Public Draft) December 2025

National Checklist Program for IT Products: Guidelines for Checklist Users and Developers

1334 1335

•

SCAP content or native scripts (e.g., PowerShell, Intune, shell, Ansible, GPO, mSCP) enable automation.

1336 1337

•

Evidence can be collected and the authoritative NCP checklist can be cited for provenance and reporting.

1338 1339

•

CCE IDs serve as the link between controls and technical checks, whether automation is SCAP-based or uses native scripting.

1340

C.3. Checklist Development Guidance

1341

In your NCP checklist, clearly state:

1342

•

Content Type (i.e., Prose, Automated, SCAP) and how CCEs are referenced

1343

•

SCAP Content data streams, enabling validation with SCAPVal

1344

•

Supporting Resources, linking native scripts that maintain CCE mapping

1345 1346

•

Regulatory/Framework Mappings using OLIR to connect CSF, SP 800‑53, and CCE for full traceability

1347

C.4. Operational Environment Tailoring and Considerations

1348 1349 1350

•

Adjust CCE-coded rules for each environment, either Stand-Alone (e.g., simple, rollbackfriendly remediation) or Managed/Enterprise, integrated with centralized policy and layered security.

1351

•

CCE anchors remain constant, but profile parameters adapt to the environment.

1352 1353 1354 1355

•

Where SCAP can be used, XCCDF integration incorporates CCE IDs in rules using the element and system URL for consistency in rule logic and downstream automation. When SCAP is unavailable, embed CCE IDs in native automation to maintain traceability (e.g., PowerShell/Intune, mSCP).

1356 1357

•

Metadata traceability is provided by referencing both CSF/SP 800‑53 and CCE in checklist metadata, including relevant automation approaches.

1358 1359 1360

•

These methods support multiple platforms, including Linux (e.g., shells, Ansible), macOS (e.g., mSCP compliance scripts mapped to CCE rules), and Windows (e.g., GPO backups, Intune JSON, PowerShell).

1361 1362

•

Use SCAPVal to validate SCAP streams and submit checklists to the NCP repository for visibility and reuse.

1363 1364 1365

C.5. Checklist Submission and Maintenance •

Ensure that CCE identifiers are consistently present in rule metadata and automation artifacts.

NIST SP 800-70r5 ipd (Initial Public Draft) December 2025

1366 1367 1368 1369

•

National Checklist Program for IT Products: Guidelines for Checklist Users and Developers

Follow NCP’s public review process (typically 30 days), maintain versions, archive outdated content, and keep contact information up to date for handling CCE-related updates and errata.

C.6. Appendix References

1370 1371

•

SP 800-70r5, National Checklist Program for IT Products — Guidelines for Checklist Users and Developers, Nov 2025

1372

•

CCE Program: https://ncp.nist.gov/cce

1373

•

NCP Checklist Repository: https://checklists.nist.gov/

1374

•

SCAP and SCAPVal resources: https://scap.nist.gov/

1375

•

NIST CSF 2.0 (NIST CSWP 29), Feb 26, 2024, https://doi.org/10.6028/NIST.CSWP.29

1376 1377

•

NIST OLIR Program (overview, catalog, and templates): https://csrc.nist.gov/Projects/olir

1378 1379

•

SP 800‑53r5 (current release, incl. 2025 updates), https://doi.org/10.6028/NIST.SP.80053r5

1380

•

CCE Program (current lists and schema): https://ncp.nist.gov/cce

1381

•

NCP Checklist Repository: https://checklists.nist.gov/

1382 1383

•

NIST IR 7275r4, Specification for the Extensible Configuration Checklist Description Format (XCCDF) Version 1.2, https://csrc.nist.gov/pubs/ir/7275/r4/upd1/final

1384 1385

•

NIST macOS Security Compliance Project (mSCP): https://pages.nist.gov/macos_security/

1386 1387

•

CSF 2.0 news and resources: https://www.nist.gov/news-events/news/2024/02/nistreleases-version-20-landmark-cybersecurity-framework

NIST SP 800-70r5 ipd (Initial Public Draft) December 2025

National Checklist Program for IT Products: Guidelines for Checklist Users and Developers

1388

Appendix D. List of Symbols, Abbreviations, and Acronyms

1389

Selected acronyms and abbreviations used in the guide are defined below.

1390 1391

AIC Architecture and Infrastructure Committee

1392 1393

CCB Change Control Board

1394 1395

CCE Common Configuration Enumeration

1396 1397

CMVP Cryptographic Module Validation Program

1398 1399

CISA Cybersecurity and Infrastructure Security Agency

1400 1401

COBIT Control Objectives for Information and Related Technologies

1402 1403

CPE Common Platform Enumeration

1404 1405

CSRDA Cyber Security Research and Development Act of 2002

1406 1407

CVE Common Vulnerabilities and Exposures

1408 1409

CVSS Common Vulnerability Scoring System

1410 1411

DHCP Dynamic Host Configuration Protocol

1412 1413

DHS Department of Homeland Security

1414 1415

DISA Defense Information Systems Agency

1416 1417

DNS Domain Name System

1418 1419

DoD Department of Defense

1420 1421

FAQ Frequently Asked Questions

1422 1423

FCL Final Checklist List

1424 1425

FedRAMP Federal Risk and Authorization Management Program

NIST SP 800-70r5 ipd (Initial Public Draft) December 2025

1426 1427

FIPS Federal Information Processing Standards

1428 1429

FISMA Federal Information Security Modernization Act

1430 1431

GLBA Gramm-Leach-Bliley Act

1432 1433

GPL General Public License

1434 1435

GPO Group Policy Object

1436 1437

HIPAA Health Insurance Portability and Accountability Act

1438 1439

IA Information Assurance

1440 1441

IATF Information Assurance Technical Framework

1442 1443

IDS Intrusion Detection System

1444 1445

IP Internet Protocol

1446 1447

IR Interagency Report

1448 1449

IT Information Technology

1450 1451

ITL Information Technology Laboratory

1452 1453

MSCP macOS Security Compliance Project

1454 1455

NCP National Checklist Program

1456 1457

NIST National Institute of Standards and Technology

1458 1459

NSA National Security Agency

1460 1461

NVD National Vulnerability Database

1462 1463

OCIL Open Checklist Interactive Language

National Checklist Program for IT Products: Guidelines for Checklist Users and Developers

NIST SP 800-70r5 ipd (Initial Public Draft) December 2025

1464 1465

OMB Office of Management and Budget

1466 1467

OVAL Open Vulnerability and Assessment Language

1468 1469

SCAP Security Content Automation Protocol

1470 1471

SCAPVAL Security Content Automation Protocol Validation Tool

1472 1473

SMTP Simple Mail Transfer Protocol

1474 1475

SNMP Simple Network Management Protocol

1476 1477

SP Special Publication

1478 1479

SSLF Specialized Security-Limited Functionality

1480 1481

STIG Security Technical Implementation Guide

1482 1483

TIS Technology Infrastructure Subcommittee

1484 1485

VPN Virtual Private Network

1486 1487

XCCDF Extensible Configuration Checklist Description Format

1488 1489

XML Extensible Markup Language

National Checklist Program for IT Products: Guidelines for Checklist Users and Developers

1490

NIST SP 800-70r5 ipd (Initial Public Draft) December 2025

National Checklist Program for IT Products: Guidelines for Checklist Users and Developers

1491

Appendix E. Glossary

1492

Selected terms used in this guide are defined below.

1493 1494 1495

audience The intended audience that should be able to install, test, and use the checklist, including suggested minimum skills and knowledge required to correctly use the checklist.

1496 1497 1498 1499 1500

author The organization responsible for creating the checklist in its current format. In most cases, an organization will represent both the author and authority of a checklist, but this is not always true. For example, if an organization produces validated SCAP content for a NIST publication, the organization that created the SCAP content will be listed as the author, but NIST will remain the authority.

1501 1502 1503

authority The organization responsible for producing the original security configuration guidance represented by the checklist.

1504 1505 1506

authority type The type of organization that is the authority for the checklist. The three types are governmental authority, software vendor, and third party (e.g., security organizations).

1507 1508 1509 1510

automated checklist A checklist that is used through one or more tools that automatically alter or verify settings based on the contents of the checklist. Automated checklists document their security settings in a machine-readable format, either standard or proprietary.

1511 1512

candidate checklist A checklist that has been screened and approved by NIST for public review.

1513 1514 1515 1516 1517

checklist A document that contains instructions or procedures for configuring an IT product to an operational environment, verifying that the product has been configured properly, and/or identifying unauthorized configuration changes to the product. Also referred to as a security configuration checklist, lockdown guide, hardening guide, security guide, secure configuration, security technical implementation guide (STIG), or benchmark.

1518 1519

checklist developer An individual or organization that develops and owns a checklist and submits it to the National Checklist Program.

1520 1521 1522

checklist group Represents the grouping of checklists based on a common source material. Commonly used if an organization packages multiple sets of product guidance under the same name.

1523 1524 1525 1526 1527 1528

checklist revision Represents a change to the checklist content that does not affect the underlying rule/value configuration guidance put forth by the content. A scenario that would require a checklist revision is when automated content is created for a prose checklist. This revision would change the checklist’s content type from prose to automated content. A new checklist revision would be created to accommodate this change, while still maintaining the prose checklist revision for interested parties.

1529 1530 1531

checklist role The primary use or function of the IT product as described by the checklist (e.g., client desktop host, web server, bastion host, network border protection, intrusion detection).

1532 1533

checklist type The type of checklist, such as compliance, vulnerability, or specialized. 45

NIST SP 800-70r5 ipd (Initial Public Draft) December 2025

National Checklist Program for IT Products: Guidelines for Checklist Users and Developers

1534 1535 1536

content type The form of the checklist content in terms of the degree of automation and standardization. Examples include prose, automated, and SCAP content.

1537 1538 1539

custom environment An environment that contains systems in which the functionality and degree of security do not fit the other types of environments.

1540 1541 1542

final checklist A checklist that has completed public review, has had all issues addressed by the checklist developer and NIST, and has been approved by NIST for listing on the repository.

1543 1544

final checklist list (FCL) The listing of all final checklists on the NIST repository.

1545 1546

independent qualified reviewer A reviewer tasked by NIST with making a recommendation regarding public review or listing of the checklist.

1547 1548 1549 1550

legacy environment A custom environment that contains older systems or applications that may need to be secured to meet today’s threats but often use older, less secure communication mechanisms and need to be able to communicate with other systems.

1551 1552

logo The NIST National Checklist Program logo.

1553 1554

managed environment An environment comprising centrally managed IT products.

1555 1556 1557

NIST checklist repository The website that maintains the checklists, the descriptions of the checklists, and other information regarding the National Checklist Program. Also known as the repository.

1558 1559 1560

non-automated checklist A checklist that is designed to be used manually, such as English prose instructions that describe the steps an administrator should take to secure a system or to verify its security settings.

1561 1562 1563

operational environment The type of environment in which the checklist is intended to be applied. Types of operational environments are Stand-Alone, Managed, and Custom, including Specialized Security-Limited Functionality and Legacy.

1564 1565

product category The main product category of the IT product (e.g., firewall, operating system, web server).

1566 1567

prose checklist A checklist that provides a narrative descriptions of how a person can manually alter a product’s configuration.

1568 1569

public reviewer A member of the general public who reviews a candidate checklist and sends comments to NIST.

1570 1571 1572 1573

review status The status of the checklist within the internal NCP review process. Possible status options are Candidate, Final, Archived, or Under Review. A status of "Final" signifies that NCP has reviewed the checklist and accepted it for publication within the program.

NIST SP 800-70r5 ipd (Initial Public Draft) December 2025

National Checklist Program for IT Products: Guidelines for Checklist Users and Developers

1574 1575 1576

SCAP content checklist An automated checklist that adheres to the SCAP specification in SP 800-126 for documenting security settings in machine-readable standardized SCAP formats.

1577 1578 1579

Specialized Security-Limited Functionality (SSLF) Environment A custom environment that is highly restrictive and secure. It is usually reserved for systems that have the highest threats and associated impacts.

1580 1581

Stand-Alone Environment An environment that contains individually managed devices (e.g., desktops, laptops, smartphones, tablets).

1582 1583

target The set of specific IT systems or applications for which a checklist has been created.

1584 1585 1586 1587

target operational environment The IT product’s operational environment (i.e., Stand-Alone, Managed, or Custom) with descriptions (e.g., Specialized Security-Limited Functionality, Legacy). Generally only applicable for security compliance/vulnerability checklists.

1588

NIST SP 800-70r5 ipd (Initial Public Draft) December 2025

National Checklist Program for IT Products: Guidelines for Checklist Users and Developers

1589

Appendix F. Change Log

1590

In May 2022, the following changes were made to the report:

1591 1592

•

Abstract — Provides direct information on the key establishment schemes (DH, MQV) and the underlying mathematics structure (discrete logs on finite field, elliptic curve)

1593 1594 1595

•

Section 3.1 — Added definitions of assumption, binding, bit string, byte, byte string, destroy, key-establishment pair, key-wrapping key, trusted association. Removed definitions on assurance of identifier, initiator, and responder.

1596

NIST SP 800-70r5 ipd: National Checklist Program for IT Products: Guidelines for Checklist Users and Developers

Analyze & explore related research in Conceptio

Related documents