NIST SP 800-82r4 draft cryptography: what OT teams need

NIST SP 800-82r4 is the fourth revision of NIST’s Guide to Operational Technology (OT) Security. It sets out how operators of industrial control systems, building automation and other cyber-physical systems should protect their environments, including how they use cryptography for data in transit between sites, cloud platforms and remote users. It is currently an initial public draft.

For organizations that run critical infrastructure, the draft matters for two reasons. It is the main US reference for adapting IT security controls to OT constraints. It also arrives at the same time as the federal post-quantum migration timeline, which determines how long today’s key exchange algorithms stay acceptable. This article explains what the draft says about cryptography, where it is silent, and how to use the comment period.

What is new in the NIST SP 800-82r4 initial public draft?

The main changes are a restructuring around the NIST Cybersecurity Framework 2.0, a wider set of OT sectors including IIoT and cloud convergence, and new architecture guidance based on zero trust. NIST published the draft on September 21, 2026, with comments due November 30, 2026.

NIST’s own summary lists these changes:

• An expanded introduction to OT sectors that now includes Building Automation and Control Systems (BACS), Water and Wastewater Systems (WWS), food and agriculture, freight rail, maritime vessels, and Industrial Internet of Things (IIoT) and cloud convergence.
• The document is restructured around the NIST Cybersecurity Framework (CSF) 2.0, including a reorganization of the previous risk management section to focus on the CSF Govern Function.
• Expanded discussion of how OT risk management aligns with broader enterprise risk management, as described in NIST IR 8286r1, plus a discussion of adopting the NIST Risk Management Framework in Appendix F.
• Security architecture guidelines focused on protecting system management functions and applying zero trust principles.

The draft follows a pre-draft consultation. In January 2026, NIST said it aimed to align with relevant NIST guidance (e.g., Cybersecurity Framework (CSF) 2.0, NIST IR 8286 Rev. 1, NIST SP 800-53 Rev. 5.2.0) and OT cybersecurity standards and practices. That pre-draft comment window ran from January 22 to February 23, 2026 (NIST CSRC, 2026).

The structure of the publication is also changing. NIST states that Appendix C on threat sources, vulnerabilities and incidents, and Appendix D on OT security organizations, research and activities, will be transitioned to online supplemental resources or separate documents for the final publication. In practice, the threat material will be updated more often than the core guidance.

What does SP 800-82r4 say about data security and cryptography (PR.DS) for OT systems?

The draft treats cryptography as a baseline safeguard for OT data in all states, and it has dedicated sections on cryptographic protection for data at rest and data in transit. It does not prescribe specific algorithms. Those come from NIST’s cryptographic standards.

In CSF 2.0, the Data Security category (PR.DS) sits under the Protect function. It covers the confidentiality, integrity and availability of data at rest, in transit and in use. Because SP 800-82r4 is organized around CSF 2.0, its data-security guidance maps directly onto those outcomes. The draft’s table of contents includes subsections titled Cryptographic Protection for Data-at-Rest, Protecting Data in Transit, and Cryptographic Protection for Data in Transit.

The executive summary puts it plainly. The authors list “securing data at rest and in transit with appropriate cryptography” among core practices, and under asset hardening they recommend that operators apply encryption and/or cryptographic hashes to protect data. Their “Restrict Data Modification” strategy calls for protecting data from unauthorized modification in all states (i.e., at rest, in transit, in use) and across network boundaries.

Why availability shapes cryptographic choices in OT

In OT, cryptography is always weighed against latency and uptime. The draft notes that systems with stringent availability and uptime requirements may require greater redundancy or alternative implementations across all communications and controls. For encrypted links between a control center and field sites, the practical questions are what happens when a link drops, whether traffic ever falls back to plaintext, and how much delay the encryption layer adds to SCADA polling cycles.

Mapping to SP 800-53 Rev. 5

For control-level detail, the draft points to the NIST SP 800-53 Rev. 5 overlay. Appendix E defines the SP 800-53r5 OT overlay and lists security controls, with tailoring considerations per family, including System and Communications Protection. That family holds the transmission confidentiality and integrity controls that most encryption decisions trace back to.

How does SP 800-82r4 address IIoT and cloud convergence for OT data flows?

The draft brings IIoT and cloud explicitly into the scope of OT. That means data leaving the plant for edge gateways and cloud back ends is now part of the OT security boundary rather than an IT afterthought.

The abstract describes OT as covering systems such as industrial control systems, building automation and control systems (BACS), freight railroad, maritime vessels, water and wastewater systems (WWS), Industrial Internet of Things (IIoT), and cloud environments. The draft includes a “Cloud and IIoT convergence example architecture” and notes that IIoT architectures commonly include sensors, instruments, machines, edge gateways, wireless or wired access networks, and backend platforms.

For cryptography planning, three flow types come out of this architecture. Each has different constraints:

The draft’s zero trust architecture guidance and its focus on protecting system management functions apply to all three. Encrypting the link is necessary, but it does not replace segmentation, authentication or monitoring.

How does SP 800-82r4 relate to NIST IR 8547 and the post-quantum transition?

SP 800-82r4 tells OT operators to protect data in transit with appropriate cryptography. NIST IR 8547 decides which public-key algorithms count as appropriate, and for how long. The two documents need to be read together. NIST’s published summary of the 800-82r4 changes does not list post-quantum cryptography as a new topic.

NIST IR 8547 sets the federal migration path. Under the transition timeline in NIST IR 8547, NIST will deprecate and ultimately remove quantum-vulnerable algorithms from its standards by 2035, with high-risk systems transitioning much earlier. It names RSA, (EC) Diffie-Hellman, MQV, ECDSA and EdDSA as vulnerable, and ML-KEM, ML-DSA, SLH-DSA, LMS and XMSS as post-quantum standards.

Dustin Moody of NIST’s Cryptographic Technology Group summarized the transition stance: “Organizations may continue using public key algorithms at the 112 bit security level as they migrate to post-quantum cryptography.” National Security Memorandum 10, quoted in NIST IR 8547, sets the US goal of “mitigating as much of the quantum risk as is feasible by 2035.”

Why key establishment comes first

NIST IR 8547 says NIST expects to prioritize the migration to quantum-resistant key-establishment schemes within these updates to protect against “harvest now, decrypt later” attacks, particularly in interactive protocols like TLS and IKE. The report adds that “starting the transition to post-quantum cryptography now is critical to preventing these future breaches.” Network diagrams, process recipes and engineering files sent between sites can stay sensitive for a long time, so the key exchange on those links is the logical first place to migrate.

NIST IR 8547 also covers hybrid approaches. Public comments on the draft describe it as treating a classical algorithm and a PQC algorithm combined into a composite mechanism, intended to be secure as long as at least one of the component algorithms is secure, and states that such hybrid approaches may be used in the initial transition to PQC.

When does the comment period for SP 800-82r4 close and how can OT operators submit comments?

The comment period closes on November 30, 2026. NIST asks reviewers to use its spreadsheet comment template and to email comments to the address given on the CSRC publication page.

The publication page says that the comment period on this initial public draft is open through November 30, 2026, and NIST encourages use of its comment template. NIST also notes that a call for patent claims is included in this draft. In the pre-draft round, NIST warned that submitted comments, including attachments and other supporting materials, will become part of the public record and are subject to public disclosure. Leave site names, IP ranges and other operational details out of your submission.

Cryptography comments worth considering

• Post-quantum cross-reference: ask NIST to reference NIST IR 8547 and FIPS 203 in the data-in-transit sections, so OT readers see the migration timeline where they read about encryption.
• Crypto agility for long-lived assets: ask for guidance on how to change algorithms on links serving equipment with multi-decade lifecycles.
• Failure behavior: ask NIST to state explicitly that encrypted OT links should not fall back to plaintext when a line fails, and how this fits with availability requirements.
• Air-gapped and isolated networks: ask how cryptographic updates should be delivered where cloud connectivity is not allowed.

How can OT operators act on the draft’s cryptography guidance now?

Start with a cryptographic inventory of every link that carries OT data across a boundary. Then decide which links need quantum-resistant key exchange first, based on how long the data stays sensitive and how long the equipment stays in service.

A practical order of work:

1. Map the flows from the IIoT and cloud convergence architecture: site to site, edge to cloud, remote access. Note which ones cross the public internet.
2. Record the key exchange on each link. Classical Diffie-Hellman and RSA key transport are on the NIST IR 8547 vulnerable list.
3. Prioritize by data lifetime. Links carrying engineering data and historian replication usually go before short-lived alarm traffic.
4. Keep inspection where it is needed. Encryption should not leave the existing firewall blind on paths where it still has to inspect traffic.
5. Document it in your CSF 2.0 profile under PR.DS, with references to the relevant SP 800-53 Rev. 5 controls, so the decision can be traced in governance reviews.

One way to implement this is a network-layer gateway at each end of a link. Quantum Network’s QPN, for example, combines a classical and an ML-KEM key agreement into a single session key, encrypts at Layer 3, and can sit in front of or behind an existing firewall depending on whether that firewall still has to inspect the traffic. This kind of approach protects data in transit only. It does not replace segmentation, endpoint hardening or monitoring, which SP 800-82r4 treats as separate safeguards.