The Conventional Wisdom
Federal agencies and defense contractors are being urged to replace their current cryptographic systems with NIST post-quantum cryptography algorithms immediately. The fear is that quantum computers will soon break existing encryption, leaving your data vulnerable. This has turned PQC into a compliance panic button.
Why This Urgency is Misguided
The rush to migrate overlooks three critical realities that could turn your PQC transition into a costly mistake.
First, you likely don't know where all your cryptographic implementations are. The OMB report estimates $7.1 billion in federal migration costs between 2025 and 2035 because agencies are still identifying cryptographic dependencies. Without a complete inventory, you can't prioritize what to migrate first. Starting a transition without this knowledge is like renovating a building without blueprints.
Second, not all systems are equally at risk from the "harvest now, decrypt later" threat model. While adversaries may be collecting encrypted data for future decryption, not all of your data will remain sensitive for 10-15 years. For example, VPN logs from 2024 won't matter in 2035, but classified research on next-generation weapons systems will. Treating all encrypted channels as equally vulnerable wastes resources on low-value targets.
Third, immediate migration can cause more harm than good. PQC algorithms require larger key sizes and different computational patterns. Forcing them into legacy systems without compatibility testing can create new vulnerabilities. You're not just swapping algorithms; you're re-engineering authentication, key exchange, and digital signatures across your environment.
The Evidence
NIST released the PQC algorithms with the understanding that agencies need time to plan. While the standards exist, the implementation ecosystem is still developing. Hardware security modules, certificate authorities, and protocol stacks are still adding PQC support. Your HSMs might not support ML-KEM-768 today, even if you wanted to deploy it tomorrow.
The OMB report outlines four strategies that counter the panic narrative. The first strategy emphasizes the importance of a comprehensive cryptographic inventory as a baseline for successful migration. Not "migrate immediately" or "replace everything," but inventory first. The third strategy advises prioritizing systems and data for PQC migration based on risk, not racing to convert everything simultaneously.
The fourth strategy highlights the need to identify systems that can't support PQC algorithms early. Some systems, like operational technology and IoT devices, can't handle the computational demands of PQC. Forcing PQC onto these platforms doesn't secure them; it makes them unstable.
A proper cryptographic inventory reveals where public-key cryptography is used, often in forgotten places. TLS certificates on internal servers, SSH keys in scripts, and code-signing certificates in your CI/CD pipeline all need evaluation. Rushing migration before mapping these dependencies guarantees you'll miss critical systems or disrupt workflows.
What to Do Instead
Begin by building a cryptographic inventory before changing any algorithms. Map every certificate, key exchange, and digital signature in your environment. Use automated tools, but manually validate their output. Your inventory should answer: Where does public-key cryptography exist? What algorithm does each implementation use? What data does it protect? How long must that data remain confidential?
Categorize your data by sensitivity duration. NIST SP 800-53 Rev 5 control SC-12 requires determining cryptographic key lifetimes based on data sensitivity. Apply this logic to PQC migration. Data that remains sensitive beyond 2035 should move first. Session keys for routine traffic can move later.
Prioritize based on exposure and replaceability. Systems exposed to the internet face higher risk than internal systems behind security layers. Systems nearing end-of-life that will be replaced soon can skip PQC migration if their replacements support it natively.
Test compatibility before committing to production migration. Set up a pilot environment with PQC-enabled endpoints to verify applications, monitoring tools, and security controls still function. Larger key sizes affect network performance, storage, and processing latency. You need baseline measurements before scaling.
Plan for hybrid cryptography during the transition. Many implementations will run both classical and post-quantum algorithms simultaneously. Your certificate authorities, HSMs, and protocol implementations need to support dual-mode operation. This isn't a weekend cutover; it's a multi-year parallel operation.
Document what can't migrate and plan compensating controls. If your SCADA system can't support PQC algorithms, you need alternative protections. Network segmentation, encrypted tunnels terminating at PQC-capable gateways, and reduced data retention become your compensating controls under NIST SP 800-53 Rev 5 control SA-8.
When the Conventional Wisdom is Right
The urgency about the threat is real. Quantum computers will eventually break RSA, ECDH, and ECDSA. Adversaries with enough storage can harvest encrypted traffic today and decrypt it later. If you're protecting data with 20-year sensitivity lifespans, you're already in the harvest window.
The urgency is correct about starting now, not migration, but discovery and planning. The gap between needing PQC and deploying it spans years of inventory, testing, procurement, and integration work. Agencies that wait until quantum computers are operational have already lost critical data.
Move immediately on new procurements. Any system you're buying today should support PQC algorithms or have a vendor roadmap to add them. Don't lock into contracts for cryptographic infrastructure that can't evolve. Your RFPs should require PQC compatibility now, even if you won't enable it immediately.
This transition is mandatory, not optional. NIST released these algorithms because quantum computing is moving from theoretical to practical. Your compliance obligations under FISMA, DFARS 252.204-7012, and NIST SP 800-171 Rev 3 will eventually require PQC support. Starting now means you're ready when the mandate arrives.
Successful PQC transitions aren't about speed. They're about understanding what you're protecting before changing how you protect it.
