Overview
Post-quantum cryptography (PQC) is the family of cryptographic algorithms that are designed to be resistant to attack by a cryptographically-relevant quantum computer. The US National Institute of Standards and Technology (NIST) has been running a multi-year standardization process, and the first three PQC standards (FIPS 203 for ML-KEM, a key-encapsulation mechanism; FIPS 204 for ML-DSA, a digital signature algorithm; and FIPS 205 for SLH-DSA, a stateless hash-based signature algorithm) have been published. The federal government has signaled an aggressive timeline for the migration to PQC, with major federal systems expected to begin the transition in the next several years.
For most working network admins, PQC is not a panic-today situation. The cryptographically-relevant quantum computer that breaks current public-key cryptography does not exist yet, and the operational impact of the PQC migration is years away for most organizations. The right response is not to ignore the topic; the right response is to start the inventory work now, so that when the migration becomes operationally relevant, the organization knows where the cryptography lives and can plan the migration with current information.
The reason the inventory work is the right starting point is that cryptography in a network is rarely a single thing. It lives in the VPN concentrators, the TLS terminators, the PKI hierarchy, the device firmware, the management plane, the data plane, the long-lived encrypted data, and the third-party integrations. The migration to PQC requires each of these to be evaluated, and the evaluation is much easier when the inventory is current. An organization that starts the inventory now will be ready when the migration becomes operationally relevant; an organization that does not will be scrambling when the migration becomes a deadline.
How it works
PQC migration in a network context affects several distinct areas. VPNs: site-to-site and remote-access VPNs that use IPsec with RSA or ECDSA key exchange need to be evaluated for PQC support. Most modern VPN concentrators and clients support hybrid key exchange that combines a classical algorithm with a PQC algorithm, which provides defense in depth even before the classical algorithm is broken. TLS terminators: web servers, API gateways, load balancers, and other TLS-terminating infrastructure need to be evaluated for PQC support in the TLS handshake. Modern TLS implementations (TLS 1.3 with the right cipher suites and the right library versions) support hybrid key exchange, and the migration path is to enable the hybrid key exchange and to phase out the classical-only configurations.
PKI and certificates: the certificate hierarchy that the network depends on (the internal CA, the public CA, the device certificates, the user certificates, the code-signing certificates) needs to be evaluated for PQC support. The PQC signature algorithms (ML-DSA and SLH-DSA from the FIPS 204 and FIPS 205 standards) are available, and the migration path is to issue PQC-signed certificates alongside the classical-signed certificates and to phase in the PQC-signed certificates as the relying parties support them. Device firmware: the firmware that runs on the network devices (switches, routers, access points, VPN concentrators, firewalls) needs to be evaluated for PQC support in the cryptographic libraries that the firmware uses. The migration path is to track the vendor's PQC support roadmap and to plan the firmware upgrades in line with the roadmap.
Long-lived encrypted data: data that was encrypted with a current public-key algorithm and is expected to remain confidential for years or decades is the data that is most at risk from the eventual quantum threat, because an attacker can capture the encrypted data today and decrypt it later when the cryptographically-relevant quantum computer exists. The migration path for long-lived encrypted data is to re-encrypt the data with a PQC algorithm as soon as the algorithm is operationally supported, which is the part of the migration that the inventory work has to identify. Third-party integrations: any third-party service that the network depends on (cloud providers, SaaS providers, managed service providers, partner networks) needs to be evaluated for PQC support. The migration path is to track the third party's PQC roadmap and to plan the integration upgrades in line with the third-party's roadmap.
Government and regulated environments are the part of the migration that is most time-sensitive. The federal government has signaled an aggressive timeline, with major federal systems expected to begin the transition in the next several years, and the regulated industries that follow the federal lead (financial services, healthcare, defense industrial base) are likely to follow the federal timeline. Organizations in these environments should be tracking the federal migration timeline and the regulator-specific guidance, and should be planning the migration in line with the regulator's expectations.
In practice
A practical PQC planning program starts with the inventory. The inventory has to identify every place that cryptography lives in the network: every VPN, every TLS terminator, every certificate, every device firmware, every long-lived encrypted data store, every third-party integration. The inventory should be in a queryable form (a spreadsheet, a database, or a CMDB entry) that can be filtered by cryptographic algorithm, by vendor, by version, and by the migration priority. The inventory is the input to the migration planning, and the migration planning cannot start until the inventory is current.
The second step is to track the vendor roadmaps. Every vendor that provides cryptographic functionality in the network (the VPN concentrator vendor, the switch vendor, the firewall vendor, the PKI vendor, the cloud provider) has a PQC roadmap, and the roadmaps are at different stages of maturity. The right operational discipline is to engage with the vendors to understand their roadmap, to plan the upgrades in line with the roadmap, and to flag the vendors whose roadmaps are lagging the operational requirement.
The third step is to enable the hybrid key exchange where it is available. The hybrid key exchange that combines a classical algorithm with a PQC algorithm is the operational mechanism that provides defense in depth even before the classical algorithm is broken. The migration path is to enable the hybrid key exchange in the VPNs and the TLS terminators that support it, and to verify that the hybrid key exchange is actually being used (not just enabled in the configuration). The hybrid key exchange is the no-regret step that organizations can take today.
The fourth step is to plan the long-lived encrypted data re-encryption. The data that is most at risk from the eventual quantum threat is the data that was encrypted with a current public-key algorithm and is expected to remain confidential for years or decades. The inventory should identify the data stores that contain long-lived encrypted data, and the migration plan should re-encrypt the data with a PQC algorithm as soon as the algorithm is operationally supported. The re-encryption is the operational work that has to happen before the cryptographically-relevant quantum computer exists; doing it after is too late.
Common mistakes
The first mistake is treating PQC as a research problem rather than an operational planning concern. The standards are published, the vendors are working on the roadmaps, and the federal government has signaled a migration timeline. The PQC migration is an operational reality that is coming, and the right operational response is to start the planning now. Treating it as a research problem that can be deferred until the algorithms are more mature is deferring the planning until the migration becomes a deadline, which is the worst possible operational posture.
The second is assuming that the migration is a vendor problem. The vendors are working on the PQC support, but the migration requires the organization to know where the cryptography lives, to plan the upgrades in line with the vendor roadmaps, and to verify that the upgrades are actually being used. An organization that assumes the vendor will handle the migration is an organization that does not have the visibility to know whether the migration is happening as planned. The right operational discipline is for the organization to own the migration plan and to engage with the vendors as the implementation partner.
The third is overlooking the operational complexity of the hybrid key exchange. The hybrid key exchange that combines a classical algorithm with a PQC algorithm is the operational mechanism that provides defense in depth, but the hybrid configuration adds complexity to the VPN and TLS configurations, and the operational discipline to manage the hybrid configuration is not trivial. The right operational answer is to enable the hybrid key exchange in a controlled environment first, to verify the operational behavior, and to roll out to production in a phased manner.
The fourth is underestimating the time required for the migration. The PQC migration is not a weekend project; it is a multi-year program that affects every cryptographic function in the network. The migration requires the inventory, the vendor engagement, the hybrid key exchange rollout, the firmware upgrades, the certificate migrations, the long-lived data re-encryption, and the third-party integrations. The right operational discipline is to plan the migration as a multi-year program and to staff it accordingly.
Defensive guidance
Start the inventory now. The inventory is the foundation for the migration plan, and the migration plan cannot start until the inventory is current. The inventory should identify every place that cryptography lives in the network, and the inventory should be in a queryable form that can be filtered by the migration priority. The inventory is the no-regret starting point that every organization can begin today.
Engage with the vendors on the PQC roadmap. The vendors are the implementation partner for the migration, and the vendor engagement is the operational mechanism that aligns the migration plan with the vendor's roadmap. The right operational discipline is to engage with every vendor that provides cryptographic functionality in the network, to understand the vendor's PQC roadmap, and to plan the upgrades in line with the roadmap.
Enable the hybrid key exchange where it is available. The hybrid key exchange is the no-regret step that organizations can take today, and the operational benefit is the defense in depth that the hybrid configuration provides. The right operational discipline is to enable the hybrid key exchange in the VPNs and the TLS terminators that support it, to verify that the hybrid key exchange is actually being used, and to monitor the operational behavior for any regressions.
Plan the long-lived encrypted data re-encryption. The data that is most at risk from the eventual quantum threat is the data that was encrypted today and is expected to remain confidential for years or decades. The inventory should identify the data stores that contain long-lived encrypted data, and the migration plan should re-encrypt the data with a PQC algorithm as soon as the algorithm is operationally supported. The re-encryption is the operational work that has to happen before the cryptographically-relevant quantum computer exists; doing it after is too late.
Track the federal and regulatory timelines. The federal government has signaled an aggressive timeline, and the regulated industries that follow the federal lead are likely to follow the federal timeline. The right operational discipline is to track the federal and regulator-specific guidance, and to plan the migration in line with the regulator's expectations. An organization in a regulated environment that defers the planning until the regulator issues a deadline is an organization that will be scrambling at the deadline.