Defense Against “Harvest Now, Decrypt Later” (HNDL) with NIST PQC Standards

10 min readFeb 25, 2026

1. Executive Summary

We are currently undertaking a critical security transition to Post-Quantum Cryptography (PQC). This initiative is driven by the strategic necessity to neutralize the “Harvest Now, Decrypt Later” (HNDL) threat — a surveillance strategy where adversaries intercept and store encrypted data today, despite lacking the ability to decrypt it immediately. They do this with the explicit intent of decrypting it retrospectively once Cryptographically Relevant Quantum Computers (CRQCs) become available.

The data most at risk includes long-lived secrets: trade secrets, biometric databases, national security intelligence, and sensitive personal infrastructure data (PII) that retains value for decades. If this data is harvested today protected only by classical algorithms (RSA, ECC), it is effectively compromised; the adversary is merely waiting for the hardware to catch up.

To mitigate this existential risk to data confidentiality, we are adopting the NIST FIPS 203 (ML-KEM) standard via a Hybrid Key Exchange strategy. This approach is conservative and robust: it does not recklessly discard proven traditional cryptography. Instead, it performs two simultaneous key exchanges — one using classical Elliptic Curve Diffie-Hellman (X25519) and one using the quantum-resistant Module-Lattice-Based Key-Encapsulation Mechanism (ML-KEM). The final session key is derived by mathematically combining the shared secrets of both. This ensures that even if the new PQC algorithms are found to contain a mathematical flaw, our communications remain as secure as they are today, protected by the classical X25519 shield.

2. Risk Classification Guidance (Mosca’s Theorem)

Not all data requires immediate PQC migration, and attempting to migrate everything simultaneously is operationally impossible. To prioritize our efforts, we utilize Mosca’s Theorem of Risk, a foundational framework for quantum risk assessment.

The risk condition is defined by the inequality:

(X + Y) > Z

Where:

X = Shelf Life: The duration for which the data must remain confidential (e.g., Session Token = 1 hour; Mortgage Contract = 30 years; DNA data = Lifetime).
Y = Migration Time: The time required to inventory, test, and deploy PQC across our infrastructure. This includes updating hardware security modules (HSMs), sidecars, and legacy codebases.
Z = Time to Collapse: The time remaining until a CRQC is available to adversaries. This is generally defined as within the strategic planning horizon of nation-state adversaries (often modeled as 10–15 years).

The Danger Zone: If (X + Y) > Z, you have failed. You are currently generating data that will be readable by the adversary before it loses its sensitivity value.

Risk Classification Table

Risk Level: CRITICAL

Data Type: Long-Term Secrets: Trade secrets, source code repositories, biometric databases, diplomatic cables, national security intelligence.
Shelf Life (X): > 10 Years
Action Required: Immediate PQC Migration. This data is the primary target of HNDL. Every day this data traverses the public internet without PQC, the risk of future exposure increases.

Risk Level: HIGH

Data Type: Regulated Data: Financial records (GLBA), PII (GDPR), Health Data (HIPAA), Legal contracts.
Shelf Life (X): 5–10 Years
Action Required: Plan & Pilot. We must enable PQC on public-facing edges (WAF/CDN) immediately to protect the transport layer, even if internal backend migration is phased.

Risk Level: LOW

Data Type: Ephemeral Data: Session cookies, marketing analytics, ephemeral application logs, public web content.
Shelf Life (X): < 1 Year
Action Required: Monitor. Standard hardware and OS refresh cycles will likely introduce PQC support naturally before Z occurs. No emergency engineering resource allocation is needed.

3. The Solution: NIST PQC Standards

After a multi-year global competition involving rounds of intense cryptanalysis, NIST finalized the first set of PQC standards in August 2024. These algorithms rely on Lattice-based cryptography, a branch of mathematics involving grid-like structures that are believed to be resistant to both classical and quantum attacks.

Standard: FIPS 203

Algorithm: ML-KEM (formerly Kyber)
Role: Key Establishment
Implementation: Priority 1 (Critical). This is the shield against HNDL. It is used to negotiate the symmetric keys that encrypt the actual data tunnel (TLS, SSH, VPN). We specifically target ML-KEM-768 as the balance between security and performance.

Standard: FIPS 204

Algorithm: ML-DSA (formerly Dilithium)
Role: Digital Signatures
Implementation: Priority 2. Protects against identity spoofing (Authentication). While critical, HNDL does not target signatures (signatures are public). Migration here is complex due to larger key sizes.

Standard: FIPS 205

Algorithm: SLH-DSA (formerly SPHINCS+)
Role: Backup Signatures
Implementation: Priority 3. A hash-based signature scheme. It is slower and produces larger signatures than ML-DSA but relies on different math. It serves as a “backup parachute” for long-term document signing.

3.1 Understanding Hybrid Safety (The “Combiner”)

It is critical to understand that Hybrid TLS is not a failover mechanism where the system “falls back” to classical crypto if PQC fails. It is a combinatorial security model that requires the adversary to solve two mathematically distinct hard problems.

Exchange 1 (Classical): The client and server generate a shared secret (S_{ecc}) using X25519. This relies on the Discrete Logarithm Problem.
Exchange 2 (Post-Quantum): The client and server generate a shared secret (S_{pqc}) using ML-KEM. This relies on the Module Learning-With-Errors (ML-LWE) problem.
Derivation: The TLS 1.3 Key Derivation Function (KDF) concatenates or mixes both secrets: SessionKey = KDF(S_{ecc} || S_{pqc})

Security Guarantee: An attacker must break BOTH the X25519 and the ML-KEM math to recover the session key.

If a quantum computer breaks X25519, the session is protected by ML-KEM.
If a mathematical flaw is found in ML-KEM (as happened to SIKE), the session is protected by X25519.

3.2 Architecture: PQC Termination Strategy

The primary HNDL threat exists on the Public Internet (Untrusted Zone), where traffic passes through ISPs, undersea cables, and backbone routers that may be subject to tapping. Therefore, our strategy focuses on terminating PQC at the Edge.

graph LR
    %% Nodes
    Client(("👤 Client Browser<br/>(Chrome/Edge)"))
    Internet{{"☁️ Public Internet<br/>(Harvesting Zone)"}}
    WAF["🛡️ Edge WAF / CDN<br/>(Cloudflare / Akamai / AWS)"]
    Origin["⚙️ Origin Server<br/>(Nginx / Envoy / App)"]

    %% Edges
    Client -- "🔒 Hybrid PQC TLS 1.3<br/>(Secrets Combined: X25519 + ML-KEM)" --> Internet
    Internet --> WAF
    
    subgraph "Trusted Private Network"
        WAF -- "Standard TLS 1.3<br/>(Or PQC if supported)" --> Origin
    end

    %% Styling
    style Internet fill:#ffcccc,stroke:#cc0000,stroke-width:2px,color:black
    style WAF fill:#ccffcc,stroke:#006600,stroke-width:2px,color:black
    style Client fill:#e6f3ff,stroke:#333,stroke-width:1px,color:black
    style Origin fill:#e6f3ff,stroke:#333,stroke-width:1px,color:black

The Termination Gap: While we terminate PQC at the WAF, the connection from the WAF to the Origin often remains standard TLS 1.3 (X25519 only). This is an acceptable risk for the “High” category because the traffic is contained within a controlled VPC or private network, significantly raising the bar for a “Harvesting” attack. For “Critical” data, end-to-end PQC is required.

4. Critical Dependency: OpenSSL Version

⚠️ Important: Web server configurations (Nginx/Apache) do not implement PQC themselves; they rely entirely on the cryptographic primitives provided by the underlying OpenSSL library. Most default OS repositories (e.g., Ubuntu 22.04 LTS, RHEL 9) ship with OpenSSL 3.0, which does not support these algorithms.

Requirement

You must use:

OpenSSL 3.2+ compiled with the OQS (Open Quantum Safe) Provider.
OR OpenSSL 3.4+ (Released late 2025) which includes native support for FIPS 203.
Verification: Before deploying any config, run the following on your server to verify library support: openssl list -groups
Success: The output must include x25519_mlkem768, kyber768, or X25519MLKEM768.
Failure: If these are missing, Nginx will fail to start or silently ignore the PQC directives, leaving you vulnerable.

5. Implementation: Web Servers & Proxies

Nginx Configuration

Prerequisite: Nginx must be compiled against OpenSSL 3.2+ w/ OQS or 3.4+.

server {
    listen 443 ssl;
    server_name internal-api.example.com;

    # 1. Force TLS 1.3
    # PQC key shares are exchanged as TLS 1.3 extensions. 
    # Attempting this with TLS 1.2 is complex and generally unsupported.
    ssl_protocols TLSv1.3;

    # 2. Hybrid PQC Curve Preference
    # This directive tells Nginx to prefer the hybrid group.
    # The syntax "GroupA:GroupB" defines the priority order.
    # Clients that support PQC will match the first group.
    # Legacy clients (older browsers/bots) will skip it and match X25519.
    ssl_ecdh_curve X25519MLKEM768:X25519;
    
    # Standard security headers
    add_header Strict-Transport-Security "max-age=63072000" always;
    
    # ... certs and other configs ...
}

Apache HTTP Server

Requires mod_ssl linked against modern OpenSSL.

<VirtualHost *:443>
    ServerName app.example.com
    
    # Enable TLS 1.3 explicitly
    SSLProtocol all -SSLv3 -TLSv1 -TLSv1.1 -TLSv1.2

    # Prioritize Hybrid PQC curves
    # The SSLOpenSSLConfCmd allows us to pass configuration directly to the 
    # OpenSSL context, bypassing Apache's abstraction layer if necessary.
    SSLOpenSSLConfCmd Curves X25519MLKEM768:X25519
</VirtualHost>

Envoy Proxy (Kubernetes / Istio)

Envoy builds usually bundle BoringSSL, Google’s fork of OpenSSL, which includes aggressive PQC support.

transport_socket:
  name: envoy.transport_sockets.tls
  typed_config:
    "@type": [type.googleapis.com/envoy.extensions.transport_sockets.tls.v3.DownstreamTlsContext](https://type.googleapis.com/envoy.extensions.transport_sockets.tls.v3.DownstreamTlsContext)
    common_tls_context:
      tls_params:
        # PQC is strictly a TLS 1.3 feature in most implementations
        tls_minimum_protocol_version: TLSv1_3
        ecdh_curves:
          # Primary: The Hybrid group (Quantum-Safe)
          - X25519MLKEM768
          # Fallback: Standard X25519 for compatibility
          - X25519

6. Implementation: Cloud & Edge

Leveraging Cloud Providers is the fastest way to achieve HNDL compliance, as they handle the complex library upgrades.

AWS Application Load Balancer (ALB) & Network Load Balancer (NLB)

Status: Available since November 2025. Action: This is Opt-In. AWS preserves backward compatibility aggressively, so existing load balancers will not auto-upgrade to PQC. You must explicitly update your Listener’s Security Policy.

Policy Name: Look for policies ending in -PQ-2025-09 or similar (e.g., ELBSecurityPolicy-TLS13-1-3-Res-PQ-2025-09).
Reference: AWS Announcement: ALB/NLB Support for Post-Quantum Key Exchange

CDN / WAF Providers

Provider: Cloudflare

Configuration Steps: Dashboard: SSL/TLS > Edge Certificates > Post-quantum key agreement (Toggle ON).
Technical Notes: Usually enabled by default. Cloudflare uses X25519MLKEM768. Verify specifically that your "Minimum TLS Version" is not interfering, though TLS 1.3 negotiation usually overrides lower bounds.

Provider: Akamai

Configuration Steps: Property Manager: Add Rule > Behavior > “Post Quantum Cryptography Client to Edge”.
Technical Notes: Requirement: You must also enable TLS 1.3 in the property settings. Akamai allows granular control to enable this only for specific geographies or paths.

Provider: Imperva

Configuration Steps: Automatic: Generally enabled by default for all sites supporting TLS 1.3.
Technical Notes: Go to Website Settings > General to verify. Imperva treats this as a platform-wide security update.

7. Strategic Considerations

Crypto Agility

We cannot assume ML-KEM is the “final” answer. Mathematical attacks against lattices could be discovered next year.

Definition: The ability to replace cryptographic primitives (algorithms) without recompiling applications or redesigning infrastructure.
Strategy: The Hybrid Mode is our primary agility mechanism. Because the secrets are combined, if ML-KEM is mathematically broken, we remain protected by the X25519 component of the key. We do not need to “switch” protocols in an emergency; the classical shield remains intact.
Application Logic: Do not hardcode “ML-KEM” or specific key sizes in your application logic. Use abstraction layers (like javax.crypto in Java or crypto/tls in Go) and rely on configuration files to select algorithms.

Limiting Session Duration (Defense in Depth)

This guidance is particularly relevant for long-lived tunnels such as VPN concentrators, database connections, or service mesh control planes.

Recommendation: Enforce hard limits on absolute session duration (e.g., force re-authentication/re-handshake every 12 hours).
Impact: While TLS 1.3 already provides Perfect Forward Secrecy (PFS) via ephemeral ECDHE, limiting the duration of any single session minimizes the data exposure window should a specific handshake be retroactively compromised. By forcing frequent re-keying, we ensure that an adversary must expend quantum computing resources to break multiple handshakes to decrypt a continuous stream of data, rather than breaking a single handshake to expose months of traffic.

What PQC Does NOT Protect Against

Migrating to ML-KEM fixes the mathematical vulnerability to quantum computers, but it does not fix:

Implementation Bugs: A buffer overflow in the PQC library is still a vulnerability. Given that PQC libraries are newer, they are arguably more prone to implementation bugs than mature libraries like OpenSSL’s ECC implementation.
Side-Channel Attacks: Power analysis or timing attacks on the hardware performing the PQC math can leak the private key.
Metadata Analysis: Adversaries can still see who is talking to whom, the size of the data, and the timing, even if they can’t decrypt the payload.
Endpoint Compromise: If the server OS is hacked, encryption is irrelevant.

8. Internal PKI Migration Strategy (Authentication)

While HNDL specifically targets Confidentiality (Key Exchange), our Internal Public Key Infrastructure (PKI) manages Authentication (Signatures). Migrating PKI is critical to prevent identity spoofing in the quantum era, though it is a distinct project from HNDL defense.

The Algorithm: FIPS 204 (ML-DSA)

We will transition internal x.509 certificates from RSA/ECDSA to ML-DSA (Dilithium). The primary constraint is signature size, which varies significantly by security level:

ML-DSA-44 (NIST Level 2): ~2,420 bytes
ML-DSA-65 (NIST Level 3): ~3,293 bytes
ML-DSA-87 (NIST Level 5): ~4,595 bytes
Comparison: A typical ECDSA signature is only ~64 bytes.

Network Impact: A full PQC certificate chain may exceed the Initial Congestion Window (IW) of TCP (usually ~14KB), causing extra round-trips and increased latency, particularly on mobile networks or high-latency links.

Recommended Strategy: Parallel PKI

Do not attempt to issue “Hybrid Certificates” (single certificates containing both RSA and ML-DSA keys) for internal apps unless the software stack explicitly supports it. The standards for hybrid certificates are still in flux.

Parallel Roots: Stand up a new PQC Root CA alongside the existing Classical Root CA.
Dual Issuance: Workloads should obtain two separate certificates (one Classical, one PQC).
Negotiation: The server presents the appropriate certificate chain based on the ClientHello extensions, where supported by the TLS stack. If the client supports PQC, it sends the PQC chain. If not, it sends the RSA/ECC chain.

Hardware Dependencies

Warning: Existing Hardware Security Modules (HSMs) and tokens (e.g., older YubiKeys, Smartcards) often lack the memory or firmware support for PQC key generation.

Action: Inventory all physical tokens and HSMs. Plan for hardware refresh cycles. FIPS 204 stateful hash-based signatures (FIPS 205) are particularly difficult for simple smartcards to manage.

9. Verification Guide

To verify that your server is correctly configured and negotiating the hybrid key exchange, use a modern OpenSSL client (3.2+ w/ OQS).

Get Namchoke Kaewkhat’s stories in your inbox

Join Medium for free to get updates from this writer.

Remember me for faster sign in

Command Line Test:

# Force the client to advertise ONLY the PQC hybrid group 
# If the server is not configured correctly, this connection will fail. 

openssl s_client -connect your-domain.com:443 -groups X25519MLKEM768 -tls1_3

Expected Output:

You should look for the Server Temp Key line in the SSL Session details.

... SSL-Session:     
Protocol  : TLSv1.3     
Cipher    : TLS_AES_256_GCM_SHA384     
# The presence of this line confirms PQC negotiation     
Server Temp Key: X25519MLKEM768  <-- CONFIRMED ...

Browser Verification (Chrome/Edge):

Open Developer Tools (F12).
Navigate to the Security tab.
Click on the main origin.
Look at the Key Exchange field.

✅ Secure: X25519MLKEM768 (or X25519Kyber768 for older drafts).
⚠️ Standard: X25519 (Classical only).

Namchoke Kaewkhat