Post-Quantum Cryptography for OT Explained: Why "Harvest Now, Decrypt Later" Threatens ICS Protocols Before NIS2's 2030 Deadline

Q: Does NIS2 require post-quantum cryptography?

Not yet as binding legal text -- the EU NIS Cooperation Group's June 2025 Coordinated Implementation Roadmap sets a 2030 transition / 2035 complete-transition target for critical infrastructure, and the European Commission has proposed writing PQC obligations directly into NIS2, but confirm the current legislative status before treating this as finalized law.

Q: When will quantum computers actually break encryption?

There's no expert consensus on a specific date -- credible estimates for when a cryptographically relevant quantum computer will exist range roughly 5 to 15-plus years out. The lack of a firm date is why harvest-now-decrypt-later is treated as a present risk, not a future one.

Diagram of the harvest-now-decrypt-later threat timeline: OT traffic captured and stored today with a padlock icon, decrypted later by a future quantum computer, shown above three unencrypted-by-default ICS protocols — Modbus, DNP3, and IEC 61850.

Post-quantum cryptography (PQC) for OT means replacing the encryption that protects industrial control system traffic — including Modbus, DNP3, and IEC 61850 — before a future quantum computer becomes powerful enough to break today's RSA- and ECC-based algorithms and unlock data attackers are already capturing now. That "harvest now, decrypt later" (HNDL) threat doesn't wait for a working quantum computer to exist; it starts the moment your OT traffic crosses a network an adversary can record, which for most plants is already happening today, quietly, in the background. NIST finalized its first PQC algorithm standards (FIPS 203, 204, and 205) in August 2024, and the EU's NIS Cooperation Group has attached a 2030 transition / 2035 complete-transition clock to critical infrastructure — a deadline that's about to fold into NIS2 compliance whether OT security budgets have accounted for it or not.

By The Whitepaper Skeptic — OT architecture reviews that never got asked about encryption

Quick Facts

Question	Answer
What is "harvest now, decrypt later" for OT?	Adversaries record encrypted (or unencrypted) ICS traffic today and store it, planning to decrypt it once a cryptographically relevant quantum computer exists — the theft happens now, the exposure happens later
What PQC standards does NIST require?	FIPS 203 (ML-KEM), FIPS 204 (ML-DSA), and FIPS 205 (SLH-DSA) — finalized August 2024, the first official post-quantum algorithm standards
What's the NIS2 PQC deadline?	The EU NIS Cooperation Group's June 2025 Coordinated Implementation Roadmap sets a transition target of end-2030 and a "complete transition for as many systems as practically feasible" target of end-2035 for critical infrastructure
Do Modbus, DNP3, and IEC 61850 encrypt traffic by default?	No — all three were designed for reliability in isolated industrial environments, with little or no built-in cryptographic protection as a baseline assumption
What is crypto-agility?	The ability to swap out a system's cryptographic algorithms or key sizes without redesigning or replacing the system itself — the practical hedge against a disputed quantum timeline and against any one PQC algorithm later being broken

What "Harvest Now, Decrypt Later" Actually Means for a Plant Floor

HNDL is not a hypothetical future attack — it's a present-tense collection strategy with a future-tense payoff. An adversary with any access point into OT network traffic (a compromised historian, a misconfigured firewall, a tapped WAN link, or simply passive collection at a point the traffic already transits) can copy and store encrypted or plaintext ICS communications today, without needing to break anything at the time of capture. The value of that stored traffic doesn't depend on today's cryptography — it depends on whether the algorithm protecting it is still unbroken by the time the adversary gets around to trying.

For IT systems, this threat model gets discussed constantly in the context of TLS and VPN traffic. It's discussed almost nowhere in OT-specific, practitioner-facing security content — most existing PQC coverage either stays at the generic enterprise level (migrating web servers, PKI, VPN concentrators) or lives in academic papers written for a cryptography research audience rather than a plant-floor engineer. That gap is exactly why this deserves its own explanation: the mechanics of applying PQC to Modbus, DNP3, and IEC 61850 are a genuinely different problem than migrating a corporate TLS stack.

Why Modbus, DNP3, and IEC 61850 Are Especially Exposed

These three protocols share a design assumption that made sense decades ago and doesn't hold anymore: that the network they run on is physically isolated, so cryptographic protection wasn't worth the engineering cost. That assumption is the same one this blog already covered from a network-isolation angle in The Air Gap Myth in OT Security — HNDL is the data-in-transit version of the same problem.

Protocol	Native encryption in the base standard	Common deployment reality	HNDL exposure
Modbus	None — the base protocol has no cryptographic layer at all	Frequently run in cleartext over TCP or serial-to-Ethernet gateways	High — plaintext traffic is trivially capturable right now, no future quantum break even required
DNP3	DNP3 Secure Authentication (SAv5, part of IEEE 1815) exists as an add-on, but is not mandatory or default	Widely deployed without SAv5 enabled, especially on older RTU/master installations	High where SAv5 is unused; even where it is enabled, its underlying cryptographic primitives are the same classical algorithms a future quantum computer targets
IEC 61850 (GOOSE/MMS)	No mandatory encryption in the base specification; separate security profiles exist but adoption varies	GOOSE messages in particular are typically left unencrypted because of strict sub-millisecond latency requirements in substation protection schemes	High for GOOSE traffic specifically; MMS exposure varies by implementation and whether a security profile was actually deployed

This isn't a hypothetical academic framing — it's the exact migration problem covered in the SSRN paper "Harvest Now, Decrypt Later Threats to Industrial Control Systems: Post-Quantum Cryptographic Migration Strategies for Modbus, DNP3, and IEC 61850 Protocols," which is one of the few sources that engages directly with what PQC migration means at the protocol level rather than the enterprise-IT level (see Sources below).

The NIS2 Countdown: 2030 and 2035 Aren't Someday Numbers Anymore

Most manufacturers already know NIS2 exists as a compliance obligation — our earlier NIS2 spoke covers the essential/important entity classification, the fine structure, and the 24-hour incident-reporting clock. What most readers of that coverage don't yet know is that a second, separate clock is now attached to the same directive: a post-quantum cryptography transition timeline.

Milestone	Timing	Source
NIS Cooperation Group publishes Coordinated Implementation Roadmap	June 2025	NIS Cooperation Group
Critical infrastructure operators expected to begin/substantially advance PQC transition	End of 2030	NIS CG Coordinated Implementation Roadmap
Complete transition "for as many systems as practically feasible"	End of 2035	NIS CG Coordinated Implementation Roadmap
European Commission proposal to write PQC obligations directly into NIS2 law	Proposed — confirm current legislative status before treating as final, proposals can shift between publication and adoption	European Commission

Two things worth being precise about. First, this roadmap is a coordination document from the NIS Cooperation Group, not yet a binding legal requirement inside NIS2's own text — the European Commission's proposal to formally write PQC obligations into the directive was still working through the process as of this writing, so "NIS2 requires PQC" is currently more accurate as "NIS2 is on track to require PQC" than as settled law. Second, 2030 is closer than it sounds once you account for OT migration timelines: a study by Robert Campbell, "Enterprise Migration to Post-Quantum Cryptography: Timeline Analysis and Strategic Frameworks," published in the MDPI journal Computers (vol. 15, no. 1, article 9; published online December 24, 2025; DOI: 10.3390/computers15010009), estimated PQC migration timelines of roughly 5-7 years for small enterprises, 8-12 years for medium enterprises, and 12-15+ years for large, complex organizations. That's a single study's estimate, not an industry consensus figure, but even taken conservatively, a large industrial operator starting a PQC migration in 2026 is not obviously ahead of a 2030 deadline.

NIST's PQC Standards: What FIPS 203, 204, and 205 Actually Cover

NIST finalized its first three post-quantum cryptography standards in August 2024, after a multi-year public evaluation process:

FIPS 203 (ML-KEM) — Module-Lattice-Based Key-Encapsulation Mechanism. This is the general-purpose replacement for algorithms like RSA and ECDH used to establish a shared secret key over an untrusted channel.
FIPS 204 (ML-DSA) — Module-Lattice-Based Digital Signature Standard. Replaces classical digital signature schemes (RSA, ECDSA) used for authentication and integrity verification.
FIPS 205 (SLH-DSA) — Stateless Hash-Based Digital Signature Standard. A conservative, hash-based alternative signature scheme, intended as a structurally different backup in case weaknesses are later found in lattice-based approaches.

Separately, the NSA's Commercial National Security Algorithm Suite 2.0 (CNSA 2.0) mandates PQC readiness for U.S. national security systems starting in 2025, with a target of exclusive PQC use by 2035 — a parallel, defense-sector timeline that roughly tracks the EU's civilian critical-infrastructure roadmap above.

None of these three standards were written with ICS protocol constraints in mind. They specify the cryptographic algorithms themselves, not how to fit them into a Modbus master-slave exchange or a sub-millisecond IEC 61850 GOOSE message — that translation work is still happening in academic papers rather than finished vendor products, which is exactly why "wait for a vendor to hand you a PQC-ready PLC" is not currently a viable near-term plan for most OT environments.

Why Crypto-Agility Matters More Than Picking "the Right" Algorithm

Crypto-agility is the ability to swap out a system's cryptographic algorithms, key sizes, or protocols without redesigning or replacing the underlying system. It matters here for two reasons that have nothing to do with each other, which is exactly why it's worth building as a standing capability rather than a one-time migration project.

First, the Q-Day timeline — when a cryptographically relevant quantum computer (CRQC) capable of actually breaking current public-key cryptography arrives — is genuinely disputed among experts. The Global Risk Institute and evolutionQ's Quantum Threat Timeline Report, an annual survey of roughly two dozen international cryptography and quantum-computing experts led by Michele Mosca and Marco Piani, put the 2025-edition probability of a CRQC existing within 10 years at between 28% and 49% depending on how responses are weighted, rising to a 50%-or-higher probability from most respondents at the 15-year mark — a spread that, in plain terms, is closer to a 5-to-15-plus-year range of credible outcomes than a single date. Nobody should plan an OT crypto migration around a single confident date, because there isn't one to plan around.

Second, even the post-quantum candidates NIST evaluated haven't all held up. SIKE (Supersingular Isogeny Key Encapsulation), a fourth-round NIST PQC candidate, was cryptanalytically broken by a classical (non-quantum) attack in 2022 — before it could be standardized. Researchers Wouter Castryck and Thomas Decru (KU Leuven) published the key-recovery attack in July 2022, breaking SIKEp434 in about an hour on a single classical CPU core (see Sources below); the SIKE submission team itself subsequently posted a note confirming the algorithm was insecure, and it was withdrawn from further NIST consideration. That's the strongest practical argument for crypto-agility available: an algorithm doesn't need to survive a quantum computer to fail; it can fail against ordinary mathematics before it's even finalized. A system that can only ever run one hardcoded cryptographic algorithm is one bad cryptanalysis paper away from needing a hardware refresh it wasn't planned for.

The Same Constraint That Blocks Patching Also Blocks Crypto Upgrades

If you've read why you can't just patch a PLC, the crypto-agility problem will sound structurally familiar, because it's the same underlying constraint wearing a different hat. A PLC or RTU installed in the 2000s or 2010s, still running the control-system firmware it shipped with, doesn't get a software update to add ML-KEM support — in a lot of cases, the processor and memory footprint that field device was built with simply doesn't have the headroom to run lattice-based cryptographic operations designed with modern IT hardware in mind. Where a patch-management decision tree routes an unpatchable finding to a compensating control (usually virtual patching at the network layer), the crypto-agility equivalent is largely the same move: a gateway or protocol-aware proxy in front of the legacy device that terminates a PQC-protected connection on the network side, while the field device itself keeps running its original, unmodified cryptography (or none at all) on the segment behind it. That's a mitigation, not a fix — the underlying device is still running classical, eventually-breakable cryptography — but it's the realistic near-term answer for the large share of the installed base that will never get a native PQC firmware update on any practical timeline.

Segmentation Protects Who Can Reach the Wire. It Doesn't Protect What's On It.

This is the point most OT security programs miss, because segmentation has rightly become the default first answer to almost every OT security question. IEC 62443 zones and conduits design controls who and what can reach a given asset or traverse a given conduit — that's an access-control problem. HNDL is a different problem entirely: it targets traffic that's already permitted to flow through an approved conduit, recorded by whatever means (a compromised device inside the zone, an insider, a supply-chain-compromised switch, or historical access that's since been closed off entirely). A perfectly designed zones-and-conduits architecture does nothing to stop an adversary who already has a recording of the traffic crossing a legitimate, correctly authorized conduit from decrypting it years later. Segmentation and encryption solve adjacent but non-overlapping problems, and it's worth being explicit that IEC 62443 as currently published does not yet mandate specific post-quantum algorithms or a PQC transition timeline of its own — treat any claim that it already does as unconfirmed until a specific edition and clause is cited.

I have signed off on exactly that kind of conduit. On more than one architecture review, the control-zone-to-historian path got closed out as adequate because it was filtered, logged, and crossing an approved boundary — and nobody in the room, me included, asked what was actually inside the packets. Going by the protocol table above, for a Modbus feed the answer is cleartext, which means the finding I recorded as "conduit adequate" was also, unnoticed, a finding about traffic an adversary only has to record once.

It's also worth noting where a device's cryptographic library version actually needs to live once you start tracking it: the same place patch status already lives. An SBOM for industrial control systems is built to hold exactly this kind of granular, per-device software inventory — and "which crypto library version, and is it PQC-capable" is a field that belongs in that same inventory, not in a separate spreadsheet nobody keeps current.

Where to Start: A Practical Crypto-Agility Checklist

Given a disputed Q-Day timeline, a 2030/2035 EU roadmap, and an installed base that mostly can't be natively upgraded, the realistic starting point for most OT security teams isn't "migrate everything to PQC" — it's building the visibility and architecture that makes a migration possible when it becomes unavoidable:

Inventory cryptographic exposure, not just assets. Extend your existing asset inventory to record which protocol each device speaks (Modbus, DNP3, DNP3-SA, IEC 61850 with or without a security profile) and whether traffic to/from it is encrypted at all today.
Identify which conduits carry the highest-value, longest-lived data. HNDL risk is proportional to how long the captured data stays sensitive — engineering configurations, safety-system logic, and long-term process data are worse HNDL targets than short-lived telemetry that's stale within hours.
Plan gateway-based crypto termination for unupgradeable field devices, using the same compensating-control logic already applied to unpatchable PLCs.
Track PQC readiness as a field in your SBOM/asset inventory, not a separate one-time compliance project — crypto-agility is a standing capability, not a checkbox.
Watch the NIS2 legislative text, not just the roadmap, since the Commission's proposal to formalize PQC obligations inside the directive itself was still moving through process as of this writing.

FAQ

Q: What is harvest now, decrypt later in OT security?
A: It's an attack pattern where an adversary captures and stores encrypted (or unencrypted) OT/ICS network traffic today, with the intent to decrypt it later once a cryptographically relevant quantum computer exists. The data theft happens now; the exposure happens whenever a future quantum computer becomes capable of breaking the algorithm that protected it.

Q: Does NIS2 require post-quantum cryptography?
A: Not yet as binding legal text — the EU NIS Cooperation Group's June 2025 Coordinated Implementation Roadmap sets a 2030 transition / 2035 complete-transition target for critical infrastructure, and the European Commission has proposed writing PQC obligations directly into NIS2, but confirm the current legislative status before treating this as finalized law rather than a roadmap plus a pending proposal.

Q: Can PLCs support post-quantum cryptography?
A: Most legacy PLCs and RTUs currently in service were not built with the processing headroom for lattice-based PQC algorithms, so native support is unrealistic on any near-term timeline for a large share of the installed base. The practical near-term approach is the same compensating-control model used for unpatchable devices: terminate PQC-protected connections at a gateway or protocol-aware proxy in front of the legacy device rather than on the device itself.

Q: What is crypto-agility in OT security?
A: Crypto-agility is the ability to swap out a system's cryptographic algorithms or key sizes without redesigning or replacing the system itself. It matters in OT because the timeline for when quantum computers will actually break current cryptography is genuinely disputed, and because even post-quantum candidate algorithms have been broken before standardization (SIKE, broken in 2022) — a system locked into one hardcoded algorithm can't adapt to either scenario.

Q: When will quantum computers actually break encryption?
A: There's no expert consensus on a specific date — credible estimates for when a cryptographically relevant quantum computer (CRQC) will exist range roughly 5 to 15-plus years out, and that range itself is contested. The lack of a firm date is precisely why "harvest now, decrypt later" is treated as a present risk rather than a future one: the data capture doesn't wait for certainty about the decryption date.

Sources

Author Bio

The Whitepaper Skeptic has run OT security architecture reviews for industrial and manufacturing environments where the standard findings were always about network segmentation and asset visibility — and where the question of what's actually encrypting (or not encrypting) traffic between a PLC and its historian almost never came up, because until a compliance clock like NIS2's 2030 PQC transition target existed, there wasn't yet a business reason to ask it. This article is the question those reviews were about to start asking.

Search This Blog

Beyond the Whitepaper