You're hearing the same reassurances in every executive briefing: "We're upgrading to post-quantum cryptography." "Our vendors have it covered." "It's just a software patch." These myths persist because they're comforting, and because the people repeating them haven't spent time in an operational technology (OT) environment where a failed update can take down a power grid.
NIST released post-quantum cryptography standards in August 2024. Governments worldwide set adoption deadlines between 2028 and 2030, with full prohibition of current RSA and elliptic-curve cryptography by 2035. Your board sees these dates and assumes you have six years to execute a straightforward cryptographic upgrade. Here's what they're missing.
Myth 1: "Post-Quantum Migration Is Like Any Other Security Update"
Reality: In OT environments, you can't test the fix against the threat it's meant to stop because a cryptographically relevant quantum computer doesn't exist yet. You're deploying countermeasures based on mathematical assumptions, not empirical validation.
Migration assumes you're swapping one working cryptographic algorithm for another. That framing doesn't hold in OT. Field-level protocols that move commands between control centers and remote terminal units, SCADA platforms, and programmable logic controllers were never built with meaningful cryptography in the first place. You're not upgrading existing protection; you're retrofitting it into systems that were designed without it.
Consider the inter-control center communications protocols used between grid control centers. These protocols have minimal cryptographic penetration today. You can't migrate what isn't there.
Myth 2: "We'll Know What Needs Upgrading When the Time Comes"
Reality: Most organizations lack a clear inventory of cryptography embedded across their OT environments. Cryptographic vulnerabilities are tracked with far less rigor than traditional security issues. Before you can plan migration, you first have to discover what cryptography, if any, is running in your environment.
This isn't an IT problem where you query your certificate management platform and get a complete asset list. OT environments contain OEM-specific products with proprietary algorithms and kernels that were never designed to have their keys changed at all, let alone replaced with larger, heavier post-quantum signatures.
Start your inventory now. Don't wait for vendor guidance or regulatory clarity. Map every protocol, every field device, every remote terminal unit that touches cryptographic operations. This work takes months, not weeks, and you can't build a migration plan without it.
Myth 3: "Hybrid Cryptography Buys Us Time"
Reality: There's no consensus on which hybrid mode to follow. Hybrid cryptography runs classical and post-quantum algorithms side by side during transition, but without standardized approaches or interoperability agreements, you're creating fragmentation rather than safety.
Some hybrid modes exist, but the absence of industry consensus makes deployment risky. The European Union Agency for Cybersecurity warns that the long wait for consensus might result in organizations skipping hybrid implementations entirely and jumping straight to full post-quantum deployments, which compounds risk in environments where testing is already constrained.
Post-quantum signatures are bigger and more memory-intensive than the algorithms they replace. Many older field controllers don't have the memory to run them. Hybrid mode doubles that burden, requiring both classical and quantum-safe algorithms to operate simultaneously. If your remote terminal units are already resource-constrained, hybrid cryptography isn't a bridge strategy; it's a non-starter.
Myth 4: "Our Vendors Are Ready"
Reality: Vendor readiness splits into two distinct groups moving at radically different speeds. Software vendors supplying analytics, visualization, PKI, and certificate management are advancing quickly on post-quantum support. Hardware vendors supplying intelligent electronic devices, remote terminal units, and programmable logic controllers are fragmented at the firmware and chip level.
Industry data shows the gap between intent and execution. According to DigiCert's Quantum Readiness Outlook from July 2026, 87% of organizations report planning, testing, or implementing post-quantum cryptography. But only 7% report that more than half of their digital certificates actually use quantum-safe or hybrid cryptography, a figure that improved less than 2% between May 2025 and July 2026.
If IT organizations with dedicated PKI teams are converting intent into deployment this slowly, the hardware vendor gap for OT is wider still. Don't assume your control system manufacturer has a post-quantum roadmap. Ask explicitly. Request timelines. Verify whether they're testing on hardware that matches your deployed base.
Myth 5: "It's a Compliance Issue, Not an Operational Risk"
Reality: Patching OT systems, including real-time control systems, is fundamentally riskier than patching an IT server. You can't afford downtime in systems managing power distribution or water treatment. Updates must be proven safe on detailed clones of live environments, but digital twins and dedicated test benches aren't common in OT deployments.
The U.S. Cybersecurity and Infrastructure Security Agency warned in October 2024 that operational technology accounts for a significant proportion of out-of-date operating systems and software platforms, including end-of-life systems like Windows XP still running in the field. OT may account for some of the last remaining platforms to achieve post-quantum cryptographic standards due to long software patching cycles, hardware replacement times, and strict procedures and governance.
This isn't a compliance checkbox. It's a question of whether your critical infrastructure can absorb a cryptographic transition without creating new availability risks that exceed the quantum threat you're trying to mitigate.
What to Do Instead
Segment your approach into two tiers. The IT-heavy layer that includes PKI, VPNs, and remote access are realistic candidates for post-quantum migration on the regulatory timeline. These systems can be upgraded, tested, and validated using existing change management processes.
The field-level protocols and embedded hardware require a different strategy. Some devices will never receive a post-quantum upgrade. You'll need to choose between adding compensating controls, replacing the device entirely, or accepting the residual risk with documented justification.
Run two parallel tracks. First, work directly with vendors to learn their post-quantum roadmaps, test on specific use cases, and build migration plans for systems you control. Second, engage budget-holders and legislators with a concrete rollout strategy, including staffing and capital costs, to establish funding priority over a fixed multi-year period.
Start the cryptographic asset inventory immediately. Run it in parallel with protocol upgrades, software patches, and hardware refreshes where possible. Don't wait for the inventory to be complete before beginning experimentation on PKI and exposed remote-access assets.
The realistic picture for OT ecosystems by 2030 looks less like a finished migration and more like triage. Your board needs to understand that now, while you still have time to set expectations and allocate resources accordingly. The deadlines assume the fix can be installed like any other update. The people closest to OT know it's a fix with nowhere to go.
