Harvest Now, Decrypt Later: Preparing Your Certificate Infrastructure for Post-Quantum Cryptography

For decades, the security of the internet has rested on a mathematical assumption: that factoring large prime numbers is too computationally expensive for any computer to achieve in a reasonable timeframe. Algorithms like RSA and Elliptic Curve Cryptography (ECC) have successfully protected our Public Key Infrastructure (PKI), securing everything from web traffic and VPNs to digital identities and software updates.

But the countdown clock on traditional cryptography has started.

While a Cryptographically Relevant Quantum Computer (CRQC) capable of breaking RSA-2048—an event often referred to as "Q-Day"—is still estimated to be a decade away, the threat to your infrastructure is immediate. Threat actors are currently engaging in "Harvest Now, Decrypt Later" (HNDL) attacks. They are actively intercepting and storing encrypted network traffic today, waiting for the day quantum computers become available to decrypt it.

If you are managing infrastructure, DevOps pipelines, or security operations, 2025 marks the shift from theoretical planning to active implementation. With the U.S. National Institute of Standards and Technology (NIST) officially finalizing the first Post-Quantum Cryptography (PQC) standards in August 2024, the race to upgrade global PKI has begun.

Here is your comprehensive guide to understanding the new standards, the impact PQC will have on your certificate infrastructure, and the practical steps you must take to achieve crypto-agility.

The NIST Post-Quantum Standards: What You Need to Know

In August 2024, NIST released three finalized Federal Information Processing Standards (FIPS) designed to withstand quantum attacks. These algorithms are based on complex mathematical structures like lattice-based cryptography, which quantum computers cannot easily solve.

Understanding these standards is the first step in mapping out your infrastructure upgrades:

1. FIPS 203 (ML-KEM, formerly CRYSTALS-Kyber): This is the primary standard for Key Encapsulation Mechanisms (KEM). It is used to establish a shared secret over a public network. In the context of your infrastructure, this is the algorithm that will secure the TLS handshakes between your users and your load balancers.
2. FIPS 204 (ML-DSA, formerly CRYSTALS-Dilithium): The primary standard for digital signatures. This is the algorithm that will replace RSA and ECC in your X.509 certificates, ensuring that a server or software package is authenticated.
3. FIPS 205 (SLH-DSA, formerly SPHINCS+): A fallback digital signature standard based on hash functions. It is larger and slower than ML-DSA but serves as a cryptographic backup plan in case vulnerabilities are discovered in lattice-based cryptography.

A fourth standard, FN-DSA (formerly FALCON), is expected to be finalized in late 2025 for use cases requiring smaller signature sizes.

How PQC Breaks Traditional PKI Architectures

Transitioning to post-quantum cryptography is not as simple as updating a cipher suite in your Nginx or HAProxy configuration. It is a fundamental architectural shift that introduces significant engineering challenges.

The Certificate Size Problem

PQC algorithms require significantly larger key sizes and signature sizes compared to RSA and ECC. For context, a standard RSA-2048 signature is 256 bytes. An ML-DSA signature (FIPS 204) is roughly 2.4 Kilobytes—nearly ten times larger.

When you factor in the entire certificate chain (Root CA, Intermediate CA, and Leaf Certificate), the total size of the certificates transmitted during a TLS handshake increases dramatically. This impacts TLS handshake latency, increases network bandwidth consumption, and poses severe challenges for constrained IoT devices with limited memory.

Hardware Security Module (HSM) Limitations

If your organization operates an internal Certificate Authority (CA), your Root and Intermediate private keys are likely stored in Hardware Security Modules (HSMs). Many legacy HSMs lack the memory and processing power required to generate or store PQC keys. Transitioning to FIPS 203/204 will require significant HSM firmware updates or complete hardware replacements.

The Migration Strategy: Hybrid Cryptography

Because pure PQC infrastructure is not yet universally supported by all clients, browsers, and network appliances, the industry consensus for the transition period (2025–2030) is the Hybrid Cryptography approach.

A Hybrid X.509 Certificate contains two sets of public keys and signatures: one classical (e.g., RSA or ECC) and one post-quantum (e.g., ML-DSA).

How it works in practice:
When a client connects to your server, the TLS 1.3 handshake negotiates the best available cipher suite.
* If the client (like a modern version of Google Chrome) supports PQC, the server and client will use the post-quantum elements to secure the connection.
* If the client is a legacy application, the connection gracefully falls back to the classical RSA/ECC elements.

This ensures backward compatibility while providing immediate quantum resistance for modern clients, effectively neutralizing the "Harvest Now, Decrypt Later" threat for supported traffic.

TLS 1.3 Integration Phases

The transition within TLS is happening in two distinct phases:
1. Hybrid Key Exchange (Available Now): Securing the session key using algorithms like X25519Kyber768 (a hybrid of standard elliptic curve X25519 and the post-quantum Kyber algorithm).
2. PQC Authentication (In Progress): Authenticating the server using PQC digital certificates. This is more complex as it requires your entire PKI chain, including Root CAs, to be updated.

Hands-On: Testing PQC in Your Infrastructure Today

You don't have to wait for commercial vendors to start experimenting with PQC. The Open Quantum Safe (OQS) project provides an open-source C library (liboqs) and an OpenSSL provider that allows you to generate PQC certificates and test TLS connections right now.

Here is how you can set up a PQC sandbox to test how ML-DSA certificates behave in your environment.

Prerequisites

You will need an environment with OpenSSL 3.0+ and the oqs-provider installed. (Many modern Linux distributions offer this via package managers, or you can compile it from the OQS GitHub repository).

Step 1: Generate a Post-Quantum Key Pair

First, we will generate a private key using the ML-DSA algorithm (often still referenced by its original name, Dilithium, in cryptographic libraries).

# Generate an ML-DSA-44 (Dilithium2) private key
openssl genpkey -algorithm dilithium2 -out pqc_private_key.pem -provider oqsprovider -provider default

Step 2: Create a Post-Quantum X.509 Certificate

Next, generate a Certificate Signing Request (CSR) and a self-signed certificate using your new post-quantum key.

# Generate the self-signed PQC certificate
openssl req -x509 -new -key pqc_private_key.pem -out pqc_cert.pem -days 365 \
  -subj "/C=US/ST=Tech/L=Cloud/O=PQC Sandbox/CN=pqc-test.internal" \
  -provider oqsprovider -provider default

If you inspect this certificate using openssl x509 -in pqc_cert.pem -text -noout, you will notice the massive size of the public key and signature compared to a standard RSA certificate.

Step 3: Test a Post-Quantum TLS 1.3 Connection

You can use OpenSSL's built-in server to test a hybrid TLS connection.

Start the test server:

openssl s_server -cert pqc_cert.pem -key pqc_private_key.pem -www -tls1_3 -provider oqsprovider -provider default

In a separate terminal, connect to the server forcing a hybrid key exchange (X25519 + Kyber768):

openssl s_client -connect localhost:4433 -groups x25519_kyber768 -provider oqsprovider -provider default

By running this sandbox, DevOps teams can capture the network traffic via Wireshark and analyze the exact impact the larger certificate size has on packet fragmentation and handshake latency.

Step-by-Step: Preparing Your Infrastructure for PQC

Regulatory bodies are forcing the timeline. The NSA's Commercial National Security Algorithm Suite 2.0 (CNSA 2.0) mandates that systems must begin transitioning to PQC by 2025. Here is the actionable roadmap to get your infrastructure ready.

1. Create a Cryptographic Bill of Materials (CBOM)

You cannot migrate what you cannot see. The biggest hurdle organizations face in PKI migration is "shadow cryptography"—certificates generated by rogue development teams, hardcoded RSA keys in legacy microservices, and forgotten internal Root CAs.

Before you can adopt PQC, you must implement continuous certificate discovery. This is where tools like Expiring.at become critical infrastructure. By tracking every certificate across your environments, their issuing algorithms, and their expiration dates, you build a living CBOM. Knowing exactly when your current RSA-2048 certificates are due for renewal allows you to strategically plan their replacement with hybrid PQC certificates, rather than reacting