Quantum threats to workload identity start with today’s handshakes

At a glance

What this is: This is an analysis of how quantum computing changes workload identity risk, with the central finding that harvested TLS traffic can remain sensitive long before decryption is possible.

Why it matters: It matters because IAM teams now have to treat workload identity, certificate lifecycles, and transport security as a single governance problem across NHI and infrastructure programmes.

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.
• 2025 survey places a 28-49% probability on a
• 51-70% probability on that machine arriving within 15

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

Context

Workload identity depends on the assumption that encrypted traffic remains unreadable after capture. Quantum-safe migration changes that assumption because today’s TLS handshakes may still be valuable later, even if no attacker can decrypt them now. For identity teams, that makes transport security, certificate handling, and workload authentication part of the same risk surface.

The immediate concern is not abstract quantum theory. It is the harvest-now, decrypt-later pattern, where attackers store mTLS handshakes, internal API calls, and identity metadata until cryptographic capabilities catch up. That creates a governance problem for NHI programmes, because the confidentiality lifetime of workload traffic can outlast the control decisions made when it was originally transmitted.

The article’s starting position is typical for infrastructure teams: strong enough to have modern TLS in place, but not yet consistent enough to assume post-quantum readiness across the estate.

Key questions

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. Prioritise internal east-west paths where you control both endpoints, because those are usually the fastest to upgrade. Treat TLS configuration drift as a governance issue, not just a platform task.

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

A: Because the data being collected is not only payload content. It also includes service identities, trust relationships, and certificate patterns that can remain useful long after collection. That means NHI governance has to account for the future value of recorded traffic, not just the security of active credentials.

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. If the stack advertises only classical key shares, or a proxy rewrites the connection, the protection may not be present in practice. Verify the full path from client to service before claiming readiness.

Q: Should organisations prioritise key exchange or certificate signatures first?

A: Prioritise key exchange first, because that is what protects against retroactive decryption of recorded traffic. Certificate-signature migration still matters, but it addresses a different problem and usually depends on broader ecosystem support. A phased plan reduces exposure sooner and avoids waiting for the entire stack to mature at once.

Technical breakdown

Harvest now, decrypt later and workload identity exposure

Harvest now, decrypt later means an attacker captures encrypted traffic today and waits for a future cryptographic breakthrough to read it. In workload identity environments, the prize is not only payload data but also identity metadata inside handshakes, including which workloads communicate, how certificates are issued, and what internal services exist. That makes passive collection strategically valuable even without active compromise. The key point is persistence: a recorded handshake can remain exploitable long after the operational event has passed, which is why transport-layer identity data has a longer security half-life than teams often assume.

Practical implication: treat internal handshake traffic as durable sensitive data and classify it accordingly in retention, monitoring, and migration planning.

TLS 1.3 key exchange versus certificate signatures

TLS has two separate asymmetric trust problems. Key exchange creates the symmetric session key used for data encryption, while certificate signatures prove the peer owns the identity it presents. Quantum risk hits these differently. Retroactive decryption mainly threatens key exchange, because a recorded ECDHE transcript could be broken later if quantum capability exists. Certificate signatures are a separate problem because they matter during authentication and CA trust, not for decrypting old recordings. That distinction matters operationally because it determines migration order, tooling priorities, and how teams test partial post-quantum support across libraries and runtime stacks.

Practical implication: prioritise post-quantum key exchange first, then plan certificate-signature migration as the ecosystem matures.

Hybrid post-quantum TLS and identity plumbing

Hybrid post-quantum TLS combines classical and post-quantum algorithms so current peers can still connect while gaining protection against future quantum decryption. In practice, this is most useful where both ends of the connection are under organizational control, because internal east-west traffic is easier to upgrade than internet-facing compatibility paths. The article also shows a subtle operational risk: library defaults can help, but explicit configuration may silently disable the protection. That means post-quantum readiness is not just a crypto question. It is also a configuration and assurance question across application runtimes, proxies, and service meshes.

Practical implication: inventory TLS libraries, default settings, and proxy layers before assuming hybrid protection is actually negotiated.

Threat narrative

Attacker objective: The attacker wants to preserve encrypted workload traffic until it can be decrypted later for identity intelligence, secret exposure, and infrastructure mapping.

1. Entry begins with passive collection of mTLS handshakes from a compromised hypervisor, rogue switch port, internet exchange device, or similar tap point.
2. Credential access occurs later when stored transcripts, public keys, and identity metadata are processed after a cryptographically relevant quantum computer exists.
3. Impact is retroactive decryption of workload traffic, exposing internal API calls, service identities, and infrastructure topology at scale.

Breaches seen in the wild

• Sisense breach — unauthorized GitLab access led to exfiltration of access tokens, API keys and certificates.
• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Harvest-now, decrypt-later is an identity governance problem, not just a crypto problem. The article shows that workload identity data can remain sensitive for years after collection, which means identity programmes have to govern confidentiality lifetime as well as authentication strength. That shifts the question from whether encryption exists to whether the encrypted identity record remains safe across the full retention window. Practitioners should treat transport telemetry, handshake metadata, and internal service relationships as governed identity assets.

Certificate validity alone does not solve workload identity risk. The security boundary is split between session confidentiality and peer authentication, and quantum impact lands differently on each. That is why post-quantum key exchange must be handled separately from certificate-signature migration, rather than being treated as one generic TLS refresh. The practical conclusion is that workload identity roadmaps need phase-specific controls, not a single upgrade milestone.

Handshake capture creates identity blast radius, not just packet risk. Once mTLS traffic is stored, the retroactive value is not limited to contents. It also includes which workloads spoke, how certificates were issued, and where internal trust relationships sit. That means the blast radius spans NHI governance, service topology, and future incident response. Practitioners should assume captured identity traffic can outlive the system that produced it.

Hybrid post-quantum transport is now a governance baseline for controlled environments. Where organizations own both ends of a connection, waiting for industry-wide completion is a policy choice, not a technical necessity. The article’s real signal is that internal east-west traffic can be upgraded earlier than many teams expect. Identity teams should treat that as a governance sequencing issue and reconcile it with runtime standards, proxy behavior, and service mesh policy.

Access review assumptions break when the asset being reviewed is a future-decryptable transcript. Traditional review cycles are designed for visible entitlements and active credentials. That assumption fails when the security concern is a recorded handshake whose risk matures later, outside the review window. The implication is that governance has to move from entitlement-only thinking to lifecycle thinking for cryptographic records, not merely for accounts and keys.

From our research:

• 69% of organisations now have more machine identities than human ones, according to The Critical Gaps in Machine Identity Management report.
• 57% of organisations lack a complete inventory of their machine identities, which makes long-lived cryptographic exposure harder to govern.
• For a broader view of identity risk patterns, see 52 NHI Breaches Analysis, which tracks how machine identity weaknesses become breach paths.

What this signals

Quantum readiness is now part of workload identity governance, not a niche cryptography project. The practical issue is not when a quantum computer arrives, but whether the identity record created today can survive that timeline safely. Teams that already manage machine identity at scale should align transport upgrades, certificate policy, and proxy behaviour under one roadmap, then verify them in runtime rather than on paper.

With 57% of organisations lacking a complete inventory of their machine identities, the same visibility gap that complicates certificate and secret governance will also complicate post-quantum migration. If you cannot map the workloads, you cannot know which handshake paths, libraries, or trust chains still depend on classical assumptions.

Quantum-safe transport will become a differentiator in internal architecture decisions. The near-term signal is that hybrid key exchange is already available in parts of the ecosystem, while signature migration remains behind. That means practitioners should expect uneven adoption, then use framework-led control mapping to keep the programme coherent across NHI, service mesh, and platform teams.

For practitioners

• 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. Include internal services, brokers, proxies, and legacy clients in the inventory, not just public endpoints.
• 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. Validate the observed ClientHello rather than assuming configuration intent equals effective posture.
• 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. Focus first on high-value service-to-service channels where recorded handshakes would expose identity relationships.
• Classify handshake logs as durable sensitive data Apply retention, access, and monitoring controls to TLS handshake records, certificate telemetry, and service-mesh traces. These artefacts can reveal infrastructure structure even before any quantum decryption becomes possible.

Key takeaways

• Workload identity traffic becomes a long-lived intelligence asset when harvested now for later decryption.
• The exposure is larger than payload confidentiality because handshakes also reveal identities, trust chains, and service topology.
• Teams should upgrade key exchange first, validate runtime behavior, and treat handshake records as governed sensitive data.

Key terms

• Harvest Now, Decrypt Later: A collection strategy where an attacker stores encrypted traffic today and waits for future cryptographic capability to read it. In workload identity environments, the target is often not only payload data but also handshake metadata, service relationships, and certificate behaviour that remain valuable over time.
• Hybrid Post-Quantum Key Exchange: A TLS handshake method that combines a classical algorithm with a post-quantum algorithm so current systems can interoperate while gaining resistance to future quantum decryption. For workload identity, it is a transition mechanism, not a permanent endpoint, because certificate and runtime dependencies still need separate governance.
• Workload Identity: The identity assigned to a machine, service, or application when it authenticates to other systems. In practice it includes certificates, service account bindings, and transport-layer trust relationships, all of which become part of the identity governance surface when traffic can be stored and decrypted later.
• ClientHello: The first TLS message a client sends to advertise supported versions, cipher suites, and key exchange groups. For post-quantum readiness, it is a key diagnostic signal because it shows what protection the client is actually willing to negotiate, which may differ from what operators believe is configured.

Deepen your knowledge

Quantum-safe workload identity and TLS migration are covered in our NHI Foundation Level course, the industry's only accredited NHI security programme. If your team is starting from TLS visibility rather than post-quantum readiness, that course provides the governance baseline.

This post draws on content published by Riptides: The Quantum Threat to Workload Identity and Why It Starts Today. Read the original.