Between 2028 and 2030, you'll need to meet post-quantum cryptography deadlines. The systems you're responsible for determine whether you're facing a software upgrade or a multi-year infrastructure replacement.
The decision isn't whether to migrate. NIST finalized post-quantum algorithms in August 2024, and the clock is running. RSA and elliptic-curve cryptography must be replaced starting in 2030 and will be prohibited by 2035. Your choice is which path to take based on what you're actually protecting.
The Decision You're Facing
Do you treat post-quantum migration as a cryptographic library update that touches your PKI, VPNs, and remote access systems? Or do you recognize it as a hardware replacement program that requires vendor roadmaps, test environments, and capital budget cycles?
This isn't a technical distinction. It's a resource allocation decision that determines whether you're looking at months or years, whether you need procurement approval or just change control, and whether your current vendor contracts even cover the work.
Key Factors That Affect Your Choice
What protocols carry your cryptography?
If your systems use standard TLS, SSH, or IPsec connections, you're working with protocols designed to swap algorithms. If you're running SCADA, Modbus, DNP3, or proprietary OEM protocols, you may be dealing with protocols that were never built with meaningful cryptography.
What hardware runs those protocols?
Post-quantum signatures are larger and more memory-intensive than the RSA or ECDSA signatures they replace. A server with 16GB of RAM handles this easily. A programmable logic controller with 512KB of memory does not. 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 Windows XP still running in field environments.
How much downtime can you accept during the swap?
If you can schedule maintenance windows and roll back a failed update, you're in IT territory. If a failed update could disrupt power distribution, water treatment, or manufacturing lines, you're in OT territory where updates must be proven safe on a detailed clone of the live environment first.
Do you have a cryptographic inventory?
If you can list every certificate, every key exchange protocol, and every signature algorithm in your environment right now, you can plan a migration. If cryptographic vulnerabilities aren't tracked with the same rigor as CVE patches, you'll spend months just discovering what needs to change.
Path A: IT-Layer Migration (2-12 Months)
Choose this path if you're responsible for:
- Public key infrastructure and certificate authorities
- VPN concentrators and remote access gateways
- Web servers, API endpoints, and application-layer encryption
- Identity providers and authentication systems
- Cloud workloads with modern operating systems
What this path requires:
You'll need vendor confirmation that your current software versions support hybrid or post-quantum modes. DigiCert's July 2026 survey found that 87% of organizations are planning post-quantum migration, but only 7% report that more than half of their digital certificates actually use quantum-safe or hybrid cryptography today.
Your migration follows standard PKI renewal cycles. You'll generate new certificate signing requests with post-quantum algorithms, update trust stores, and test interoperability between hybrid and legacy systems. You're working within existing change management processes.
Timeline drivers:
Software vendors serving the IT layer are releasing post-quantum support now. Your constraint is internal: testing certificate chains, validating authentication flows, and coordinating updates across distributed systems. You can complete this work before 2028 if you start the inventory and vendor engagement this year.
Risk profile:
Your primary risk is interoperability during the hybrid phase. You'll run classical and post-quantum algorithms side-by-side, but there's no industry consensus yet on which hybrid mode to follow. Test thoroughly, document rollback procedures, and expect some systems to need multiple update cycles.
Path B: OT-Layer Migration (3-7 Years)
Choose this path if you're responsible for:
- Remote terminal units and SCADA systems
- Programmable logic controllers in manufacturing or utilities
- Intelligent electronic devices in power grids
- Protection relays and field instrumentation
- Inter-control center communication protocols
What this path requires:
You're not swapping cryptographic libraries. You're coordinating hardware refresh cycles, vendor roadmaps that may not exist yet, and capital budgets that require legislative or board approval.
The protocols that move commands between control centers and field devices often have minimal cryptography built in. Where cryptography exists, it's frequently embedded in proprietary firmware that can't be patched separately from the hardware. Many OEM-specific products use proprietary algorithms and kernels that were never designed to have their keys changed at all.
Timeline drivers:
Your timeline depends on vendor delivery schedules, not your internal readiness. Hardware vendors supplying intelligent electronic devices, RTUs, and PLCs are fragmented in their post-quantum support. Some may release firmware updates. Others will require full device replacement.
You'll need digital twins or dedicated test benches to validate updates before deploying them to production. These test environments aren't common in OT settings, and building them adds 6-12 months to your timeline.
Risk profile:
Your primary risk is that some devices will never receive post-quantum updates. The U.S. Cybersecurity and Infrastructure Security Agency noted that 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."
Plan now for how you'll handle devices that can't be upgraded: network segmentation, additional monitoring, or formal risk acceptance.
Path C: Hybrid Approach (Most Realistic)
Most critical infrastructure operators will split the difference. Your IT-adjacent OT systems like HMI workstations, historians, and engineering workstations follow Path A. Your field-level devices follow Path B.
This creates a boundary problem. You'll have quantum-safe control centers communicating with non-quantum-safe field devices for years. Your risk management strategy needs to account for this gap explicitly.
Engage vendors now on their post-quantum roadmaps. If they don't have one, that's a procurement signal. Start building the business case for capital replacement in parallel with your IT-layer migration. Don't wait for the inventory to be complete before beginning vendor discussions.
Summary Matrix
| Factor | IT Track | OT Track |
|---|---|---|
| Primary constraint | Internal testing cycles | Vendor delivery schedules |
| Update mechanism | Software/firmware patches | Hardware replacement |
| Downtime tolerance | Scheduled maintenance windows | Requires pre-validated test environment |
| Completion timeline | 2-12 months | 3-7 years |
| Budget type | Operational (software licenses, staff time) | Capital (device procurement, installation) |
| Rollback capability | Standard change control | High-risk, may require physical swap |
| Vendor readiness | Post-quantum support available now | Fragmented, roadmaps incomplete |
The deadlines assume this is a software problem. For half your infrastructure, it isn't. Start the procurement conversation now, or you'll be explaining in 2029 why compliance depends on vendors who haven't shipped the hardware yet.
