Workload identity and quantum risk: are your TLS controls ready?

TL;DR: Harvest now, decrypt later turns today’s mTLS traffic into a future intelligence store, because captured handshakes can expose workload identities, internal API calls, and certificate patterns if quantum-safe key exchange is not in place, according to Riptides. The security problem is not a distant quantum milestone, but the fact that every unprotected handshake becomes a permanent record.

NHIMG editorial — based on content published by Riptides: The Quantum Threat to Workload Identity and Why It Starts Today

By the numbers:

• Go 1.24, released in February 2025, enabled X25519MLKEM768 hybrid key exchange by default in crypto/tls.
• A cryptographically relevant quantum computer would need approximately 20 million physical qubits to break RSA-2048.
• The Global Risk Institute’s 2025 survey places a 28-49% probability on a cryptographically relevant machine arriving within 10 years.

Questions worth separating out

Q: How should security teams prepare workload identity for quantum-safe TLS migration?

A: Start by separating transport confidentiality from identity authentication, then inventory which protocols, libraries, and proxies are still dependent on classical key exchange.

Q: Why does harvest-now, decrypt-later matter for NHI governance?

A: Because the data being collected is not only payload content.

Q: How do teams know if hybrid post-quantum TLS is actually working?

A: Inspect the live ClientHello and negotiated session parameters, not just the intended configuration.

Practitioner guidance

• Inventory TLS 1.2 dependencies Map every service still negotiating TLS 1.2 and prioritize replacement, because there is no post-quantum upgrade path for that protocol.
• Verify runtime defaults across Go and proxy layers Check whether Go 1.24+ services are actually using nil CurvePreferences and whether gRPC helpers or intercepting proxies are suppressing hybrid key exchange.
• Enable hybrid key exchange on controlled internal links Turn on hybrid post-quantum negotiation wherever you own both sides of the connection, especially east-west traffic and internal RPC paths.

What's in the full article

Riptides' full article covers the operational detail this post intentionally leaves for the source:

• Go runtime and gRPC configuration examples that show when hybrid key exchange is negotiated and when it is silently disabled
• The practical differences between TLS 1.2, TLS 1.3, and hybrid post-quantum handshake behavior across internal services
• Hands-on inspection guidance for ClientHello analysis so teams can validate what their clients are actually offering
• The specific rollout assumptions behind Riptides' own kernel-level TLS and PQC adoption path

👉 Read Riptides' analysis of quantum risk in workload identity and TLS →

Workload identity and quantum risk: are your TLS controls ready?

Explore further

View Full Forum →  |  NHI Foundation Course →