Post-Quantum Cryptography for TLS and VPN: The Practical Deployment Guide for Network Security Teams in 2026
The Post-Quantum Cryptography TLS VPN deployment is not a future planning exercise. It is the most operationally actionable step available to network security teams in 2026 — and it can be completed for internet-facing services within weeks, not months. Cloudflare has deployed hybrid ML-KEM + X25519 key exchange across its global network and upgraded more than six million customer domains to post-quantum TLS by default[1]. Chrome (version 131), Firefox (version 135), and Go 1.24 all enable hybrid ML-KEM TLS natively, meaning that for organizations running modern TLS infrastructure, quantum-safe key exchange is often a configuration change, not a rebuild.
The reason TLS key exchange is the correct starting point — before PKI migration, before certificate authority changes, before HSM upgrades — is structural. In TLS, the key exchange establishes the session secret that protects data in transit.
A nation-state adversary conducting an HNDL operation captures the full TLS session — handshake and ciphertext — and can later apply Shor’s algorithm to recover the classical ECDH session key and decrypt the session content.
The signature (the certificate) only authenticates the handshake at the time it occurs; it cannot be retroactively exploited[2]. This asymmetry makes hybrid TLS key exchange the immediate priority and PKI signature migration the follow-on phase.
For the full 6-phase migration program that this deployment fits within, see the companion guide: [20004C] – Post-Quantum Cryptography Migration Roadmap (PQC): The Complete 6-Phase Enterprise Implementation Guide for 2026
⚠ Technical Disclaimer: This article is for educational and informational purposes only. It does not constitute professional cybersecurity, cryptographic, or legal advice. Organizations should engage qualified professionals before implementing cryptographic changes.
Hybrid TLS Deployment — The X25519MLKEM768 Configuration Guide
The IETF standard governing hybrid TLS key exchange is draft-ietf-tls-ecdhe-mlkem (draft version 04, February 2026), co-authored by PQShield, AWS, and Cloudflare[3]. It defines three hybrid key agreement mechanisms for TLS 1.3: X25519MLKEM768 (recommended for most deployments), SecP256r1MLKEM768, and SecP384r1MLKEM1024. The hybrid construction derives the final session key by combining the shared secrets from both the classical and post-quantum exchanges using a Key Derivation Function — an attacker must break both algorithms simultaneously to compromise the session.
OpenSSL 3.5, released in April 2025, includes native support for ML-KEM and the X25519MLKEM768 hybrid group in its default provider — no external OQS provider extension required[4]. The hybrid key agreement increases TLS ClientHello size, causing the handshake to split across two packets. Cloudflare documented this split ClientHello behavior and uses the TLS 1.3 HelloRetryRequest mechanism to handle middleboxes that do not correctly process multi-packet ClientHello messages[5]. The OpenSSL Foundation benchmarked the handshake overhead at approximately 2–2.5ms additional latency compared to classical TLS — a figure that is effectively negligible with TLS session resumption in place [4].
Table 1: Post-quantum TLS hybrid deployment configuration guide — component, recommended configuration, vendor stack, HNDL protection level, and compatibility notes.
| Component | Recommended Config | Vendor / Stack | HNDL Protection | Notes / Compatibility Risk |
| TLS Library | OpenSSL 3.5 — native ML-KEM + X25519 hybrid (X25519MLKEM768) | OpenSSL 3.5; BoringSSL (Cloudflare); Go 1.24 TLS stack | Immediate — all new TLS sessions protected from HNDL collection | OpenSSL 3.5 released April 2025; Go 1.23 used draft Kyber (incompatible with finalized ML-KEM); verify version alignment across fleet |
| Web Server / Reverse Proxy | NGINX compiled against OpenSSL 3.5; cipher group: X25519MLKEM768 | NGINX Plus R33+; Apache (OQS provider); Caddy (Go 1.24) | High — edge-to-client conversations protected immediately | Nginx Plus R33 supports the final ML-KEM-768 spec natively; Apache requires manual OQS provider compilation |
| CDN / Edge Layer | X25519+ML-KEM768 is enabled by default on all edge nodes | Cloudflare (default); Fastly (configurable); Akamai (in roadmap) | Maximum — 6M+ domains upgraded automatically by Cloudflare in 2025 | Cloudflare: enabled for all customers by default since 2025; verify origin server supports split ClientHello before enabling |
| Load Balancer / API Gateway | Hybrid TLS cipher group priority: X25519MLKEM768 first | AWS ALB (PQC TLS mode); Azure App Gateway (roadmap) | High — protects traffic between clients and backing services | AWS has enabled hybrid ML-KEM in KMS and selected services; confirm your LB firmware/version supports IETF draft-ietf-tls-ecdhe-mlkem |
| Browser Clients | Supported natively: X25519MLKEM768 in Chrome 131+, Firefox 135+, Edge, Brave | Chrome (v131, Nov 2024); Firefox (v135, Feb 2025); Safari (iOS 26 / 2026) | High for new sessions; legacy browsers fall back to classical TLS | Verify no ClientHello packet fragmentation issues at middleboxes; Cloudflare uses HelloRetryRequest to handle ossified middleboxes |
For teams asking about NGINX post-quantum cryptography setup with OpenSSL 3.5: compile NGINX against OpenSSL 3.5, add ssl_ecdh_curve X25519MLKEM768:X25519 to your server block, and verify with openssl s_client -connect hostname:443 — Look for ‘Negotiated group: X25519MLKEM768’ in the output.
Post-Quantum Cryptography For VPN Deployment — IKEv2 Hybrid Key Exchange via RFC 9370
VPN infrastructure presents a structurally different deployment challenge than TLS. Where TLS key exchange migration is typically a server configuration change, IPsec IKEv2 VPN migration requires that both endpoints — site-to-site peers, or client and gateway — negotiate the same post-quantum key exchange mechanism. The protocol framework that enables this without replacing the classical IKEv2 exchange is RFC 9370 (Multiple Key Exchanges in IKEv2), which allows up to seven additional key exchanges to run alongside the classical Diffie-Hellman Phase 1 negotiation[6]. The ML-KEM key exchange is carried in the IKE_INTERMEDIATE exchange (RFC 9242), allowing larger key sizes — ML-KEM-768 produces a 1,184-byte public key — to be fragmented and transmitted without causing IP-layer fragmentation of the initial IKE_SA_INIT message.
Cloudflare extended its hybrid ML-KEM deployment to IPsec in February 2026, following the draft-ietf-ipsecme-ikev2-mlkem-05 specification[7]. Cloudflare’s CEO noted that this upgrade required no hardware changes or complex configuration — it was deployed via software update to the Cloudflare One Appliance (version 2026.2.0)[7]. Fortinet FortiOS 7.6+, Check Point (with ML-KEM-768 as the default additional key exchange in its hybrid profile), and strongSwan v6.0 all support RFC 9370 hybrid IKEv2 in 2026. Palo Alto Networks currently implements quantum resistance via RFC 8784 pre-shared keys (PPKs) as an interim mechanism, with native ML-KEM support in its product roadmap.
Table 2: Post-Quantum Cryptography For deployment guide — VPN type, applicable RFC framework, hybrid configuration, and vendor support status in 2026.
| VPN Type | PQC Standard / RFC | Hybrid Configuration | Vendor Support in 2026 |
| IPsec / IKEv2 (Site-to-Site VPN) | RFC 9370 (Multiple Key Exchanges) + draft-ietf-ipsecme-ikev2-mlkem-05 | Classical IKEv2 Phase 1 DH + ML-KEM-768 (ADDKE1) via IKE_INTERMEDIATE exchange (RFC 9242) | Fortinet FortiOS 7.6+; Check Point (Kyber768 default); strongSwan v6.0+; Palo Alto PAN-OS (RFC 8784 PPK + ML-KEM in roadmap) |
| SSL VPN / Web-based VPN | TLS 1.3 with X25519MLKEM768 hybrid key exchange | Same as TLS hybrid deployment; SSL VPN gateway must run OpenSSL 3.5 or equivalent PQC-capable TLS stack | Cloudflare One Appliance (v2026.2.0); Cloudflare SASE (IPsec + TLS); Palo Alto GlobalProtect (roadmap) |
| SD-WAN Tunnels | TLS 1.3 or IPsec IKEv2. Depending on vendor implementation | Hybrid key exchange on all tunnel endpoints; vendor algorithm negotiation must support X25519MLKEM768 | Cloudflare Magic WAN (ML-KEM deployed March 2026); Cisco SD-WAN (in development); Fortinet SD-WAN (via FortiOS 7.6+ IKEv2 PQC) |
| Remote Access VPN (Client-based) | IKEv2 RFC 9370 + ML-KEM for key exchange; ML-DSA for authentication (in draft) | Classical DH IKE_SA_INIT + ML-KEM via ADDKE; PPK (RFC 8784) as interim quantum resistance | strongSwan v6.0 (ML-KEM IKEv2); WireGuard (PQC research stage — no finalized standard yet); OpenVPN (in development for ML-KEM key exchange) |
CNSA 2.0 note for VPN: NSS environments must use ML-KEM-1024 (not ML-KEM-768) for VPN key exchange per CNSA 2.0 requirements. ML-KEM-1024’s 1,568-byte key size exceeds the capacity of the initial IKE_SA_INIT exchange and must be carried in the IKE_INTERMEDIATE phase. Verify that your VPN vendor’s RFC 9370 implementation correctly handles ML-KEM-1024 key sizes in the intermediate exchange.
Why Key Exchange Migration Comes Before Certificate PKI — The Operational Rationale
A common misconception in PQC deployment planning is that TLS certificate migration (replacing RSA or ECDSA certificates with ML-DSA) must precede or accompany key exchange migration. This is incorrect. The TLS key exchange and the TLS certificate signature protect against different threat models. The key exchange establishes the session secret; an HNDL adversary who captures the encrypted traffic can recover this secret with a quantum computer and decrypt the session.
The certificate signature authenticates the server at handshake time; a quantum computer could potentially forge a signature, but only to impersonate the server in an active attack — not to retroactively decrypt previously recorded traffic.
This asymmetry — documented explicitly in Cloudflare’s post-quantum Cryptography deployment guidance[5] — means that hybrid TLS key exchange provides immediate and complete HNDL protection for new traffic without requiring any PKI changes.
An organization can deploy X25519MLKEM768 across all its TLS endpoints today, and all traffic encrypted with that configuration from that point forward is HNDL-protected — regardless of whether the server is using an RSA-2048 or ECDSA-P256 certificate. The certificate migration (Phase 5 of the migration roadmap) follows on a longer timeline because it requires coordination with certificate authorities, browser and OS trust stores, and the full PKI ecosystem — a process that historically takes five to seven years at large enterprises.
Deployment Readiness Checklist — Validating Your PQC TLS and VPN Configuration
Deploying hybrid TLS and VPN without validation creates a false sense of security. Protocol version mismatches — for example, Go 1.23 using the draft X25519Kyber768Draft00 identifier versus Go 1.24 using the finalized X25519MLKEM768 identifier — can silently downgrade connections to classical cryptography without error [8].
Middlebox incompatibility can cause connection failures that are misattributed to other causes. Table 3 provides eight specific validation checks that confirm your deployment is functioning as intended, with the CLI commands and pass criteria for each.
Table 3: Post-Quantum Cryptography for TLS and VPN deployment readiness checklist — eight validation checks with tools and pass criteria for each.
| Deployment Check | Tool / Method | Pass Criteria |
| TLS library version on all servers running OpenSSL | openssl version; rpm -q openssl; apt show openssl | OpenSSL 3.5.0 or later on all servers; Go 1.24+ for Go-based services |
| Negotiated TLS group on production endpoints | openssl s_client -connect <host>:443 | grep ‘Negotiated group’ | Output shows X25519MLKEM768; no classical-only fallback on primary endpoints |
| ClientHello packet size and middlebox compatibility | Wireshark capture of TLS handshake; Cloudflare HelloRetryRequest rate check | ClientHello fits within MTU or middleboxes handle split correctly; HelloRetryRequest rate < 1% of connections |
| IKEv2 VPN negotiated key exchange groups | Vendor CLI: Fortinet diagnose vpn ike gateway list; strongSwan: ipsec statusall | Output shows PQC-KEM (IKE): yes or equivalent; ML-KEM algorithm identifier in proposal output |
| Browser and client compatibility for hybrid TLS | Browser developer tools → Security tab → Connection; TLS scanner tools | Chrome 131+, Firefox 135+ confirmed; legacy browsers negotiate graceful fallback to classical TLS |
| Split ClientHello handling at load balancers | Load balancer access logs; TCP packet inspection | No connection failures attributable to split ClientHello; load balancer firmware updated if needed |
| CNSA 2.0 algorithm compliance for NSS environments | NSA CNSA 2.0 compliance review; algorithm audit against FIPS 203 CNSA profile | ML-KEM-1024 used for NSS key exchange (not ML-KEM-768); documented deviation justification if hybrid is used |
| Origin server PQC readiness (edge-to-origin path) | Cloudflare Automatic SSL/TLS scanner; origin server TLS handshake capture | Origin accepts X25519MLKEM768; Cloudflare reports PQC preferred key agreement on origin scan |
💡 For more information, explore the complete segments of our PQC Series
Counter-Arguments: Four Honest Challenges to PQC TLS and VPN Deployment
Objection: Enabling hybrid ML-KEM TLS will break connections with older clients and create support incidents — the risk outweighs the HNDL protection benefit.
Discussion: The hybrid approach is specifically designed to prevent this outcome. X25519MLKEM768 is offered as an additional cipher group in the ClientHello, not as a replacement for classical TLS. Servers and clients that do not support ML-KEM negotiate the classical X25519 group and continue connecting normally — no connection failure occurs. The only compatibility risk is with middleboxes (load balancers, firewalls, deep packet inspection proxies) that do not correctly handle a split ClientHello — a known issue that Cloudflare addressed using HelloRetryRequest. [1] Go version mismatches (1.23 vs 1.24) also create silent downgrades, not connection failures — the draft identifier changed between versions [3].
Solution: Enable X25519MLKEM768 on non-production endpoints first. Monitor HelloRetryRequest rates and connection success rates. Update the middlebox firmware before enabling on production. Verify Go version alignment across your fleet before relying on PQC negotiation.
Objection: Our VPN vendor does not yet support RFC 9370 ML-KEM — there is nothing we can do for VPN HNDL protection until vendor support arrives.
Discussion: RFC 8784 pre-shared keys (PPKs) provide an interim form of quantum resistance for IKEv2 VPNs using vendors that support them, including Palo Alto Networks. While PPKs lack forward secrecy against quantum adversaries, as ML-KEM does, they do add a symmetric quantum-resistant component to the IKEv2 key derivation, materially reducing HNDL exposure for configured tunnels [6]. Additionally, for site-to-site VPNs where traffic also transits a TLS segment (SASE architectures), hybrid TLS deployment on the TLS path provides protection even if the IPsec tunnel itself has not yet migrated.
Solution: Request your VPN vendor’s RFC 9370 ML-KEM roadmap with specific delivery dates. Deploy RFC 8784 PPKs as an interim measure where supported. For SASE architectures, prioritize TLS hybrid deployment on the segments where it is available while tracking vendor IPsec roadmap progress.
Objection: Our organization uses WireGuard, which has no finalized post-quantum support — we cannot migrate our VPN infrastructure.
Discussion: WireGuard’s post-quantum migration path is genuinely more complex than IPsec IKEv2. WireGuard’s Noise protocol framework does not currently have a finalized PQC key exchange standard, and the WireGuard development team has not published a release timeline for ML-KEM integration [6]. This is a legitimate gap. However, WireGuard tunnels typically terminate at a gateway that handles TLS for management and application traffic — hybrid TLS deployment on those TLS paths provides HNDL protection for the majority of sensitive data flows, even if the WireGuard tunnel itself remains classically protected. Research implementations of post-quantum WireGuard (using Kyber in the Noise handshake) exist but are not production-ready.
Solution: For WireGuard deployments, prioritize hybrid TLS deployment on all application and management traffic paths. Track WireGuard development releases for post-quantum handshake support. Consider migrating high-sensitivity tunnels to IPsec IKEv2 with RFC 9370 support as an interim measure.
Objection: The performance overhead of hybrid ML-KEM TLS is unacceptable for high-throughput, latency-sensitive services.
Discussion: The OpenSSL Foundation benchmarked X25519MLKEM768 hybrid handshake overhead at approximately 2–2.5ms per new connection versus classical TLS. [4] This overhead applies only to the initial TLS handshake — once the session is established, the symmetric AES-256 encryption that protects data in transit operates at the same performance as classical TLS. For services using TLS session resumption (session tickets or session IDs), the ML-KEM overhead is paid only on the initial connection and effectively amortized to near-zero across the session lifetime. Cloudflare’s production deployment of hybrid ML-KEM across millions of connections validates that this overhead is operationally acceptable for the vast majority of enterprise use cases.
Solution: Enable TLS session resumption to amortize the per-handshake ML-KEM overhead. Benchmark the specific impact in your environment before making architecture decisions — production evidence from Cloudflare and AWS consistently shows acceptable performance. Constrained embedded and IoT devices require hardware-accelerated implementations.
Knowledge Assessment: Is Your Network Infrastructure PQC-Ready?
⚠ Disclaimer: This quiz is for self-awareness only and does not constitute a professional assessment.
Knowledge Assessment Quiz: Is Your TLS and VPN Infrastructure PQC-Ready?
Q1: Why is TLS key exchange migration (Phase 3) prioritized over TLS signature migration (certificate PKI) for HNDL risk reduction?
- A) TLS signature algorithms are already quantum-safe by default in TLS 1.3
- B) Key exchange protects session secrets that adversaries can record and store today for future quantum decryption; signature authentication is verified at handshake time and cannot be retroactively exploited
- C) NIST FIPS 203 applies only to key exchange and does not cover TLS signatures
- D) Certificate PKI migration requires replacing all server hardware before the key exchange can be updated
Q2: An organization detects that its load balancer is dropping a small percentage of TLS connections after enabling X25519MLKEM768 hybrid key exchange. What is the most likely cause?
- A) ML-KEM-768 is not supported by TLS 1.3 and requires TLS 1.4 negotiation
- B) The server’s OpenSSL version is too new and incompatible with client browsers
- C) Middlebox protocol ossification is causing connection failures when the ClientHello is split across two packets due to the larger ML-KEM key share
- D) The hybrid cipher suite X25519MLKEM768 has a known implementation bug in all OpenSSL versions before 4.0
Q3: Which RFC framework enables post-quantum ML-KEM key exchange within IKEv2 IPsec VPN without replacing the classical Diffie-Hellman exchange?
- A) RFC 8784 — which defines post-quantum pre-shared keys as the only IKEv2 PQC method
- B) RFC 9370 — which extends IKEv2 to perform multiple key exchanges, including ML-KEM via IKE_INTERMEDIATE
- C) RFC 7383 — which defines IKEv2 message fragmentation needed to handle large ML-KEM key shares
- D) FIPS 203 — which mandates IKEv2 use ML-KEM-1024 exclusively in all VPN configurations
Score Interpretation:
- All correct (B, C, B): Strong PQC network deployment knowledge. Use Table 3 to audit your current TLS and VPN configurations and identify gaps before your next compliance review.
- Mostly correct: Review the TLS hybrid deployment section and the IKEv2 RFC framework — the distinction between key exchange and signature migration is the central operational concept.
- Incorrect: Return to Section 1 (why key exchange is prioritized) and Section 3 (IKEv2 hybrid deployment) before planning any network-layer PQC deployment.
FAQ
Q1: What is X25519MLKEM768, and why is it the recommended hybrid TLS configuration?
A: X25519MLKEM768 is a hybrid TLS key exchange mechanism that combines X25519 (classical ECDH) with ML-KEM-768 (NIST FIPS 203 post-quantum KEM) in a single TLS 1.3 key share. The session key is derived from both shared secrets using a KDF — an attacker must break both the classical and post-quantum components to recover the session key. It is the recommended configuration because ML-KEM-768 provides NIST Level 3 security with manageable key sizes (1,184-byte public key, 1,088-byte ciphertext), and it is already supported natively in OpenSSL 3.5, Chrome 131+, Firefox 135+, and Go 1.24.
Q2: Does enabling hybrid TLS key exchange require replacing our TLS certificates?
A: No. The TLS key exchange and TLS certificate are separate cryptographic operations that protect against different threats. Hybrid ML-KEM key exchange immediately eliminates HNDL exposure for new traffic — regardless of whether the server certificate uses RSA or ECDSA. Certificate migration (replacing RSA/ECDSA certificates with ML-DSA certificates) is a separate, longer-duration Phase 5 activity in the migration roadmap. Most organizations should deploy hybrid TLS key exchange now and plan certificate PKI migration on a 2027–2030 timeline.
Q3: Which OpenSSL version is required for native ML-KEM hybrid TLS support?
A: OpenSSL 3.5.0, released in April 2025, is the first version to include native ML-KEM support in the default provider without requiring the Open Quantum Safe (OQS) external provider extension. Organizations running OpenSSL 3.0 to 3.4 can use the OQS provider plugin to enable ML-KEM, but native support in OpenSSL 3.5 simplifies deployment and reduces the risk of library version drift. NGINX Plus R33+ supports ML-KEM-768 when compiled against OpenSSL 3.5 or using OQS.
Q4: What is RFC 9370, and why does IPsec VPN need it for post-quantum key exchange?
A: RFC 9370 (Multiple Key Exchanges in IKEv2) extends the IKEv2 protocol to support multiple key exchange rounds in a single IKE SA establishment. Without it, IKEv2’s initial IKE_SA_INIT exchange would need to carry the ML-KEM key share — but ML-KEM-768’s 1,184-byte public key exceeds what fits comfortably in the initial exchange. RFC 9370 allows the ML-KEM exchange to occur in a subsequent IKE_INTERMEDIATE round (RFC 9242), combining the classical DH secret and the ML-KEM shared secret into the final IKE SA keying material. This is the standardized path for hybrid quantum-safe IPsec in 2026.
Q5: How do I verify that my TLS connections are using hybrid ML-KEM key exchange?
A: Use the OpenSSL command-line tool: openssl s_client -connect <hostname>:443, then look for ‘Negotiated group: X25519MLKEM768’ in the output. In browser developer tools, check the Security tab and look for ‘Key exchange: X25519MLKEM768’ in the connection details. Chrome’s security indicator and network panel both show the negotiated key exchange group. Cloudflare provides a connection information page that displays the negotiated key exchange method for connections traversing its network.
Q6: Does CNSA 2.0 require ML-KEM-768 or ML-KEM-1024 for National Security Systems?
A: CNSA 2.0 requires ML-KEM-1024 — the highest-security parameter set — for National Security Systems. ML-KEM-768 is appropriate for most commercial enterprise deployments, where NIST Level 3 security is sufficient. For NSS environments subject to CNSA 2.0, verify that your VPN and TLS configurations specify ML-KEM-1024 explicitly. Note that ML-KEM-1024’s larger key size (1,568-byte public key) requires RFC 9370 IKE_INTERMEDIATE handling in IKEv2 — it is too large for the initial IKE_SA_INIT exchange without IP fragmentation.
PQC Series Overview
This article is part of the Post-Quantum Security Series — a technical collection of guides exploring cryptographic vulnerabilities exposed by quantum computing, migration strategies for organizations, and the steps required to protect sensitive data before quantum decryption becomes operationally viable.
References
- [1] Cloudflare Blog. Automatically Secure: How We Upgraded 6,000,000 Domains to Get Ready for the Quantum Future. September 2025. https://blog.cloudflare.com/automatically-secure/
- [2] Cloudflare. Post-Quantum Cryptography — SSL/TLS Documentation. https://developers.cloudflare.com/ssl/post-quantum-cryptography/
- [3] IETF. draft-ietf-tls-ecdhe-mlkem-04 — Post-quantum hybrid ECDHE-MLKEM Key Agreement for TLSv1.3. February 2026.https://datatracker.ietf.org/doc/draft-ietf-tls-ecdhe-mlkem/
- [4] OpenSSL Foundation. The Features of 3.5: Hybrid ML-KEM. April 2025. https://openssl.foundation/news/the-features-of-3-5-hybrid-ml-kem
- [5] Cloudflare. Post-Quantum Between Cloudflare and Origin Servers. https://developers.cloudflare.com/ssl/post-quantum-cryptography/pqc-to-origin/
- [6] IETF. draft-ietf-ipsecme-ikev2-mlkem-05 — Post-quantum Key Exchange with ML-KEM in IKEv2. March 2026. https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ikev2-mlkem/
- [7] InfoQ. Cloudflare Adopts Hybrid ML-KEM for IPsec — Standardizing Post-Quantum IPsec. March 2026. https://www.infoq.com/news/2026/03/cloudflare-post-quantum-ipsec/
- [8] Kubernetes.io. Post-Quantum Cryptography in Kubernetes. January 2026. https://kubernetes.io/blog/2025/07/18/pqc-in-k8s/
- [[9] NSA. CSfC Post Quantum Cryptography Guidance Addendum 1.0. April 2025. https://www.nsa.gov/Portals/75/documents/resources/everyone/csfc/capability-packages/CSfC%20Post%20Quantum%20Cryptography%20Guidance%20Addendum%201_0%20Draft%20_5.pdf?ver=wCGPoDQXcJKEWTgbH8xsRA%3D%3D
