Post-quantum cryptography, often abbreviated as PQC, is the field of cryptography that designs algorithms believed to remain secure even if an attacker has a powerful quantum computer.

The important point is this: PQC does not usually mean using quantum computers to encrypt data. It means using new mathematical problems that run on normal classical computers but are designed to resist both classical and quantum attacks.

Today, much of the internet depends on public-key cryptography such as:

• RSA
• Diffie–Hellman
• Elliptic Curve Diffie–Hellman
• ECDSA / EdDSA digital signatures

These are used in TLS, SSH, VPNs, software updates, code signing, certificates, identity systems, cloud platforms, messaging systems, package repositories, Kubernetes components, firmware signing, and more.

The issue is that a sufficiently capable quantum computer running Shor’s algorithm could break RSA, finite-field Diffie–Hellman, and elliptic-curve cryptography by solving the underlying factoring and discrete logarithm problems much faster than classical computers can. NIST’s post-quantum cryptography programme exists specifically to standardise replacements for these vulnerable public-key algorithms.

What quantum computers threaten

Quantum computers mainly threaten public-key cryptography.

They are dangerous to:

Cryptographic use	Classical algorithms at risk	Why it matters
Key exchange	RSA key transport, DH, ECDH	Attackers could recover session keys
Digital signatures	RSA, DSA, ECDSA, EdDSA	Attackers could forge identities, software updates, certificates, tokens
Long-lived encrypted data	TLS, VPNs, backups, archives	Captured ciphertext may be decrypted later
PKI and certificates	RSA/ECDSA certificates	Trust chains could be undermined

Symmetric cryptography is less affected. Algorithms like AES and SHA-2/SHA-3 are not “broken” by Shor’s algorithm. Grover’s algorithm gives a quadratic speedup against brute force search, so the normal response is to use larger symmetric keys, for example AES-256 rather than AES-128 for high-value long-term protection.

The core PQC idea

PQC replaces vulnerable public-key primitives with algorithms based on problems believed to be hard for both classical and quantum computers.

The main families include:

PQC family	Example	Common use
Lattice-based	ML-KEM, ML-DSA	Key exchange, signatures
Hash-based	SLH-DSA	Digital signatures
Code-based	Classic McEliece, HQC	Encryption / KEM research and candidates
Multivariate	Historically studied, many broken	Mostly not favoured for general deployment
Isogeny-based	SIKE was broken	Largely a cautionary example

The most important current standards are the NIST FIPS standards released in August 2024:

Standard	Algorithm	Purpose
FIPS 203	ML-KEM	Key encapsulation / key establishment
FIPS 204	ML-DSA	Digital signatures
FIPS 205	SLH-DSA	Stateless hash-based digital signatures

NIST released the first three finalised post-quantum encryption and signature standards in August 2024: ML-KEM, ML-DSA, and SLH-DSA.

---

Why it matters

A quantum computer running Shor’s algorithm could break the maths behind:

• RSA encryption
• Elliptic Curve Cryptography
• Diffie–Hellman key exchange
• Digital signatures such as ECDSA

Shor’s algorithm is the canonical reason RSA, finite-field Diffie–Hellman, and elliptic-curve systems are considered quantum-vulnerable.

The most important point here is that many systems use vulnerable public-key cryptography not only for encryption, but for trust.

For example:

System area	Use of public-key crypto
TLS / HTTPS	Server authentication and key exchange
SSH	Host keys, user keys, session key exchange
VPNs	Peer authentication and tunnel setup
Kubernetes	mTLS, certificates, service identity
Software supply chain	Package signing, container signing, firmware signing
Cloud infrastructure	Certificates, API auth, secure service-to-service communication
Git / CI/CD	SSH keys, signed commits, deployment credentials

A major PQC migration therefore affects far more than “web encryption”. It touches infrastructure identity, authentication, software provenance, device trust, secure boot, PKI, and long-lived secrets.

---

The store now, decrypt later threat

It shows three stages:

1. Attacker captures encrypted data today
2. Data is stored for years
3. A future quantum computer decrypts the data

This is also known as:

• Harvest now, decrypt later
• Store now, decrypt later
• Retrospective decryption
• Long-horizon confidentiality risk

This matters because not all data loses value quickly. Some data remains sensitive for decades.

The infographic lists data at risk:

At-risk category	Why it matters
Government and military communications	National security information may remain sensitive for decades
Health records	Medical data is long-lived and highly personal
Intellectual property	Designs, algorithms, research, trade secrets
Financial data	Transactions, account information, business strategy
Long-term secrets and credentials	Root keys, signing keys, archival secrets, identity material

This is the right risk model. A criminal or state actor does not need a quantum computer today. They only need storage, patience, and access to encrypted traffic or archives.

The key architectural lesson is:

Data with a long confidentiality lifetime should be migrated first.

A short-lived session token that expires in 15 minutes is less urgent than a 20-year government archive, private health record, root CA key, firmware signing key, or sensitive research dataset.

---

What is post-quantum cryptography?

PQC uses new mathematical problems believed to be hard for both classical and quantum computers.

PQC approaches:

• Lattice-based, for example ML-KEM
• Code-based
• Hash-based
• Multivariate

The practical deployment landscape is now heavily centred on lattice-based and hash-based schemes.

Lattice-based cryptography

This is currently the most important family for general-purpose PQC.

Examples:

Algorithm	Standard name	Use
Kyber	ML-KEM	Key establishment
Dilithium	ML-DSA	Digital signatures

ML-KEM is especially important because it is the main replacement candidate for ECDH-style key establishment in protocols such as TLS, VPNs, SSH-like systems, and other secure channels.

Hash-based signatures

Hash-based signatures are conservative because they rely mainly on the security of cryptographic hash functions.

Example:

Algorithm	Standard name	Use
SPHINCS+	SLH-DSA	Stateless digital signatures

Hash-based signatures can be larger and slower than classical signatures, but they provide a useful conservative option for certain signing use cases.

Code-based cryptography

Code-based cryptography has a long history, especially McEliece-style systems. It can offer strong security confidence, but public keys can be large, which complicates deployment.

Multivariate cryptography

This family has had many proposals broken over time. It is still academically relevant, but it is not the main current deployment path for mainstream PQC.

---

How it works: hybrid approach

For real-world engineering solution:

Classical algorithm + post-quantum algorithm = combined secret

This is the hybrid key exchange model.

A hybrid key exchange combines something like:

• X25519, a classical elliptic-curve key exchange
• ML-KEM, a post-quantum key encapsulation mechanism

The resulting shared secret is derived from both components.

The security logic is:

Scenario	Result
Classical algorithm remains secure	Session remains secure
PQC algorithm remains secure	Session remains secure
One component later has a weakness	The other component may still protect the session
Both are broken	Session fails

Hybrid mode is popular because PQC is still relatively new in production. Combining classical and post-quantum cryptography gives a safer migration path than abruptly replacing everything at once.

This is also why OpenSSH is relevant. OpenSSH has supported post-quantum key agreement by default since OpenSSH 9.0, initially using a hybrid sntrup761x25519-sha512 key exchange.

The infographic says:

“If either one is secure, the session stays secure.”

That is the basic intended property of a well-designed hybrid construction. The practical caveat is that this depends on the combiner, implementation, protocol design, downgrade resistance, and correct negotiation. Bad hybrid composition can still introduce failure modes.

For SRE/platform work, the key things to check are:

• Does the protocol support hybrid PQ key exchange?
• Is it enabled by default?
• Can old clients downgrade the connection?
• Are logs available showing negotiated algorithms?
• Do load balancers, proxies, TLS terminators, SSH bastions, VPNs, and service meshes support it?
• Can certificates and signatures be migrated separately from key exchange?
• What breaks when key sizes, signature sizes, or handshake sizes increase?

---

PQC standardization & timeline

The broad timeline:

2016: NIST launched the PQC standardisation project

NIST launched its post-quantum cryptography standardisation effort to evaluate candidate algorithms and select standards for quantum-resistant public-key cryptography.

2017–2022: evaluation, cryptanalysis, testing

This was the period where many candidate algorithms were submitted, evaluated, attacked, benchmarked, and refined.

This matters because PQC algorithms are not trusted merely because they are new. They are trusted because they survive extensive public cryptanalysis.

2022–2024: standards selected

NIST selected algorithms for standardisation, including key establishment and signature schemes. The final standards were published in 2024 as FIPS 203, FIPS 204, and FIPS 205.

2024+: standards adopted and deployed

This is where the hard work begins. Standardisation is not migration.

A full migration involves:

• discovering cryptographic usage
• replacing libraries
• updating protocols
• changing certificates
• testing interoperability
• updating hardware security modules
• upgrading clients and servers
• checking compliance
• validating performance
• monitoring negotiated algorithms
• training engineering teams
• coordinating suppliers and customers

Migration is “a journey, not a switch.”

---

Where PQC is being adopted and what an SRE can do

There are several adoption areas.

1. OpenSSH

Current support examples

OpenSSH is one of the clearest places where PQC is already operationally visible.

Modern OpenSSH supports hybrid post-quantum key exchange algorithms such as:

mlkem768x25519-sha256
sntrup761x25519-sha512
sntrup761x25519-sha512@openssh.com

OpenSSH release notes state that mlkem768x25519-sha256 is now used by default for key agreement in supported versions. That means newer clients and servers can negotiate a hybrid key exchange without changing the application layer at all.

How to check support

On both the client and the server, check what key exchange algorithms the installed OpenSSH supports:

ssh -V

ssh -Q kex | grep -Ei 'mlkem|sntrup|ntru|pq'

Check what the server is configured to allow:

sudo sshd -T | grep -i kexalgorithms

From the client side, check what is actually negotiated:

ssh -vvv user@server.example.com true 2>&1 | grep -Ei 'kex: algorithm|kex algorithm|mlkem|sntrup'

A good result would look conceptually like:

debug1: kex: algorithm: mlkem768x25519-sha256

or:

debug1: kex: algorithm: sntrup761x25519-sha512

That is the evidence you want as an SRE: not “the package is new enough,” but “this connection actually negotiated a PQ/hybrid KEX.”

How to implement as an SRE

For a controlled rollout:

1. Inventory OpenSSH versions across bastions, admin hosts, CI runners, Git servers, jump boxes, storage nodes, Kubernetes nodes, and cloud images.

for h in $(cat hosts.txt); do
  echo "=== $h ==="
  ssh "$h" 'ssh -V 2>&1; ssh -Q kex | grep -Ei "mlkem|sntrup" || true'
done

2. Upgrade OpenSSH on clients and servers where the PQ/hybrid algorithms are missing.
3. Avoid disabling PQ algorithms accidentally in /etc/ssh/sshd_config, /etc/ssh/ssh_config, or enterprise crypto policy.
4. On servers, prefer appending rather than replacing the whole KEX list:

KexAlgorithms +mlkem768x25519-sha256,+sntrup761x25519-sha512

5. Reload SSH safely:

sudo sshd -t
sudo systemctl reload sshd

6. Keep a second session open while testing so you do not lock yourself out.
7. Add a compliance check to your configuration management:

ssh -G server.example.com | grep -i kexalgorithms

8. Log and alert on servers that still negotiate only classical KEX.

For Rocky/RHEL-family systems, also check whether system crypto policy is overriding application configuration:

update-crypto-policies --show

The SRE deliverable should be a small dashboard or report showing:

Host class	OpenSSH version	PQ KEX available	PQ KEX negotiated	Action
Bastions	9.x	Yes	Yes	Done
Git server	8.x	No	No	Upgrade
Old appliances	Unknown	No	No	Vendor escalation

---

2. Web browsers and TLS libraries

Current support examples

This is where PQC adoption is moving quickly.

Google says Chrome enabled ML-KEM by default for TLS 1.3 and QUIC on desktop in May 2024, and that ML-KEM is also enabled on Google servers. Google also notes that Kyber was standardised with changes and renamed ML-KEM, and that ML-KEM was implemented in BoringSSL, Google’s cryptography library.

Cloudflare documents post-quantum key agreement for TLS and states that its PQ key agreements are supported only in protocols based on TLS 1.3, including HTTP/3, and that Cloudflare provides a browser support check through Cloudflare Radar.

Google Cloud Load Balancing now documents support for X25519MLKEM768 as a hybrid key exchange method. When enabled, Google Cloud load balancers use it with clients that advertise TLS 1.3 and X25519MLKEM768; clients that do not support it are unaffected.

OpenSSL 3.5 adds native support for the standardised PQ families ML-KEM, ML-DSA, and SLH-DSA, plus standardised hybrid PQ schemes.

How to check browser-side support

For user/browser verification:

• Use a PQ-aware test site such as Cloudflare Radar’s browser support check.
• Check the browser version.
• Confirm the browser is using TLS 1.3 or HTTP/3/QUIC where applicable.
• Capture a TLS handshake with Wireshark and inspect the supported_groups extension for hybrid groups such as X25519MLKEM768.

From an SRE perspective, browser-side validation is useful, but server-side validation is more important.

How to check server-side TLS support

With OpenSSL 3.5 or newer, check whether your local OpenSSL knows about ML-KEM/hybrid groups:

openssl version

openssl list -kem-algorithms 2>/dev/null | grep -Ei 'ML-KEM|MLKEM' || true
openssl list -groups 2>/dev/null | grep -Ei 'MLKEM|X25519'

Then test a TLS endpoint:

openssl s_client \
  -connect example.com:443 \
  -servername example.com \
  -tls1_3 \
  -groups X25519MLKEM768

Depending on OpenSSL build and naming, you may need to inspect supported groups first:

openssl list -groups

For packet-level proof:

sudo tcpdump -i any -w pq-tls-test.pcap host example.com and port 443

Open the capture in Wireshark and inspect:

TLS ClientHello → supported_groups
TLS ServerHello → selected group / key_share

You are looking for a negotiated hybrid group such as:

X25519MLKEM768

or equivalent naming.

For internet-facing HTTPS estates, build or use a scanner that records:

Endpoint	TLS version	Key exchange group	Certificate algorithm	PQ KEX?	PQ cert?
www.example.com	TLS 1.3	X25519MLKEM768	ECDSA P-256	Yes	No
api.example.com	TLS 1.3	X25519	RSA	No	No
legacy.example.com	TLS 1.2	ECDHE-RSA	RSA	No	No

This matters because most current progress is in key exchange, not yet in the full certificate/signature layer.

How to implement TLS PQC as an SRE

The cleanest SRE implementation path is to enable PQC at TLS termination points first:

• CDN
• cloud load balancer
• ingress controller
• API gateway
• reverse proxy
• service mesh gateway
• internal mTLS gateway

Do not start by modifying every application.

Practical implementation options:

Option A: CDN / managed edge

For services behind Cloudflare, Google Cloud Load Balancing, AWS, or similar, enable PQ/hybrid TLS at the managed edge where supported.

This gives you:

• low operational risk
• broad client compatibility
• centralised rollout
• simpler rollback
• better telemetry

Option B: cloud load balancer

For Google Cloud Load Balancing, evaluate and enable post-quantum TLS support using X25519MLKEM768, then observe handshake metrics and client compatibility. Google Cloud states that unsupported clients are unaffected, which is exactly the behaviour you want during migration.

Option C: self-managed reverse proxy / ingress

For Nginx, Envoy, HAProxy, Apache, or Caddy, the question is not only the web server version. It is also the TLS library underneath:

Component	What matters
Nginx	Built against OpenSSL/BoringSSL/AWS-LC with PQ support
Envoy	BoringSSL/AWS-LC capabilities
HAProxy	Linked TLS library and group configuration
Apache httpd	OpenSSL version and TLS config
Kubernetes ingress	Controller image, TLS library, and config surface

Your SRE deployment pattern should be:

1. Build a canary ingress or gateway.
2. Enable TLS 1.3 only for the test endpoint.
3. Add hybrid group support.
4. Test with PQ-capable clients.
5. Capture handshakes.
6. Watch latency, CPU, handshake failure rate, and client error rate.
7. Roll out by endpoint class.

Example SLOs and telemetry:

tls_handshake_duration_seconds
tls_handshake_failures_total
tls_version_negotiated_total
tls_key_exchange_group_total
http_5xx_rate
client_tls_error_rate
ingress_cpu_seconds_total

The missing metric in many environments is tls_key_exchange_group_total. If your proxy does not expose it, you may need access logs, debug logs, eBPF, packet sampling, or custom instrumentation.

---

3. VPNs: IPsec, WireGuard-style VPNs, ZTNA, remote access

Current support examples

For IPsec/IKEv2, strongSwan 6.0 is an important example. strongSwan 6.0 introduced an ml plugin for Module-Lattice-based crypto / ML-KEM, and its documentation shows IKEv2 examples using ML-KEM. A strongSwan test case shows road-warrior clients using hybrid key exchanges such as x25519-ke1_mlkem512 and ecp384-ke1_mlkem768.

Cloudflare has also announced generally available post-quantum encryption for Cloudflare IPsec using hybrid ML-KEM.

How to check VPN support

For strongSwan:

swanctl --version
swanctl --list-algs | grep -Ei 'mlkem|ml-kem|kem|ke1'

Check configured proposals:

sudo grep -RniE 'mlkem|ke1|x25519|ecp384|ike' /etc/swanctl /etc/strongswan* 2>/dev/null

Check live SAs:

swanctl --list-sas

Increase IKE logging during testing:

charondebug="ike 2, cfg 2, enc 2, knl 1"

Then check logs:

journalctl -u strongswan --since "10 minutes ago" | grep -Ei 'mlkem|ke1|proposal|selected|IKE'

For vendor VPNs:

• Check release notes for ML-KEM, Kyber, post-quantum, hybrid IKE, or hybrid key exchange.
• Ask whether PQ is supported for control-plane key establishment, not just marketing-level “quantum safe” claims.
• Confirm whether both ends support it.
• Confirm whether fallback is classical and whether fallback is logged.

How to implement VPN PQC as an SRE

Prioritise VPNs that protect:

• production admin access
• site-to-site datacentre links
• cloud interconnects
• backup replication
• privileged remote access
• third-party supplier access

For strongSwan, implement in a lab first:

1. Upgrade to strongSwan 6.x with ML-KEM-capable crypto backend.
2. Confirm ml plugin or backend support.
3. Configure hybrid IKE proposal.
4. Initiate tunnel.
5. Confirm negotiated proposal in logs and swanctl --list-sas.
6. Run throughput and latency tests.
7. Test rekey, failover, NAT traversal, MTU, fragmentation, and DPD.
8. Roll out to one non-critical tunnel.
9. Add observability.

You are trying to answer these operational questions:

Question	Why it matters
Does the tunnel still come up after rekey?	PQ KEX may expose rekey bugs
Does MTU/fragmentation change?	Larger key exchange messages can affect IKE
Does the peer silently fall back?	Silent fallback hides risk
Can old clients still connect?	Compatibility management
Are negotiated algorithms logged?	Auditability
Can we roll back cleanly?	Production safety

For commercial VPN/ZTNA providers, your SRE task is vendor assurance:

Please provide evidence of:
- Supported PQ/hybrid key exchange algorithms
- Whether ML-KEM is FIPS 203 aligned
- Whether deployment is default or opt-in
- Whether fallback is logged
- Which clients/agents support it
- Whether IPsec, TLS, WireGuard, or proprietary tunnels are covered
- How negotiated algorithms can be exported to SIEM/telemetry

---

4. Email and messaging

This area is split into two very different worlds:

1. Modern messaging apps, where PQC is already being deployed.
2. Traditional email, where PQC is more complex and adoption is slower.

Messaging examples

Signal introduced PQXDH, which incorporates quantum-resistant cryptographic secrets when chat sessions are established, specifically to protect against harvest-now, decrypt-later attacks. Signal later described additional work on post-quantum ratchets.

Apple introduced PQ3 for iMessage, describing it as a protocol combining post-quantum initial key establishment with ongoing ratchets for protection against harvest-now, decrypt-later attacks.

Traditional email examples

For email standards, the work is more fragmented:

• OpenPGP has an IETF draft for post-quantum cryptography in OpenPGP, including examples using ML-KEM-768 + X25519.
• CMS, which underpins S/MIME-style cryptographic messaging, now has RFC 9936, “Use of ML-KEM in the Cryptographic Message Syntax,” published as a proposed standard in March 2026.

How to check messaging support

For consumer messaging apps, you often cannot inspect negotiated cryptographic parameters directly. So the checks are governance and client-state checks:

• Are users on versions that include PQXDH/PQ3 or equivalent?
• Is the feature enabled by default?
• Is the communication end-to-end encrypted?
• Are backups also protected?
• Are all devices in the conversation upgraded?
• Is there vendor documentation for the exact protocol?

For enterprise messaging platforms, ask the vendor:

Do you support post-quantum or hybrid key establishment?
Is this for transport TLS only, message E2EE, or both?
Are mobile, desktop, and web clients all covered?
Are backups covered?
Can admins see rollout status?
Can non-upgraded clients force downgrade?

How to check email support

For SMTP transport security, start with TLS:

openssl s_client \
  -starttls smtp \
  -connect mail.example.com:25 \
  -servername mail.example.com \
  -tls1_3 \
  -groups X25519MLKEM768

For IMAP:

openssl s_client \
  -connect imap.example.com:993 \
  -servername imap.example.com \
  -tls1_3 \
  -groups X25519MLKEM768

For submission:

openssl s_client \
  -starttls smtp \
  -connect smtp.example.com:587 \
  -servername smtp.example.com \
  -tls1_3 \
  -groups X25519MLKEM768

For content encryption:

• Check whether your OpenPGP implementation supports PQC draft algorithms.
• Check whether your S/MIME/CMS stack supports ML-KEM in CMS.
• Check whether your mail gateway, DLP, archiving, and legal hold tooling can process larger keys/signatures.
• Check whether mobile clients can handle the chosen algorithms.

How to implement email/messaging PQC as an SRE

For enterprise email, treat it as three layers:

Layer	What to do
Transport	Enable TLS 1.3 and hybrid PQ KEX on SMTP/IMAP/submission endpoints where supported
Identity/authentication	Track PQ support for S/MIME certificates, DKIM, MTA-STS, DANE, internal PKI
Message content	Pilot PQ-capable OpenPGP or S/MIME/CMS for high-value groups

Do not assume that PQ TLS makes email fully quantum-safe. SMTP TLS protects the hop, not necessarily the message at rest or across every relay.

A sensible SRE rollout:

1. Upgrade mail edge TLS first.
2. Validate PQ-capable handshakes.
3. Keep classical compatibility.
4. Pilot content encryption for a small group.
5. Test archiving, search, DLP, legal hold, mobile clients, and recovery.
6. Build a clear policy for high-value long-lived content.

---

5. Cloud providers and enterprise platforms

Current support examples

AWS says hybrid post-quantum key agreement standards for TLS have been deployed to AWS KMS, AWS Certificate Manager, and AWS Secrets Manager endpoints, using ML-KEM for hybrid post-quantum key agreement in non-FIPS endpoints across AWS Regions in the aws partition. AWS also describes its work to provide a smooth migration to hybrid PQ key agreement for TLS.

Google Cloud documents post-quantum TLS support on load balancers using X25519MLKEM768.

Microsoft has made PQC capabilities available in Windows Insider builds and through SymCrypt-OpenSSL on Linux, exposing early-access support for testing.

Cloudflare documents PQ support for TLS 1.3-based protocols and Cloudflare IPsec support with hybrid ML-KEM.

What “enterprise platform support” actually means

For SREs, “cloud supports PQC” is too vague. You need to break it down:

Platform layer	PQC question
Public HTTPS edge	Does the load balancer/CDN negotiate hybrid PQ TLS?
Internal service mesh	Does mTLS support PQ/hybrid key exchange?
API clients/SDKs	Does the client TLS library support ML-KEM?
KMS/HSM	Does the service endpoint support hybrid PQ TLS?
Certificates	Are PQ or hybrid signatures supported?
Code signing	Are ML-DSA/SLH-DSA available?
VPN/interconnect	Does IPsec support hybrid ML-KEM?
Kubernetes ingress	Is the controller built with PQ-capable TLS?
Observability	Can negotiated crypto be measured?
Compliance	Is support available in FIPS mode or only non-FIPS?

A common trap: a cloud service may support hybrid PQ TLS on the public endpoint, but your client library, proxy, corporate TLS inspection device, or old Java runtime may prevent negotiation.

How to check cloud endpoint support

For AWS service endpoints:

openssl s_client \
  -connect kms.eu-west-2.amazonaws.com:443 \
  -servername kms.eu-west-2.amazonaws.com \
  -tls1_3 \
  -groups X25519MLKEM768

For Google Cloud load-balanced services:

openssl s_client \
  -connect your-lb.example.com:443 \
  -servername your-lb.example.com \
  -tls1_3 \
  -groups X25519MLKEM768

For Cloudflare-fronted services:

openssl s_client \
  -connect your-zone.example.com:443 \
  -servername your-zone.example.com \
  -tls1_3 \
  -groups X25519MLKEM768

Then verify the selected group through:

• OpenSSL output, if exposed by your version/build
• packet capture
• load balancer logs
• CDN analytics
• provider-specific TLS analytics

For cloud provider support, also check whether the feature is:

Mode	Meaning
Default	Automatically enabled where compatible
Opt-in	Needs explicit configuration
Preview	Not for production
GA	Production-supported
FIPS excluded	May not be available on FIPS endpoints
Region-limited	Not available everywhere
Client-limited	Requires newer clients/libraries

---

6. A practical SRE implementation plan

Phase 1: Build a cryptographic inventory

Start by discovering where public-key crypto is used.

Prioritise:

SSH
TLS/HTTPS
VPN/IPsec
SMTP/IMAP/submission
service mesh mTLS
Kubernetes ingress
API gateways
load balancers
KMS/HSM endpoints
CI/CD deploy keys
Git servers
package signing
container signing
firmware signing
backup encryption

Example scan fields:

Field	Example
Asset	api-prod-lb
Protocol	TLS
Version	TLS 1.3
Current KEX	X25519
PQ-capable?	No
Long-lived data?	Yes
Owner	Platform
Migration action	Enable X25519MLKEM768
Evidence	pcap / log / scan result

Phase 2: Establish test tooling

Create a small internal repo:

pqc-readiness/
├── ssh/
│   ├── check-ssh-pq.sh
│   └── parse-ssh-debug.py
├── tls/
│   ├── check-tls-pq.sh
│   └── capture-handshake.sh
├── vpn/
│   ├── check-strongswan-pq.sh
│   └── parse-swanctl.py
├── inventory/
│   └── pqc-assets.csv
└── dashboards/
    └── grafana-json/

Example SSH check:

#!/usr/bin/env bash
host="$1"

echo "== $host =="
ssh -o BatchMode=yes "$host" 'ssh -V 2>&1; ssh -Q kex | grep -Ei "mlkem|sntrup" || true'

ssh -vvv "$host" true 2>&1 \
  | grep -Ei 'kex: algorithm|mlkem|sntrup' || true

Example TLS check:

#!/usr/bin/env bash
host="$1"
sni="${2:-$host}"

openssl s_client \
  -connect "${host}:443" \
  -servername "$sni" \
  -tls1_3 \
  -groups X25519MLKEM768 \
  </dev/null 2>&1 | tee "tls-${host}.log"

Phase 3: Start with low-risk hybrid key exchange

Best first targets:

Target	Why
SSH bastion canary	Easy to validate and roll back
Non-critical HTTPS endpoint	Good TLS test surface
Internal API gateway	Centralised TLS termination
Site-to-site VPN lab tunnel	Tests IPsec behaviour
Cloud KMS client path	High-value, vendor-supported

Do not begin with root CA migration, production code signing, or all endpoints simultaneously.

Phase 4: Add observability

Add metrics like:

pqc_ssh_kex_negotiated_total{algorithm="mlkem768x25519-sha256"}
pqc_tls_group_negotiated_total{group="X25519MLKEM768"}
pqc_vpn_ike_proposal_total{proposal="ecp384-ke1_mlkem768"}
pqc_scan_endpoint_status{status="classical|hybrid|pq|unknown"}

Dashboards should show:

Panel	Purpose
PQ-capable endpoints	Coverage
PQ-negotiated sessions	Real adoption
Classical fallback rate	Risk
TLS handshake latency	Performance
Failed handshakes	Compatibility
Top non-PQ clients	Remediation
Vendor unsupported systems	Escalation

Phase 5: Rollout policy

Use a tiered migration model:

Tier	Systems	Action
Tier 0	Lab/canary	Enable PQ/hybrid now
Tier 1	Admin SSH, bastions, VPNs	Enable after validation
Tier 2	Public TLS edge	Enable through CDN/LB where supported
Tier 3	Internal service mesh	Pilot carefully
Tier 4	PKI/signatures/code signing	Track standards and vendor support
Tier 5	Legacy appliances	Vendor roadmap or replacement

---

7. What to be careful about

PQC key exchange does not mean full PQC

A TLS session might use hybrid PQ key exchange but still authenticate with an RSA or ECDSA certificate. That improves confidentiality against harvest-now, decrypt-later, but does not fully solve future authentication/signature risks.

TLS 1.2 is usually a blocker

Most practical web PQ KEX work is TLS 1.3-focused. Cloudflare explicitly documents PQ key agreements as TLS 1.3-based.

Middleboxes can break things

TLS inspection appliances, old proxies, old Java runtimes, IDS/IPS devices, and corporate gateways may not understand larger ClientHello messages or new groups.

Watch MTU and fragmentation

PQC handshakes are larger. This can matter in:

• VPNs
• mobile networks
• IoT
• old firewalls
• UDP/QUIC
• IPsec/IKE

FIPS mode may lag

Cloudflare notes PQ key agreements are disabled for websites in FIPS mode. Similar constraints may exist elsewhere. Always check whether PQC is supported in your compliance mode, not just in general product documentation.

---

SRE summary

For an SRE, PQC implementation is not “install a quantum-safe algorithm.” It is an estate-wide migration programme.

Your practical checklist is:

1. Inventory SSH, TLS, VPN, email, service mesh, PKI, KMS, CI/CD, and signing.
2. Find which systems support hybrid PQ key exchange.
3. Prove negotiation with logs or packet captures.
4. Enable hybrid PQ KEX at central termination points first.
5. Keep fallback for old clients, but measure fallback.
6. Add dashboards showing PQ-capable vs PQ-negotiated.
7. Test performance, MTU, rekeying, and rollback.
8. Track PQ signatures and certificate migration separately.
9. Push vendors for exact evidence, not marketing claims.
10. Prioritise systems carrying long-lived sensitive data.

The most useful near-term SRE target is:

Hybrid PQ key exchange for SSH, TLS 1.3, cloud load balancers, VPN tunnels, and high-value service endpoints — with observability proving what was actually negotiated.

This is one reason PQC migration is a platform engineering problem, not only a cryptography team problem.

Governments and critical infrastructure

Governments and critical infrastructure are planning migrations. For example, NSA’s CNSA 2.0 guidance sets out transition expectations for national security systems and quantum-resistant algorithms.

---

7 steps you can take now

Each step maps to a real migration programme.

Step 1: Inventory and discover

“Identify where cryptography is used across your systems, apps, and data.”

This is the most important first step.

You cannot migrate what you cannot see.

A serious crypto inventory should include:

Area	What to discover
TLS endpoints	Certificates, ciphers, key exchange groups, TLS versions
SSH	Host keys, user keys, KEX algorithms, bastions
VPNs	IKE/IPsec/WireGuard/OpenVPN parameters
PKI	Root CAs, intermediate CAs, certificate lifetimes
Code signing	Package signing, container signing, firmware signing
Secrets systems	KMS, Vault, HSMs, key wrapping, envelope encryption
Applications	Crypto libraries, hardcoded algorithms, JWT signing
Kubernetes	cert-manager, kubelet certs, ingress TLS, service mesh mTLS
CI/CD	Git signing, artifact signing, deployment keys
Backups	Archive encryption, retention, restore path
Third parties	SaaS, suppliers, managed platforms, appliances

This is where crypto-agility matters. Systems should be able to change algorithms without full redesign.

Step 2: Use strong crypto today

“Use modern algorithms and key sizes.”

This is practical and necessary. PQC migration will take years, but weak crypto can be removed now.

Good near-term hygiene includes:

• disable TLS 1.0 and TLS 1.1
• prefer TLS 1.3
• remove weak ciphers
• avoid RSA key exchange
• use ECDHE/X25519 where PQC is not yet available
• use AES-256-GCM or ChaCha20-Poly1305 where appropriate
• use SHA-256/SHA-384 rather than SHA-1
• avoid long-lived static keys
• rotate certificates and secrets
• shorten certificate lifetimes where feasible
• use HSM/KMS-backed key management for high-value keys

This does not make systems fully quantum-safe, but it reduces classical risk and prepares for migration.

Step 3: Enable hybrid where available

“Turn on hybrid PQ key exchange and PQC features in supported systems.”

This is the bridge from current cryptography to PQC.

Examples:

System	What to evaluate
SSH	Hybrid KEX algorithms, OpenSSH version, server/client crypto policy
TLS	Hybrid key exchange support in TLS library, browser/client compatibility
VPN	Vendor roadmap for PQ/hybrid IKE or tunnel establishment
Service mesh	Envoy/Istio/Linkerd support for PQC-capable TLS stacks
Load balancers	PQC support in appliance/cloud LB TLS termination
Internal APIs	mTLS support, certificate/signature migration plan

For SSH, check both sides:

ssh -Q kex | grep -E 'sntrup|mlkem|x25519'

And for a connection:

ssh -vvv user@host 2>&1 | grep -i 'kex: algorithm'

The goal is to verify the negotiated algorithm, not merely assume the software version supports it.

Step 4: Protect high-value data now

“Classify sensitive data. Use encryption, access controls, and monitoring.”

This is a risk-prioritisation step.

Not all systems need to move at the same speed. Prioritise data with:

• long confidentiality lifetime
• regulatory sensitivity
• national security value
• business-critical intellectual property
• customer privacy impact
• credential or root-of-trust value

For example:

High-priority data	Why
Health records	Sensitive for decades
Government records	Long-lived national/security implications
Source code and IP	Long-term commercial value
Root CA keys	Trust anchor compromise is catastrophic
Firmware signing keys	Device ecosystem compromise
Backups and archives	Often retained for years
Research data	May have long-term strategic value

This step should also include detection and monitoring. You need to know where sensitive data flows, where encrypted traffic terminates, and where long-lived keys exist.

Step 5: Plan for migration

“Follow NIST standards and your vendors’ roadmaps.”

This is the governance part.

A good PQC migration plan should include:

Workstream	Deliverable
Discovery	Crypto asset inventory
Risk	Data confidentiality lifetime assessment
Architecture	Hybrid/PQC target architecture
Dependencies	Vendor and library compatibility matrix
Testing	Lab validation and interoperability tests
Rollout	Phased migration by risk tier
Monitoring	Algorithm negotiation telemetry
Compliance	Mapping to NIST/sector requirements
Recovery	Rollback and downgrade prevention plan

NIST’s National Cybersecurity Center of Excellence has a migration-to-PQC project focused on practices for moving from quantum-vulnerable public-key algorithms to NIST-standardised PQC algorithms.

Step 6: Work with your ecosystem

“Engage vendors, partners, and customers.”

This is essential because cryptography is rarely isolated.

Your system may depend on:

• operating system crypto policies
• OpenSSL, BoringSSL, LibreSSL, GnuTLS, wolfSSL
• Java crypto providers
• HSM and KMS vendors
• cloud load balancers
• CDN providers
• VPN appliances
• endpoint agents
• mobile clients
• IoT devices
• certificate authorities
• browsers
• package repositories
• SaaS platforms

A company can be internally ready but still blocked by suppliers, old clients, embedded devices, or regulatory constraints.

The right questions for vendors are:

• Which PQC algorithms do you support?
• Do you support NIST FIPS 203/204/205?
• Do you support hybrid key exchange?
• Which protocols are supported: TLS, SSH, IPsec, S/MIME, code signing?
• Is PQC enabled by default or opt-in?
• What versions are required?
• What telemetry shows negotiated algorithms?
• What are the performance and packet-size impacts?
• What is your roadmap for certificates and signatures?
• Are HSM/KMS integrations supported?
• Is there FIPS validation or planned validation?

Step 7: Stay informed and test

“Track standards and threats. Test PQC in labs and pilot environments.”

This is accurate because PQC is moving from standardisation into deployment. Standards exist, but production readiness varies across protocols, libraries, vendors, and operating systems.

Testing should include:

• TLS handshake size and latency
• SSH interoperability
• certificate chain size
• MTU and fragmentation issues
• load balancer compatibility
• packet inspection behaviour
• HSM/KMS support
• CPU overhead
• memory impact
• logging and observability
• downgrade resistance
• old client compatibility
• disaster recovery and rollback

This is particularly important for SRE/platform teams because cryptographic changes can fail in operationally awkward places: old agents, old appliances, Java runtimes, embedded devices, package mirrors, monitoring agents, backup clients, and internal automation.

---

Clarification Points

“Cryptographically relevant quantum computers are not here yet.”

Quantum computers exist today, but not at the scale needed to break real-world RSA/ECC cryptography.

“Can break many widely used public-key algorithms.”

Quantum computers do not automatically break all classical cryptography. Symmetric encryption and hashes are affected differently.

PQC mainly replaces or augments public-key mechanisms:

• key exchange
• key encapsulation
• digital signatures

Bulk encryption still normally uses symmetric encryption such as AES or ChaCha20.

---

The bottom line

Quantum computers will change the threat landscape. Post-quantum cryptography helps keep important data and communications secure for the future.

The practical message is:

Do not wait for a cryptographically relevant quantum computer to exist before starting migration.

The right approach is:

1. inventory cryptography
2. classify long-lived sensitive data
3. remove weak crypto now
4. test hybrid PQC where available
5. track NIST and vendor roadmaps
6. build crypto-agility
7. migrate high-value systems first

For infrastructure and SRE teams, PQC is not just “new algorithms”. It is a multi-year operational migration across SSH, TLS, VPNs, PKI, service identity, code signing, certificates, secrets management, observability, compliance, vendors, and customer compatibility.