The clock is running. NIST finalized its first set of post-quantum cryptographic standards in August 2024, and the U.S. federal government has set 2027 as the target deadline for agencies and critical contractors to complete migration away from vulnerable encryption algorithms. That deadline is now less than a year away, and most enterprise IT teams are still running RSA-2048 and ECC across their core infrastructure. If your organization handles sensitive data, financial transactions, or classified communications, this is no longer a future problem — it is a present one.
Why Current Encryption Will Fail Against Quantum Computers
Today’s public-key cryptography — RSA, Diffie-Hellman, and elliptic curve cryptography (ECC) — relies on mathematical problems that classical computers cannot solve in reasonable time. Specifically, factoring large integers and computing discrete logarithms. A sufficiently powerful quantum computer running Shor’s algorithm can break these in hours, not centuries.
The threat is not purely theoretical. Adversaries are already executing harvest now, decrypt later (HNDL) attacks — intercepting and storing encrypted traffic today with the intent to decrypt it once quantum hardware matures. Intelligence agencies estimate that cryptographically relevant quantum computers (CRQCs) capable of breaking 2048-bit RSA could arrive between 2028 and 2035. The 2027 migration deadline is designed to get systems hardened before that window opens.
The algorithms at risk are everywhere: TLS handshakes on web servers, VPN tunnels, SSH keys, digital certificates, code-signing pipelines, and database encryption layers. If your infrastructure touches any of these — and it does — you have exposure.
NIST’s Approved Post-Quantum Standards: What You Need to Know
NIST has standardized three primary post-quantum cryptographic (PQC) algorithms. IT teams should understand what each does before selecting tools:
- ML-KEM (CRYSTALS-Kyber) — A key encapsulation mechanism (KEM) used for secure key exchange. This is the primary replacement for RSA and ECDH in TLS and VPN scenarios.
- ML-DSA (CRYSTALS-Dilithium) — A digital signature algorithm. Replaces RSA and ECDSA for code signing, certificate issuance, and authentication workflows.
- SLH-DSA (SPHINCS+) — A hash-based signature scheme. Slower but offers a different mathematical foundation, recommended as a secondary or fallback signature method.
A fourth algorithm, FALCON (now standardized as FN-DSA), provides compact signatures and is particularly suited for constrained environments like IoT devices or embedded systems where bandwidth and storage matter.
For most enterprise environments, the practical migration path centers on ML-KEM for key exchange and ML-DSA for signatures. Hybrid schemes — combining classical ECC with ML-KEM — are strongly recommended during the transition period to maintain backward compatibility while adding quantum resistance.
How to Audit and Prioritize Your Legacy Systems
Before touching a single config file, you need a cryptographic inventory. Most large environments have no idea where all their RSA certificates, SSH keys, and TLS configurations actually live. Start here:
- Run Venafi or Keyfactor to enumerate all certificates across your network, including expiry dates, key sizes, and algorithm types.
- Use IBM Quantum Safe Explorer or Cryptosense Analyzer to scan application code and binaries for hardcoded cryptographic calls.
- Audit VPN gateways, PKI infrastructure, HSMs (hardware security modules), and API authentication layers separately — these are commonly missed.
Once inventoried, prioritize by data sensitivity and exposure. Systems handling long-lived sensitive data — health records, financial archives, government communications — are highest priority. Public-facing TLS endpoints come next because they are the most actively harvested. Internal service-to-service authentication can follow in a second migration wave.
Document every dependency. Migrating a certificate authority (CA) without mapping downstream certificate consumers is a fast way to break production services during a maintenance window.
Practical Migration Steps IT Teams Can Execute Now
Migration does not happen all at once. A phased approach reduces risk and lets teams build expertise incrementally.
- Update your PKI: Deploy a parallel PQC-capable CA using tools like Bouncy Castle (Java) or Open Quantum Safe’s liboqs. Begin issuing hybrid certificates (X.509 with dual algorithm support) for non-critical systems first.
- Harden TLS configurations: Enable ML-KEM key exchange in your load balancers and web servers. NGINX and Apache both support PQC cipher suites through OpenSSL 3.x with the OQS provider plugin.
- Rotate SSH infrastructure: OpenSSH 9.0+ supports ML-KEM hybrid key exchange by default. Force key rotation across jump servers, CI/CD pipelines, and admin access points.
- Test, then enforce: Run PQC in hybrid mode for 60 to 90 days, monitoring for handshake failures or performance regressions. TLS performance overhead with ML-KEM is typically under 5ms per handshake on modern hardware — acceptable in almost every production context.
Budget for HSM firmware upgrades. Many hardware security modules from vendors like Thales and Entrust have PQC-ready firmware available now but require explicit update cycles and vendor coordination.
Conclusion
The 2027 deadline is firm, the threat is real, and the tools to act are already available. IT teams that start their cryptographic inventory now have enough runway to migrate cleanly. Teams that wait until late 2026 will face rushed migrations, vendor backlogs, and avoidable outages. Post-quantum cryptography is not a research topic anymore — it is an operational requirement. Start the audit this quarter.