The Quantum Threat to Workload Identity — And Why It Starts Today

The follow-up we promised: the harvest-now, decrypt-later attack pattern, what the NIST PQC timeline means for infrastructure teams, and where Riptides stands.

---

Someone may be recording your mTLS traffic right now. Not to read it today. To read it later.

No exploit. No alert. No active interference. Just a passive tap: a compromised hypervisor, a rogue switch port, a network device at an internet exchange, silently capturing TLS handshakes and storing them cheaply until a cryptographically relevant quantum computer exists. At that point, the math changes, and every session recorded today becomes readable retroactively.

This is Harvest Now, Decrypt Later, and it is the most underappreciated threat in workload identity security. Not because it is subtle (it is not), but because it creates urgency before any quantum computer capable of executing it actually exists.

What a Quantum Computer Actually Is

The short version: a classical computer solves a problem by trying possibilities sequentially. A quantum computer can, for certain specific types of problems, explore many possibilities at once and collapse to the right answer. This is not useful for most computing tasks — but for the math underlying encryption, it is a structural shortcut that breaks the assumptions everything else is built on.

Quantum computers are not faster classical machines, and they are not related to AI. They are a fundamentally different category of hardware, based on different physics.

A classical computer stores information as bits: transistors that are either on or off. A quantum computer stores information as qubits, which exploit superposition: a qubit exists as 0 and 1 simultaneously until measured. Carefully designed algorithms can use this property to cancel out wrong answers and amplify correct ones, a process called interference. This is not brute force. It is a structural shortcut through specific classes of mathematical problems.

The algorithm that matters here is Shor’s algorithm, published in 1994. It can factor large integers and solve discrete logarithms, the mathematical foundations of RSA and elliptic curve cryptography, exponentially faster than any classical machine. A cryptographically relevant quantum computer running Shor’s algorithm could recover a private key from its public key in hours.

That machine does not exist yet. Google’s Willow chip, released in late 2024, has 105 physical qubits. Breaking RSA-2048 requires approximately 20 million physical qubits running with error correction. We are roughly five orders of magnitude away from a working attack. The Global Risk Institute’s 2025 survey of leading quantum researchers places a 28–49% probability on a cryptographically relevant machine arriving within 10 years, and 51–70% within 15.

In practical terms: we are still a very long way from a working attack, but credible researchers place it in the range of a decade or two — well within the lifetime of infrastructure decisions made today.

The timeline is uncertain. The direction is not.

Why Identity Infrastructure Is the High-Value Target

Generic HTTPS traffic, when decrypted retroactively, leaks user sessions. Harvested mTLS traffic between internal workloads leaks something more durable: the shape of your infrastructure itself.

A captured mTLS handshake reveals the SPIFFE IDs of both communicating workloads: their identities, their roles, who talks to whom. It exposes the content of internal API calls: authentication flows, secrets requests, RPC payloads. It reveals your CA hierarchy and certificate issuance patterns. This is not session data. It is architectural intelligence about how your systems are built, and it remains useful long after the specific sessions have ended.

The sensitivity lifetime of that information is measured in years. If a cryptographically relevant quantum computer arrives in eight years, and your internal service topology today reflects your service topology in eight years (which for most organizations it largely will), then the traffic being captured now is genuinely useful to whoever holds it when Q-Day arrives.

This is the calculation that changes how urgency should be framed: the deadline for acting is not when a quantum computer can decrypt your traffic. It is today, because every unprotected handshake is a permanent record.

Two Separate Problems in TLS

It helps to be precise about what, specifically, is vulnerable. A TLS 1.3 handshake involves two distinct asymmetric operations, and they carry different risk profiles.

Key exchange establishes the session key, the symmetric key used to encrypt the actual connection. In standard TLS 1.3, this is ECDHE: an ephemeral elliptic curve Diffie-Hellman exchange. The session key is derived from public keys visible in the handshake transcript. A quantum attacker with a recording of that handshake can run Shor’s algorithm against the captured ECDHE public key, recover the session key, and decrypt every record. This is the HNDL-critical layer.

Certificate signatures authenticate the parties by proving that the certificate presented matches the private key held by the peer. Breaking this requires running Shor’s algorithm in real time during an active connection, or forging certificates after compromising a CA key. This is a real threat, but it does not enable retroactive decryption of stored traffic. The urgency is lower.

The practical implication: fixing key exchange first is the right priority. That protects against the attack that is executable today: passive collection for future decryption. Certificate signature migration can follow as the ecosystem matures, and it will need to.

Where the Ecosystem Stands

The good news is that the critical layer, key exchange, is moving fast.

Go 1.24, released in February 2025, enabled X25519MLKEM768 hybrid key exchange by default in crypto/tls. Any Go service running 1.24 or later, without explicit overrides to CurvePreferences, is already negotiating post-quantum key exchange with compatible peers. Chrome, Firefox, and OpenSSL 3.5 all ship ML-KEM hybrid support by default. A meaningful fraction of internet traffic is already post-quantum protected at the key exchange layer.

The certificate signature layer is further behind. ML-DSA, the NIST-standardized post-quantum signature algorithm, landed as an internal implementation in Go 1.26. A public API is proposed for Go 1.27, but X.509 and crypto/tls integration is a further step, targeted at Go 1.28 or later. Production CA support for ML-DSA certificates is expected from the CA/Browser Forum in 2026–2027. SPIRE, the reference SPIFFE implementation, has no public roadmap for ML-DSA SVID issuance yet.

The migration will happen in two phases, whether organizations plan for it or not. The question is whether you are ahead of the collection window or behind it.

Where Riptides Stands

The short version: the part of the connection that protects data in transit is already upgraded. The part that verifies identities is still catching up across the whole industry, and we are tracking it.

In our previous post, we upgraded the Riptides kernel module to TLS 1.3 and shipped opt-in PQC hybrid mode (X25519 combined with ML-KEM-768) for internal mTLS handshakes. That was the key exchange layer.

The fuller picture across our stack:

The record layer is not a quantum problem. Riptides uses kTLS for record encryption, with AES-256-GCM. Symmetric ciphers are not broken by quantum computers in any practical sense. Grover’s algorithm provides only a quadratic speedup against brute force search, leaving AES-256 with an effective 128-bit security level that is computationally infeasible to attack. kTLS does not need to change.

The Go daemon and control plane negotiate PQC key exchange automatically on Go 1.24+, as long as CurvePreferences is not explicitly overridden. We have audited our gRPC credential setup to verify this. Go 1.26 adds SecP256r1MLKEM768 to the defaults as well.

The kernel module handshake layer is where active work continues. The TLS 1.3 upgrade replaced BearSSL (TLS 1.2 only, with no PQC path) with a library that supports both TLS 1.3 and ML-KEM hybrid key exchange. The opt-in pqc_hybrid mode ships that hybrid handshake today. What remains: PQC support in the underlying library is experimental rather than production-certified, and ML-DSA certificate signatures at the kernel module level are not yet possible in any production TLS library. We are tracking both, and will harden and extend as the ecosystem matures.

This is not a solved problem. It is work in progress, done in the open, with an honest assessment of what is covered and what is not.

Check Your TLS Posture Right Now

Before planning any migration, you need to know where you actually stand. That starts with understanding what your clients are advertising in their ClientHello.

We built safetls.riptides.io to answer that question directly. Visit it from any browser or HTTP client and it inspects the TLS handshake your client just performed, returning a full analysis of the TLS versions offered, cipher suites advertised, key exchange groups including whether any post-quantum groups were offered, and a security grade. No configuration, no agent, no signup.

For a browser check, just open the URL. If you’re not a command-line user, that’s all you need — you’ll see a letter grade and a plain-English summary of your client’s TLS posture. For programmatic inspection from any HTTP client:

curl -s https://safetls.riptides.io/api/inspect | jq .observation.grade.rating

The response tells you your client’s rating (A+ through F). For the full breakdown including score, findings, and recommendations:

curl -s https://safetls.riptides.io/api/inspect | jq .observation.grade

{
  "score": 85,
  "rating": "B",
  "summary": "Modern TLS client with a strong baseline, but no post-quantum hybrid key share was observed.",
  "post_quantum_offered": false,
  "findings": [
    {
      "severity": "warning",
      "code": "static-rsa-key-exchange",
      "message": "Static RSA cipher suites are offered, which means those connections lack forward secrecy."
    },
    {
      "severity": "info",
      "code": "cbc-cipher-suite-compat",
      "message": "CBC-based cipher suites are offered for compatibility, but TLS 1.3 is also present."
    },
    {
      "severity": "info",
      "code": "pqc-hybrid-missing",
      "message": "No post-quantum hybrid key share was observed."
    }
  ],
  "recommendations": [
    "Prefer ECDHE-based TLS 1.2 suites and TLS 1.3 suites only.",
    "Favor AEAD suites such as AES-GCM or ChaCha20-Poly1305.",
    "Add a hybrid key exchange such as X25519MLKEM768 where your TLS stack supports it."
  ]
}

One important caveat: if you are behind a corporate TLS proxy that intercepts and re-establishes connections, you will see the proxy’s ClientHello, not your own. That is itself useful information about your network posture.

What Infrastructure Teams Should Do Now

Three concrete actions that do not require waiting for anything.

Audit where TLS 1.2 still runs. Older TLS versions cannot be made quantum-safe — there is no upgrade path for them, only replacement. TLS 1.2 has no post-quantum migration path. The IETF will not define PQC cipher suites for it. Any service speaking TLS 1.2 today is categorically excluded from a quantum-safe future, and every handshake it performs is harvestable.

Verify your Go TLS defaults are intact. Go 1.24 shipped post-quantum protection on by default, but certain configuration patterns silently disable it — and most teams don’t realize. If you are on Go 1.24+ and CurvePreferences is nil in your TLS configuration, you are already negotiating hybrid PQC key exchange with compatible peers. If CurvePreferences is set explicitly, or if you are using gRPC convenience helpers like NewClientTLSFromCert, that protection may be silently disabled. Use the API above to verify before assuming.

Enable PQC hybrid mode where you control both ends. If you own both sides of a connection — internal services talking to each other — you don’t need to wait for industry standards to catch up. For internal east-west traffic where both sides are under your control, there is no reason to wait. The overhead is measurable only at very high connection rates with no reuse; for normal internal RPC patterns it is negligible.

The quantum computer that can decrypt your traffic does not exist today. The adversary collecting your traffic in case it eventually does is already operational.

---

Questions about PQC mode or the TLS 1.3 rollout? Reach out at riptides.io or get in touch for a demo.

If you found this useful, follow us on LinkedIn and X for more updates.

---

If you enjoyed this post, follow us on LinkedIn and X for more updates. If you'd like to see Riptides in action, get in touch with us for a demo.