Planning Your Migration to Post-Quantum Standards

Migrating cryptographic infrastructure is not a short-term project. Large organizations take 10-15 years to fully update all systems. NIST estimates that quantum computers capable of breaking RSA-2048 could exist within 10-30 years. Given the harvest-now-decrypt-later threat and long migration timelines, organizations must begin planning today, even if the immediate quantum threat seems distant.

Crypto-agility means designing systems so that cryptographic algorithms can be swapped out without redesigning the entire architecture. An agile system centralizes algorithm selection in configuration, uses abstract key types, and decouples protocol logic from specific cipher implementations. Systems that hardcode RSA or ECDH in their protocol logic will require far more expensive migrations than agile ones.

The first step of migration is cataloging every cryptographic primitive in your system: where RSA, ECDH, ECDSA, and symmetric algorithms are used, in what contexts (TLS, code signing, data-at-rest encryption, authentication tokens), and what data lifetimes are involved. NIST IR 8547 and CISA guidance recommend using automated discovery tools to find hardcoded keys and algorithm identifiers in codebases and configurations.

TLS 1.3 supports hybrid key exchange combining X25519 and ML-KEM-768, specified in IETF draft-ietf-tls-hybrid-design. The hybrid NamedGroup X25519MLKEM768 sends both classical and PQC key shares in the ClientHello. The shared secret is the hash of both outputs. This requires zero protocol changes for servers that support the new NamedGroup and is backward compatible with clients that don't.

NIST IR 8413 (2022) provides migration guidance for post-quantum cryptography. It categorizes systems into three zones: immediately critical (long-lived secrets that face harvest-now-decrypt-later risk), medium-term (data with 5-10 year sensitivity), and low-priority (ephemeral or short-lived data). NIST recommends prioritizing PKI and certificate infrastructure, as changing root certificates affects entire trust chains.

The harvest-now-decrypt-later (HNDL) threat is the most urgent reason to deploy post-quantum encryption immediately, even before quantum computers exist. Adversaries (nation-states) record encrypted traffic today with the expectation of decrypting it once a quantum computer is available. Data with long-term sensitivity (medical records, state secrets, financial data with multi-decade relevance) is at immediate risk from this attack.

Based on the HNDL threat, the highest priority for post-quantum migration is protecting data with long confidentiality requirements. TLS ephemeral key exchange (ECDHE) should be upgraded to hybrid X25519+ML-KEM immediately. Long-lived RSA private keys (used for certificate signing or stored encrypted data) need re-encryption under post-quantum schemes. Ephemeral session keys for streaming video are low priority since they have no long-term value.

Before deploying PQC, organizations should benchmark the performance impact on their specific workloads. ML-KEM is fast: key generation and encapsulation take under 20 microseconds on modern hardware. However, increased key and ciphertext sizes (ML-KEM-768: 1184 + 1088 bytes vs X25519: 32 + 32 bytes) increase TLS handshake sizes. For high-volume TLS servers handling millions of connections per second, this bandwidth overhead must be measured.

The Open Quantum Safe (OQS) project provides liboqs, an open-source library implementing PQC algorithms including all NIST standards. OQS also provides forks of OpenSSL and BoringSSL that add PQC support, and a test server at test.openquantumsafe.org. Organizations can use liboqs to prototype and test PQC integration before production deployment without waiting for mainline library support.

US federal agencies and regulated industries must use FIPS-validated cryptographic modules. NIST FIPS 203, 204, and 205 are now published but validated implementations (with CMVP certificates) take additional time to appear. NIST is running an accelerated validation program for PQC. Organizations in regulated environments should track CMVP validation status and plan for a period where hybrid classical+PQC deployments use FIPS-validated classical algorithms alongside validated PQC implementations.

Migrating PKI is particularly complex. Root certificates and intermediate CAs need to be re-issued with ML-DSA or hybrid keys. Certificate chains grow larger (ML-DSA-65 certificates are approximately 4 KB vs 1 KB for RSA-2048). Browser trust stores, mobile OS trust stores, and embedded device trust stores all need updating. Some organizations are exploring dual-algorithm certificates (hybrid PKI) to maintain backward compatibility during the transition.

Which type of data is the HIGHEST priority for post-quantum encryption migration due to the harvest-now-decrypt-later threat?

PQC migration requires crypto-agility, a complete cryptographic inventory, and priority based on data lifetime. The harvest-now-decrypt-later threat makes immediate deployment of hybrid TLS (X25519+ML-KEM-768) urgent for long-lived secrets. Performance overhead is manageable for most workloads. liboqs enables testing before mainline library support. FIPS compliance requires tracking CMVP validation status of PQC implementations.