In Unit 2 you got a map, the Migration Stakes Tour showed you every system that needs to move from classical cryptography to quantum-safe algorithms. In Unit 4, lessons 4.1 through 4.3 built the architectural and planning foundations for that move. Now it is time to go deep on networks.
Networks are hard for three reasons that software migration doesn't share. First, every protocol is a negotiation between two endpoints, both sides must support the new algorithm at the same time. You can't quietly upgrade one end and leave the other behind. Second, much of your network infrastructure is hardware: the VPN appliance in the rack, the firewall handling TLS inspection, the DNS resolver your ISP controls. Software updates often can't fix hardware limitations. Third, network protocols are tightly standardized. You cannot deploy a custom PQC cipher suite in your VPN until the standards bodies finalize the spec, the vendors implement it, and your peers' equipment recognizes it.
This lesson covers the four protocol families that appear on the network migration checklist: VPN, TLS, DNSSEC, and routing. For each one you will see: what the current state of PQC support looks like, what the migration path involves, and what the honest blockers are. By the end, every row of your network checklist should have a name attached to it.
Deliverable B asks you to mark which items on the network migration checklist apply to your defined scope, with a priority ranking and estimated timeline for the top five items. Everything in this lesson maps directly to that checklist. Take notes as you go.
You're building fluency so you can participate credibly in technical discussions. This lesson is where you will hear people in PKIC working groups spend most of their time, protocol migration is the daily reality of PQC work right now. Understanding VPN and TLS migration at this level of detail will let you follow and contribute to those conversations. Focus especially on the hybrid approach and why it exists: it is the dominant real-world deployment strategy and knowing it cold will signal expertise.
You may not operate the network yourself, but you are signing the contracts with the vendors who do. The checklist work in this lesson translates directly into questions for your IT team or managed service provider: "Have you assessed our VPN firmware for PQC readiness? Are we running hybrid TLS in any client-facing services?" If the answer is a blank look, that is useful information. Use the protocol summary table in the Checklist section to anchor that conversation.
This is the operational center of the course for you. Every protocol here is something you manage. By the end of this lesson you should be able to map your current environment against each protocol's migration state, identify which items are blocked on vendor timelines, and write the first draft of your annotated network checklist. Pay particular attention to the VPN section, that is where most organizations get surprised by the firmware dependency problem.
Cipher suite — the combination of algorithms a protocol uses for key exchange, authentication, and encryption. When you upgrade to PQC, you are changing the cipher suite.
Hybrid mode — a configuration where both a classical algorithm and a PQC algorithm are used together. The connection is only as strong as the stronger of the two, but this approach allows compatibility with endpoints that don't yet support PQC.
IANA — Internet Assigned Numbers Authority. The organization that maintains official registries of protocol parameters, including cipher suite identifiers. A PQC cipher suite isn't usable until IANA assigns it a number.
Virtual Private Networks (VPNs) secure traffic between two endpoints, a remote worker and a corporate network, two branch offices, a company and its cloud provider. Under the hood, most VPNs use one of two protocols: IPsec (Internet Protocol Security) or SSL/TLS-based VPN (like OpenVPN or Cisco's AnyConnect). Both depend on public-key cryptography for the key exchange that establishes the encrypted tunnel.
That key exchange is exactly what Shor's algorithm breaks. When a quantum computer powerful enough to run Shor's algorithm exists, an attacker who captured your VPN traffic today can retroactively decrypt it. For organizations handling data with long confidentiality requirements, government contracts, health records, financial models, that is not a theoretical risk. It is a design requirement.
The IETF (Internet Engineering Task Force) has been working on integrating PQC into IPsec and IKEv2 (the key exchange protocol that IPsec uses) for several years. As of mid-2026, the situation is:
Here is the practical reality that surprises most organizations. Software-defined systems, web servers, applications, cloud services, can often be updated through a configuration change or a library version bump. VPN appliances are different. They run firmware: embedded software that is written to specific hardware and controls everything the device does.
Firmware updates for PQC support require the vendor to:
This takes time, typically 12–18 months from when a vendor decides to prioritize a feature. And if your appliance is at end-of-life, the vendor may never release a PQC firmware for it. That means a hardware refresh conversation becomes part of your migration plan.
If an adversary has been capturing your site-to-site VPN traffic, they have copies of everything that went through those tunnels. When a cryptographically relevant quantum computer arrives, those recordings can be decrypted. Organizations whose VPN carries data with a 10+ year confidentiality requirement should treat VPN migration as urgent, not because the quantum computer exists today, but because the data they need to protect is already being harvested.
Transport Layer Security (TLS) is the protocol that secures your web traffic, the padlock in your browser, the encryption on your API calls, the protection on your email. It is the most widely deployed security protocol on the internet. And it is the protocol where PQC migration is furthest along, but that doesn't mean it's simple.
In Unit 2, Lesson 2.2, you saw a live demo of hybrid TLS. This section goes deeper on the migration path.
TLS 1.3, the current version, released in 2018, was designed with algorithm agility in mind. It uses a mechanism called Key Share Groups (or Named Groups) that allows the key exchange algorithm to be swapped out. This means PQC can be dropped in without a protocol version change. That is genuinely good news.
The hybrid approach that has emerged, combining a classical Diffie-Hellman key exchange with ML-KEM, is what major browsers and CDNs have been deploying since 2024. The IETF's RFC 8446 (TLS 1.3) combined with a PQC key exchange draft gives us a stable operational base.
The reason TLS migration is more complex than it first appears is that TLS actually uses cryptography in two distinct ways, and they migrate on different schedules.
The key exchange is what protects the data in transit. It's the part where "harvest now, decrypt later" applies. Hybrid ML-KEM is deployable today, is supported by major TLS libraries (OpenSSL 3.x, BoringSSL, LibreSSL), and doesn't require changing certificates. This is the first and most urgent layer to migrate.
Check: Is your server running OpenSSL 3.2 or later? If yes, hybrid key exchange is available with a configuration change. If not, an upgrade path exists.
The certificate is what proves the server is who it claims to be. Currently signed with RSA or ECDSA. Migration requires your CA (certificate authority) to support PQC signature algorithms. Commercial CAs are working on this but it is not yet widely available. Expect 2027–2029 for mainstream availability.
The path: eventually you will receive a PQC-signed certificate from your CA, install it on your server, and retire the classical certificate. Until then, the hybrid model, PQC key exchange, classical certificate, is the correct interim position.
The PKIC working groups are actively debating the certificate migration timeline and the performance implications of larger PQC certificate chains. Understanding why there are two layers, key exchange and authentication, and why they migrate independently is the kind of nuance that separates people who've read a summary from people who understand the architecture. Lock that distinction in.
If your website runs on any modern cloud or CDN platform (Cloudflare, AWS CloudFront, Azure Front Door), you may already have hybrid TLS on the key exchange layer without knowing it, many providers have enabled it by default. Ask your web team or hosting provider to confirm. The certificate migration that comes later will require action from you: renewing certificates with a CA that supports PQC signatures. That is a 2027–2029 horizon item to note in your planning.
Two concrete actions to add to your checklist. First: audit your TLS termination points, web servers, load balancers, API gateways, mail servers. Check which OpenSSL or TLS library version they're running. Anything on OpenSSL 3.2+ can enable hybrid key exchange now. Second: map your certificate inventory against CA support. Which of your certificates are from CAs that have announced PQC roadmaps? Let's Encrypt, DigiCert, and Sectigo have all published timelines, check where your CAs stand.
The Domain Name System (DNS) is the internet's address book, it translates domain names like "example.com" into IP addresses that computers use to find each other. DNSSEC (Domain Name System Security Extensions) adds cryptographic signatures to DNS responses, so your computer can verify that the answer it received hasn't been tampered with.
DNSSEC is not the most urgent protocol on the migration list: DNS responses are not secret, so "harvest now, decrypt later" doesn't apply to confidentiality. The risk is different: a quantum computer could forge DNSSEC signatures, redirecting users to attacker-controlled servers. That is a serious integrity threat, but it requires an operational quantum computer rather than a capable-but-not-yet-quantum adversary.
For most organizations, the honest checklist entry for DNSSEC is: "Monitor IETF and ICANN developments. No unilateral action possible until root zone migration begins. Review annually." If you operate your own authoritative nameservers for sensitive internal domains, add: "Assess DNS operator's PQC roadmap by [date]." That is the correct posture, this is not a problem you can solve ahead of the ecosystem.
Routing protocols — BGP (Border Gateway Protocol), OSPF (Open Shortest Path First), IS-IS — are what routers use to learn about the network topology and decide where to send traffic. Securing these protocols matters because a compromised routing table can redirect internet traffic at scale.
BGP in particular has a troubled security history. RPKI (Resource Public Key Infrastructure) was introduced to cryptographically validate BGP route origin announcements, essentially, to prevent one network from falsely claiming it owns IP address space it doesn't. RPKI uses standard X.509 certificates and RSA or ECDSA signatures.
If you're ranking protocols for migration urgency, the consensus ordering based on confidentiality risk and standards maturity is:
1. TLS key exchange (do this now, hybrid ML-KEM is available) → 2. VPN (plan and pilot) → 3. DNSSEC (monitor) → 4. Routing / RPKI (monitor)
The ordering reflects both the "harvest now, decrypt later" risk (confidentiality first) and the availability of usable standards and implementations (TLS furthest along).
The priority ordering above, TLS first, VPN second, DNSSEC and routing as "monitor" items, is the consensus that practitioners debate in working groups. Understanding why this ordering exists (confidentiality risk and standards maturity) and being able to defend it gives you a genuine contribution to make in those conversations. The people who can articulate trade-offs, not just list protocols, are the ones who move discussions forward.
The message for you is: you probably don't run BGP, so routing migration is not your problem. Your network migration priorities are TLS (ask your hosting provider if hybrid key exchange is enabled), and VPN (ask your IT team or MSP about their PQC roadmap for the VPN appliances protecting your remote access). Those two conversations will tell you most of what you need to know about your organization's network migration exposure.
For your network migration checklist: TLS is your highest-priority active item with concrete steps you can take now. VPN requires a vendor assessment, pull firmware versions and check support pages this week. DNSSEC: add a 6-month calendar reminder to check IETF and ICANN status. Routing: if you don't operate BGP, this row is "N/A, not in scope." If you do operate BGP or RPKI, add "monitor IETF SIDROPS" and review annually. That is the complete and honest posture for the current moment.
Below is a condensed version of the network migration checklist from your course workbook. For each item, the phase stepper walks you through where most organizations are in the migration. Use this as your reference when completing Deliverable B.
| Protocol | PQC urgency | Standards maturity | Your action now |
|---|---|---|---|
| TLS 1.3 (web, API) | 🔴 High — confidentiality at risk from HNDL | Hybrid ML-KEM available in major libraries | Enable hybrid key exchange on servers running OpenSSL 3.2+ |
| TLS certificates | 🟡 Medium — authentication forgery requires quantum computer | CA support in development, 2027+ expected | Map certificate inventory; monitor CA roadmaps |
| IPsec / IKEv2 (VPN) | 🔴 High — confidentiality at risk from HNDL | RFC 9370 available; vendor support uneven | Audit firmware versions; identify PQC-capable appliances; plan refresh budget |
| DNSSEC | 🟡 Medium — integrity risk requires operational QC | IETF drafts in progress; no RFC yet | Monitor ICANN and IETF; no unilateral action possible |
| BGP / RPKI | 🟢 Lower — depends on organizational role | Early research phase | Monitor IETF SIDROPS; N/A if you don't run BGP |
These questions test understanding, not memorization. Each wrong answer includes a full explanation of why it's wrong. You can retake this as many times as you need.
You now have everything you need to begin the network portion of Deliverable B. Open your course workbook's network migration checklist tab. Go through each row. Mark whether it applies to your defined scope. For any row that applies, note the current state and your estimated timeline. Prioritize the top five items. The summary table in Section 6 above is your reference.