When should organisations start moving to post-quantum cryptography for network traffic?

Organisations should start now when they protect sensitive data with long-lived value, operate critical infrastructure, or expect equipment to remain in service for years. The main risk is delayed migration, because cryptographic transitions take time across inventory, testing, interoperability, and governance. Waiting for a future deadline usually leaves too little runway to change safely.

Why This Matters for Security Teams

Post-quantum cryptography is not a niche research topic anymore. It is a planning problem for any organisation that expects network traffic, archives, or device identities to remain sensitive for years. The risk is less about a quantum computer breaking today’s encryption tomorrow, and more about long-lived data being captured now and decrypted later. That makes migration timing a governance issue, not just a cryptography refresh.

Security teams often underestimate how much of their environment depends on cryptography they do not directly control: TLS termination, VPNs, service-to-service traffic, embedded appliances, and third-party links. In Zero Trust programs, NIST SP 800-207 Zero Trust Architecture reinforces the need to assume network paths are not inherently trustworthy, which makes the strength and agility of transport encryption part of core risk management. NHI Mgmt Group also notes in the Ultimate Guide to NHIs that 90% of IT leaders say properly managing NHIs is essential for a successful zero-trust implementation, which matters because machine identities and the traffic they secure will be part of any PQC transition.

In practice, many security teams encounter cryptographic exposure only after procurement, firmware, and interoperability constraints have already delayed the migration.

How It Works in Practice

The practical answer is to start with crypto inventory and data classification, then prioritise systems where confidentiality must outlast the current key lifespan. That usually means management networks, VPNs, inter-service traffic, regulated data flows, and appliances with long replacement cycles. Current guidance suggests treating PQC as a phased migration: first identify where public-key algorithms are used, then determine which paths can accept hybrid approaches, and finally validate performance and compatibility before making policy changes.

For network traffic, the near-term pattern is often hybrid cryptography rather than immediate full replacement. Hybrid TLS and hybrid key exchange let teams keep conventional algorithms while adding post-quantum algorithms to reduce transition risk. That approach gives room for testing, certificate handling, and operational fallback. It also helps where transport is mediated by third parties or legacy load balancers. The migration should be coordinated with certificate lifecycle, trust store updates, device firmware, and incident response playbooks so that replacement does not create blind spots or break authentication dependencies.

For organisations already struggling with secrets hygiene, the first step is usually to improve inventory and ownership. NHI Mgmt Group’s Ultimate Guide to NHIs highlights that 96% of organisations store secrets outside of secrets managers in vulnerable locations, which is a reminder that cryptographic modernisation must be paired with better control of machine identities and keys. Standards work is still evolving, but baseline planning can already align to ISO/IEC 27001:2022 Information Security Management for governance and to PCI DSS v4.0 where payment traffic and key protection are in scope.

• Inventory all protocols and devices using RSA, ECC, or certificate-based trust.
• Classify traffic by data lifetime, not only by current sensitivity.
• Test hybrid configurations in non-production first, including rollback paths.
• Plan for certificate, firmware, and vendor dependency changes together.

These controls tend to break down in OT, embedded, and outsourced environments because long support cycles and fixed firmware often prevent timely algorithm changes.

Common Variations and Edge Cases

Tighter cryptographic controls often increase operational overhead, requiring organisations to balance stronger future protection against compatibility, latency, and vendor readiness. That tradeoff is real, especially where network appliances, industrial systems, or regulated platforms cannot be patched quickly. Best practice is evolving here, and there is no universal standard for when every environment should complete migration.

Some systems do not need immediate PQC rollout. Short-lived internal traffic with low confidentiality value may be lower priority than customer data, backup replication, or identity traffic that must remain trustworthy for a decade. Likewise, some ecosystems will need a staging strategy because not every client, server, or certificate authority will support the same algorithms at the same time. That is why many organisations should start with crypto agility rather than full replacement: build the ability to swap algorithms without redesigning the whole stack.

Where organisations already have strong NHI governance, the transition is easier because key ownership, rotation, and service inventory are clearer. Where those basics are weak, PQC becomes just another layer of hidden complexity. The Ultimate Guide to NHIs is a useful reminder that machine identities are already numerous and difficult to control, which makes transport cryptography part of the same operational problem, not a separate one.

Related resources from NHI Mgmt Group

• How should organisations start migrating to post-quantum cryptography without replacing everything at once?
• How should organisations prepare IAM for post-quantum cryptography?
• When should organisations start planning for post-quantum identity controls?
• Which controls matter most when moving to post-quantum cryptography?