NIST Draft Publications Open for Comment

SP 800-230, Additional SLH-DSA Parameter Sets for Limited Signature Use CasesInitial Public Draft

2026-04-13T00:00:00-04:00

NIST is seeking public comments on the initial public draft (ipd) of Special Publication (SP) 800-230, Additional SLH-DSA Parameter Sets for Limited-Signature Use Cases. This document serves as a technical extension to FIPS 205 by specifying six additional parameter sets for security levels 1, 3, and 5. These variants are specifically tailored for use cases that require fast verification and reduced signature sizes, such as the signing of software, firmware, and digital certificates. These optimizations are achieved by establishing a strict limit of 2^24 signatures per signing key; therefore, these sets are not approved for general-purpose use.

NIST requests feedback on the suitability of these additional parameter sets, specifically asking reviewers to identify applications for which these variants might incur unacceptable performance or to suggest alternative sets that are better suited for such use cases. Users must perform a thorough evaluation to ensure that the signature limit is never exceeded during a key's lifetime. Please submit comments to SP800-230-comments@nist.gov by June 12, 2026

SP 800-133 Rev. 3, Recommendation for Cryptographic Key GenerationInitial Public Draft

2026-04-17T00:00:00-04:00

This document describes the generation of keys to be managed and used by approved cryptographic algorithms.

Proposed changes in this revision include the following:

Asymmetric key-pair generation has been expanded to include methods for deriving randomness during key-pair generation.
Key-pair generation now has options for derivation similar to symmetric keys and new methods for “seed expansion,” which allows for the limited use of SHAKE and deterministic random bit generators (DRBGs).
Key-encapsulation mechanisms (KEMs) are discussed as a key-establishment option for symmetric key generation, and post-quantum cryptography (PQC) references have been added throughout (e.g., the new PQC signatures).
Text has been reworded to address random number generation in alignment with SP 800-90C.

Comments are especially requested regarding:

Hardware security module (HSM) design — How do these requirements align with common practice and existing systems using a root seed/secret value?
PQC implementations and protocol — How do these requirements fit with storing keys as seeds (e.g., for ML-KEM) and performing hybrid (i.e., combined classical and post-quantum) implementations?

IR 8500A, Blockchain-Based Secure Software Assets Management (BloSS@M)Initial Public Draft

2026-05-19T00:00:00-04:00

NIST Internal Report (IR) 8500A ipd (initial public draft), Blockchain-Based Secure Software Assets Management (BloSS@M), outlines a modernized conceptual approach for transforming how software assets are acquired, tracked, and secured across an interagency ecosystem.

The conceptual approach for BloSS@M was developed in consideration of federal asset inventory and management requirements — including OMB Circular A-130 and OMB M-13-13 — as well as NIST SP 800-37 and SP 800-53 guidelines. BloSS@M establishes a shared infrastructure for software acquisition that promotes asset reuse, eliminates duplicative procurement, and strengthens supply chain security at scale. Its key capabilities include:

Federal purchasing power: A consolidated model that reduces redundant spending and increases collective leverage with vendors through government-wide aggregation
Immutable life cycle tracking: Utilizes blockchain’s tamper-resistance to provide a verifiable, continuous record of asset provenance from acquisition to retirement
Automated vulnerability management: Real-time integration with the National Vulnerability Database (NVD) to continuously surface newly disclosed vulnerabilities associated with deployed assets
Machine-processable compliance: Leverages the Open Security Controls Assessment Language (OSCAL) to enable automated risk assessments, continuous monitoring, and scalable life cycle management across heterogeneous environments

While BloSS@M is optimized for software, where end-to-end automation is most achievable, the approach is architected to support hardware assets when integrated with appropriate physical delivery and retrieval mechanisms.

Submit Your Comments:

NIST invites input from federal agencies, industry partners, researchers, and the broader cybersecurity community. The public comment period is open through June 26, 2026.

SP 800-228A, Guidelines for the Secure Deployment of RESTful Web APIsInitial Public Draft

2026-05-18T00:00:00-04:00

A RESTful API platform is a stateless architectural framework that leverages standard HTTP protocols to manage and exchange data as "resources," serving as the primary bridge for communication between modern web applications. These Web APIs are the most prevalent API type. Their inherent simplicity, universal compatibility with browsers, robust ecosystem of developer tools, and superior caching efficiency align with existing web infrastructure to provide scope for introducing vulnerabilities and accompanying threats of exploitation.

This document:

Analyzes threats to RESTful APIs across the pre-runtime and runtime phases
Provides guidelines for implementing a set of controls to mitigate threats
Complement the detailed set of controls provided in SP 800-228 by including parameters that are specific to the architectural style of RESTful Web APIs

NOTE: A call for patent claims is included in this draft. For additional information, see the Information Technology Laboratory (ITL) Patent Policy – Inclusion of Patents in ITL Publications.

IR 8323 Rev. 2, Foundational PNT Profile: Applying the Cybersecurity Framework for the Responsible Use of Positioning, Navigation, and Timing (PNT) ServicesInitial Public Draft

2026-05-06T00:00:00-04:00

This profile helps organizations manage risks to systems, networks, and assets that use PNT services, such as Global Positioning Systems (GPS), public NIST and United States Naval Observatory (USNO) Network Time Protocol (NTP) servers, commercial services, and internal systems.

Originally developed based on NIST Cybersecurity Framework version 1.1, this profile has been updated to align with the NIST CSF 2.0 and includes updated references to standards, guidelines, and practices to provide practical guidelines to help an organization achieve the desired outcome for each Subcategory in the profile.

Organizations can apply the Profile to govern cybersecurity risk management, identify systems dependent on PNT, identify appropriate PNT sources, protect PNT user equipment from adversaries, detect anomalies and manipulation of PNT services, and respond to and recover from PNT service disruptions.

We encourage you to review the revised publication draft and submit comments until July 6, 2026, using the instructions provided on the project page. NIST is seeking targeted feedback to ensure the profile is practical and aligned to real-world use.

Specific questions are included in the draft document. In particular, we are interested in:

Whether additional references to support PNT systems and data, or additional Categories or Subcategories from NIST CSF 2.0 should be added
How emerging technologies (including AI) impact the use of PNT systems and data
Whether the profile appropriately addresses third-party and data dependency risks

SP 1800-41, Responding to and Recovering from a Cyber Attack: Cybersecurity for the Manufacturing SectorInitial Public Draft

2026-05-21T00:00:00-04:00

The NIST National Cybersecurity Center of Excellence (NCCoE) has released this initial public draft NIST Cybersecurity Practice Guide, which provides guidelines on response and recovery activities in an industrial control system (ICS) environment and recommendations to improve operational resilience. The comment period for this publication is open through July 8, 2026.

Background

As Operational Technology (OT) systems like ICS become increasingly interconnected with IT networks, they are increasingly being targeted by cyber threats, putting factory operations, safety, and property at risk. Organizations operating these systems, such as those in the manufacturing sector, need to have plans and capabilities in place to respond to cyber incidents and restore operations to improve overall resilience.

The NCCoE worked with 11 industry collaborators to develop reference architectures, describe response and recovery scenarios, and demonstrate relevant approaches and capabilities.

This draft publication provides actionable guidelines on responding to and recovering from cyber attacks in manufacturing environments. Discover how to:

Understand the risks and potential impact of cyber incidents on your operations
Develop a comprehensive response and recovery plan
Implement best practices to minimize downtime and restore operations quickly

Comment Now!

We encourage you to review the publication and share your feedback by July 8, 2026. If you’re interested in staying up-to-date on this project, you can join the NCCoE Manufacturing Community of Interest by signing up on our project page.

SP 800-38F Rev. 1, PRE-DRAFT Call for Comments: Recommendation for Block Cipher Modes of Operation: Methods for Key WrappingInitial Preliminary Draft

2026-05-05T00:00:00-04:00

NIST plans to revise Special Publication (SP) 800-38F, Recommendation for Block Cipher Modes of Operation: Methods for Key Wrapping (2012), and is soliciting preliminary feedback.

The following are the two main goals for the revision:

The specification of TKW should be removed because its underlying block cipher, TDEA, is no longer approved.
The approval in Section 3.1 of unspecified combinations of an approved encryption mode with an approved authentication method should be revisited because such combinations may introduce unexpected security vulnerabilities compared to fully specified methods for authenticated encryption. (See the NIST page on authentication for block cipher modes for more information, including links to some of the relevant security analysis.)

NIST requests feedback on all aspects of this publication, especially the following questions:

What ad hoc combinations—approved encryption mode and approved authentication method—are currently implemented, in practice?
Should NIST limit the approval to an explicit set of such combinations that occur within prominent protocols?

The public comment period is open through July 10, 2026. Send comments to ciphermodes@nist.gov with “Pre-Draft Comments on SP 800-38F” in the subject line. Comments received in response to this request will be posted on this page after the due date. Submitters’ names and affiliations (when provided) will be included, while contact information will be removed.

IR 8320E, Hardware-Enabled Security: Confidential Computing of Data in Cloud WorkloadsInitial Public Draft

2026-05-29T00:00:00-04:00

The National Cybersecurity Center of Excellence (NCCoE) invites public comments NIST Interagency Report (NIST IR) 8320E ipd (initial public draft), Hardware-Enabled Security: Confidential Computing of Data in Cloud Workloads. This is the latest in a series of reports on hardware-enabled security techniques and technologies.

Confidential computing addresses data security and privacy concerns for organizations that move sensitive workloads to the cloud. It is a critical advancement that enables the encryption of data while it is being processed in memory, extending encryption coverage to data in active use. As cloud adoption continues to grow, confidential computing will play a pivotal role in improving security and privacy in cloud environments.

IR 8320E describes an example approach to protecting data being acted upon by artificial intelligence workloads on cloud infrastructures so that the datasets are protected from malware, data theft, and other security-related vulnerabilities. This report is intended to be a blueprint that the general security community can use to validate and utilize the described implementation.

The public comment period for this draft is open through July 13, 2026. See the publication details for a copy of the draft and instructions for submitting comments. You can also contact the authors at hwsec@nist.gov.

SP 800-38D Rev. 1, Second Pre-Draft Call for Comments: GCM and GMAC Block Cipher Modes of Operation2nd Preliminary Draft

2026-06-01T00:00:00-04:00

As previously announced, NIST is revising Special Publication (SP) 800-38D, Recommendation for Block Cipher Modes of Operation: Galois/Counter Mode (GCM) and GMAC. In addition to revising the Galois/Counter Mode (GCM), NIST proposes to specify a wider variant, wGCM. wGCM operates on an underlying block cipher with 256-bit blocks, to support the Rijndael-256 variant of AES that NIST proposed for standardization.

NIST is preparing an initial set of parameters for wGCM and requests feedback on the efficiency and security trade-offs, including the following issues and questions:

1. Questions on GCM:

The revision to GCM will remove support for authentication tags whose lengths are less than 96 bits. Which of the remaining tag sizes (i.e., 96, 104, 112, 120, or 128 bits) are needed for GCM? In particular, would tag sizes of 96 bits and 128 bits be sufficient for applications?
GCM currently supports variable-length IVs by applying the internal hash function to generate a new, 96-bit IV value. Are variable-length IVs important for any applications?

2. Questions on wGCM:

Would a limit of 2⁶⁴ wGCM invocations per key be sufficient?
What authentication tag sizes should be specified for wGCM (e.g., 128, 192, or 256 bits) to support larger data limits than GCM? Is more than one tag size necessary?
NIST proposes 192 bits as the default IV length for wGCM, devoting the remaining 64 bits of the IV block within wGCM to the message block counter for the GCTR encryption. Is there a need to support longer IVs in wGCM by applying the internal hash function, as in GCM?
The deterministic IV construction for GCM defines a fixed field and an invocation field. For wGCM, NIST proposes to recommend a fixed field of 96 bits and an invocation field of 96 bits to promote interoperability. Are other options needed?
The random IV construction for GCM defines a random field and a free field. For wGCM, if the number of invocations per key were limited to 2⁶⁴, and if 192 bits were specified for the random field, then the probability of an IV collision would be limited to 2^-64. Is the free field useful/necessary for wGCM?
Are these two 192-bit IV constructions sufficiently flexible, or should NIST consider adding other, comparably secure constructions?
The natural generalization of the GCM hash function (i.e., GHASH) for wGCM would specify a suitable polynomial of degree 256 to define a hash function (called wide-GHASH) on 256-bit blocks. The output can be truncated as needed to obtain the appropriate tag size. Should NIST consider a different option for the hash function component of wGCM? For example, two instances of GHASH using independent 128-bit keys could be concatenated and truncated as needed. Since this option (called concat-GHASH) operates on 128-bit blocks, it would be more efficient than wide-GHASH. However, concat-GHASH cannot provide as much generic security assurance as wide-GHASH and would require much more restrictive usage bounds (i.e., smaller limits on total data, the message length, and invocations per key) for any given security target.

The public comment period is open through July 31, 2026. Comments can be submitted to ciphermodes@nist.gov with “Comments on SP 800-38D revision” in the subject field. Comments received in response to this request will be posted on this page after the due date. Submitters' names and affiliations (when provided) will be included, while contact information will be removed.

Learn more about NIST’s cipher modes project.