Unit 3 · Level 2 → Level 3 · Inventory, CBOM & Crypto Agility
The Network Migration
Checklist in Context
The network layer is where quantum-vulnerable cryptography is most visible and most actively exploited. This lesson covers the checklist items that are specific to protocols, infrastructure, and cryptography that moves across wires, the layer where Harvest Now Decrypt Later starts.
Part 1
Why the Network Layer Gets Its Own Checklist
The Corporate Migration Checklist from Lesson 3.5 covers the organizational program, governance, inventory, assessment, remediation, validation, and monitoring. It applies to every cryptographic asset in every part of the organization.
The Network Migration Checklist is different. It is specifically scoped to cryptography that operates at the network layer — the protocols, devices, and configurations that govern how data moves between systems. This layer deserves a dedicated checklist for three reasons.
First, the network layer is where Harvest Now Decrypt Later attacks happen. An adversary cannot easily intercept application-layer cryptography embedded in a desktop application. But they can, and nation-state actors do, capture network traffic at scale. Every TLS handshake, every VPN session, every SSH connection that crosses a network boundary is potentially being archived for future decryption. The network layer is the primary HNDL attack surface.
Second, network cryptography has unique deployment challenges. Unlike application-layer cryptography, which can often be updated by modifying a single service, network cryptography touches every device and endpoint in the environment. A change to a VPN gateway's cipher suite must be compatible with every client connecting to it. A change to a certificate authority's algorithm affects every certificate issued downstream. The blast radius of a network cryptography change is organization-wide.
Third, the network layer has its own specific protocol vocabulary. TLS, SSH, IKEv2, DNSSEC, BGP, each has its own algorithm configuration, its own migration path, and its own specific vulnerabilities. The network checklist addresses each of these explicitly.
⚠ The Most Urgent Layer
If your organization does nothing else in the near term, migrating the network layer, specifically VPN key exchange and externally facing TLS, is the highest-impact action. It directly addresses the HNDL threat and protects the data that is most exposed to interception. Everything in this lesson is oriented toward that goal.
Part 2
The Network Cryptography Stack — Where Quantum Exposure Lives
Quantum-vulnerable cryptography is present at multiple layers of the network stack. The exposure profile is different at each layer. Click any layer to see where the vulnerability lives and what migration looks like.
Where the exposure is: The TLS handshake uses asymmetric cryptography for two purposes: key exchange (ECDHE or RSA key transport) and authentication (certificate signature verification). Both are broken by Shor's algorithm. The symmetric cipher used for bulk data encryption (AES-128-GCM or AES-256-GCM) is not broken, only the handshake is vulnerable.
Why HNDL applies here: An adversary who captures the TLS handshake today has the encrypted session key material. When a quantum computer is available, they can recover the session key from the handshake and decrypt all traffic captured from that session. Every HTTPS request your organization has ever made is potentially archived and waiting.
Migration path: TLS 1.3 already supports algorithm negotiation, cipher suite lists are configurable. When a hybrid ML-KEM key exchange group is available in your TLS library (OpenSSL 3.5+, BoringSSL, rustls), add it to the supported groups list. Configure servers to prefer hybrid groups when clients support them. The migration does not break backward compatibility, clients that don't support the hybrid group fall back to ECDHE automatically.
Priority by certificate vs. key exchange: The key exchange algorithm is the HNDL risk (it protects session data in transit). The authentication certificate has a longer migration window because it is replaced at renewal. Prioritize key exchange (cipher suite configuration) over certificate algorithm migration, the former is faster and has higher HNDL impact.
Where the exposure is: VPN protocols use asymmetric key exchange to establish the tunnel: IKEv2 uses DH or ECDH groups, WireGuard uses Curve25519, OpenVPN uses RSA or ECDH. All of these are broken by Shor's algorithm. The VPN tunnel itself (ESP in IPsec, ChaCha20 in WireGuard) uses symmetric encryption that is not broken.
Why VPN is the highest-priority network item: VPNs protect the most sensitive organizational data, internal communications, file transfers, authentication traffic, and database connections that traverse remote access tunnels. This is exactly the traffic an adversary wants to archive for HNDL decryption. VPN key exchange is the single highest-priority item in most corporate network migration checklists.
Migration path by protocol:
IKEv2/IPsec: Add ML-KEM groups to the IKE proposal set. Most enterprise-grade VPN gateways (Cisco, Palo Alto, Fortinet) have vendor roadmaps for PQC IKE support. Check your firmware version and the vendor's PQC release notes.
WireGuard: The upstream WireGuard protocol does not yet have an official PQC extension, but several hybrid implementations exist (e.g., the mew-pq fork, and Cloudflare's CIRCL library). Monitor the upstream project for the official PQC extension.
OpenVPN: OpenVPN 2.6+ supports TLS 1.3 for the control channel, which enables hybrid PQC key exchange via the TLS layer when the OpenSSL backend supports it.
Where the exposure is: SSH uses asymmetric cryptography in two places: host key authentication (RSA, ECDSA, or ed25519) and key exchange (ECDH or DH groups). Ed25519 is elliptic curve cryptography and is weakened (not fully broken) by Shor's algorithm, it provides ~128-bit classical security but has reduced post-quantum security. RSA and standard ECDSA host keys are fully broken by Shor's.
Migration path: OpenSSH 9.0+ includes support for the sntrup761x25519-sha512@openssh.com hybrid key exchange (combining Streamlined NTRU Prime 761 with X25519). This is already deployed as the default in recent OpenSSH builds. For host keys, the migration path to ML-DSA host keys is on the OpenSSH roadmap. Check your SSH server version, if you're running OpenSSH 9.0+, hybrid key exchange is likely already active.
Authorized keys inventory: Each authorized_keys file on each server is a cryptographic asset inventory problem. A large organization may have thousands of RSA public keys registered across hundreds of servers. Auditing and rotating these is a significant but necessary migration task.
Where the exposure is: DNSSEC uses asymmetric digital signatures to authenticate DNS records. Zone signing keys (ZSKs) and key signing keys (KSKs) use RSA or ECDSA, both broken by Shor's algorithm. A quantum attacker who can forge DNSSEC signatures can redirect DNS queries to attacker-controlled servers, enabling large-scale man-in-the-middle attacks across the internet.
Why medium-term rather than immediate: DNSSEC forgery requires a quantum computer to be operational, it is not a HNDL-style pre-collection attack. The attack is real-time, not retrospective, so there is no current data at risk from future decryption. The urgency is high but slightly behind VPN and TLS key exchange.
Migration path: DNSSEC algorithm migration requires coordination with your DNS registrar, DNS hosting provider, and the parent zone (for delegation). IETF has active work on PQC DNSSEC algorithms. The ICANN DNSSEC root key is managed by a global governance process, watch for root KSK rollover announcements. For zone operators: follow your DNS provider's migration guidance when PQC algorithms are available in their platform.
Where the exposure is: BGP itself does not use asymmetric cryptography directly, but BGP session authentication (TCP-AO) and Route Origin Authorization (ROA) certificates in RPKI use X.509 certificates with RSA or ECDSA. A quantum attack on RPKI certificates could enable large-scale BGP route hijacking.
Who this applies to: Internet Service Providers, large enterprises running their own BGP, and organizations participating in RPKI. This is not relevant to most corporate environments that use upstream ISP routing without direct BGP management.
Migration path: IETF SIDR-Ops working group has active work on PQC for RPKI. Monitor ARIN, RIPE, and APNIC for guidance on PQC ROA certificates. Timeline is medium-term, the RPKI ecosystem migration requires coordination across regional internet registries.
Where the exposure is: EAP-TLS (used in 802.1X network access control) uses X.509 certificates for mutual authentication, both the server and client certificates use RSA or ECDSA. Kerberos PKINIT uses X.509 certificates for initial authentication. These are lower HNDL risk than VPN or public HTTPS (they authenticate internal devices, not external sessions), but they establish long-lived session credentials that could be intercepted.
Migration path: EAP-TLS migration requires: updated RADIUS server with PQC certificate support, new client certificates issued to all authenticating devices, and updated 802.1X supplicants on endpoints. This is a significant PKI operation, it touches every managed device in the environment. Coordinate with your NAC (Network Access Control) platform vendor for PQC support timelines.
Kerberos: The Kerberos PKINIT extension (RFC 4556) uses X.509 certificates. Microsoft Active Directory domain controllers using smart card authentication are affected. Monitor Microsoft's PQC roadmap for AD/Kerberos support.
Part 3 — Reference
Protocol Quantum Vulnerability Reference
Use this table as a quick reference when classifying network protocol entries in your CBOM. Each row covers one protocol, its current algorithm, its quantum vulnerability, and the migration action.
| Protocol | Current Algorithm | Quantum Risk | Migration Action | Priority |
|---|---|---|---|---|
| TLS 1.3 Key Exchange | ECDHE (P-256, X25519) | Broken by Shor's | Add ML-KEM hybrid group to cipher suite (X25519MLKEM768 or P256MLKEM768) | Immediate |
| TLS Certificate Auth | RSA-2048 / ECDSA P-256 | Broken by Shor's | Replace with ML-DSA hybrid cert at next renewal when CA supports it | Medium-term |
| IKEv2 / IPsec | DH Group 14/19/20, ECDH | Broken by Shor's | Add ML-KEM DH group to IKE proposal; require hybrid negotiation | Immediate |
| WireGuard | Curve25519 (ECDH) | Broken by Shor's | Monitor upstream PQC extension; consider hybrid fork for high-sensitivity environments | Immediate |
| SSH-2 Key Exchange | ECDH (curve25519-sha256) | Broken by Shor's | OpenSSH 9.0+: hybrid sntrup761x25519 already default in many distros | Immediate |
| SSH Host Keys | RSA-3072, ed25519 | Weakened (ed25519) / Broken (RSA) | Rotate RSA host keys; monitor OpenSSH for ML-DSA host key support | Medium-term |
| DNSSEC ZSK/KSK | RSA-2048, ECDSA P-256 | Broken by Shor's | Follow DNS provider / registrar PQC algorithm rollout; coordinate key rollover | Medium-term |
| 802.1X EAP-TLS | RSA / ECDSA client certs | Broken by Shor's | Re-issue client certs with PQC algorithm when RADIUS server and supplicants support it | Medium-term |
| TLS Bulk Encryption | AES-256-GCM | Not affected | No replacement needed. Document and monitor. | Monitor |
| IPsec ESP (bulk) | AES-256-GCM | Not affected | No replacement needed. Document and monitor. | Monitor |
📌 A Key Distinction
Key exchange vs. bulk encryption — Notice that the AES-256-GCM rows at the bottom are "Not affected" while the ECDHE and ECDH rows above them are "Immediate." This is because TLS, IPsec, and WireGuard all use a two-layer design: asymmetric cryptography (vulnerable) establishes a shared secret, which is then used as the key for symmetric encryption (AES, not vulnerable). Fixing the asymmetric layer is what protects the session. The symmetric layer does not need to change.
Part 4 — Interactive
The Network Migration Checklist
Click any item to expand its explanation. Check items off as you review them.
Every endpoint that terminates a TLS connection for external clients is a HNDL exposure point. The inventory must capture the endpoint address, the certificate (algorithm, issuer, expiry), the TLS version, and the cipher suite list currently configured. This is the starting point for all TLS migration work.
Prioritize by exposure: Public-facing web servers and APIs are highest priority (most likely to be passively captured). Internal-only TLS endpoints are lower priority but still need to be inventoried and scheduled.
TLS 1.3 is a prerequisite for the hybrid PQC key exchange migration. The hybrid ML-KEM key exchange groups are only available in TLS 1.3. TLS 1.2, while still in wide use, uses older key exchange mechanisms that do not support the new groups.
Why enforce TLS 1.3 now: Even before PQC cipher suites are available, enforcing TLS 1.3 eliminates the weaker cipher suites in TLS 1.2, reduces the HNDL attack surface, and positions the endpoint for the PQC cipher suite addition with no further protocol change required. TLS 1.3 enforcement alone is a migration step, not just a prerequisite.
This is the core TLS migration action. When your TLS library (OpenSSL 3.5+, BoringSSL, or equivalent) supports hybrid ML-KEM key exchange groups, add them to the server's supported groups configuration. The hybrid groups combine ECDHE with ML-KEM, clients that support the hybrid group use post-quantum key exchange; clients that do not fall back to ECDHE automatically.
No disruption: Adding a new key exchange group is backward-compatible. Clients that don't support the new group negotiate ECDHE as before. Clients that do support it automatically benefit from PQC key exchange with no configuration change on their end. This is the lowest-friction migration action in the entire network checklist.
Certificate algorithm migration (replacing RSA/ECDSA certificates with ML-DSA hybrid certificates) depends on your CA issuing PQC certificates. Major public CAs (DigiCert, Sectigo, Let's Encrypt) have published roadmaps for hybrid certificate support. Internal CA migration is within the organization's control and can be planned independently.
Optimal timing: Align certificate migration with the natural renewal cycle. A certificate expiring in 8 months is already on a renewal timeline, if your CA supports hybrid PQC certs by then, migrate at that renewal. Forcing an off-cycle replacement costs time and money; the natural renewal window is free.
VPN gateways are individually diverse, a large organization may run IKEv2 for site-to-site tunnels, WireGuard for remote employees, and OpenVPN for legacy client support, all simultaneously. Each protocol has a different migration path, different vendor dependency, and different timeline. The inventory must capture the protocol type, the key exchange algorithm, the vendor and firmware version, and the vendor's PQC roadmap status.
The firmware version matters: PQC VPN support is a firmware/software update in most cases. Knowing the current firmware version tells you how far you are from a version that supports PQC key exchange.
IKEv2 key exchange is extensible, new DH groups can be added to the IKE proposal set without changing the rest of the protocol. When your VPN gateway vendor releases firmware with ML-KEM group support, add the new group to the proposal set. The IKE negotiation will prefer the new group with clients that support it and fall back to existing groups with clients that do not.
Vendor status (as of 2025): Cisco has published PQC IKEv2 roadmap for IOS-XE and ASA. Palo Alto has PAN-OS PQC support on the roadmap for 2025-2026. Fortinet and Check Point have similar roadmaps. Verify your specific platform and firmware version.
WireGuard's cryptographic design is intentionally simple and minimal, which means adding PQC requires changes to the protocol itself, not just a library update. An official PQC extension for WireGuard is under development but not yet finalized. For organizations running WireGuard in high-sensitivity environments, evaluate hybrid implementations (such as those using the PQXDH key exchange) and test against your client population before production deployment.
For Meridian Agency specifically: WireGuard is rated Immediate priority in the Meridian CBOM. Monitor the upstream WireGuard project and your deployment platform (cloud or self-hosted) for PQC extension availability.
Unlike TLS (where the server can add a new group and clients simply ignore it if unsupported), some VPN client implementations may not handle an unrecognized IKE proposal gracefully, they may fail to connect rather than falling back to a supported group. Test hybrid PQC VPN configuration against your full client population, including legacy OS versions, mobile clients, and third-party clients, before deploying to production.
Rollout strategy: Deploy PQC groups first to a pilot group of technically capable endpoints. Verify connectivity, measure performance (PQC key exchange is slightly slower, confirm it is within acceptable latency budgets), then expand to all endpoints. Keep the existing classical groups in the proposal set throughout the transition period.
OpenSSH 9.0, released in 2022, made sntrup761x25519-sha512@openssh.com the default key exchange algorithm, a hybrid combining NTRU Prime (post-quantum) with X25519 (classical). This means that if both the SSH client and server are running OpenSSH 9.0+, hybrid PQC key exchange is already active with no configuration change required.
Action: Run ssh -V on each server. If the version is below 9.0, upgrade. Most current Linux distributions ship with OpenSSH 9.0+, this is primarily a concern for long-term-support distros (Ubuntu 20.04, RHEL 8) that ship older OpenSSH versions. A package update to a backported OpenSSH may be available without a full OS upgrade.
Every ~/.ssh/authorized_keys file on every server that allows RSA key-based authentication is a CBOM item. RSA public keys in authorized_keys files represent long-lived authentication credentials that are quantum-vulnerable. An audit of authorized_keys files across the server fleet is a discovery task, use a configuration management tool (Ansible, Chef, Puppet) to enumerate and report on key algorithms at scale.
Migration path: Replace RSA keys with ed25519 in the short term (ed25519 is weakened but not broken, and is the best currently available option until ML-DSA SSH keys are standardized). When ML-DSA SSH key support arrives in OpenSSH, plan a second rotation from ed25519 to ML-DSA.
This item is on the network migration checklist for a different reason than quantum vulnerability. SSH password authentication is vulnerable to brute force, credential stuffing, and phishing, these are classical attack vectors that are active today. During the period when you are auditing and rotating SSH keys, ensure that password authentication is disabled (PasswordAuthentication no in sshd_config) so that the key rotation work does not coexist with an open password-based attack surface.
Phased approach: Before disabling password auth, confirm that every user and service account that needs SSH access has a working key-based credential. A misconfigured lockout during this phase can cause significant operational disruption.
Remote Desktop Protocol (RDP) uses TLS for its transport layer when properly configured. The TLS migration actions (TLS 1.3, hybrid key exchange, certificate migration) apply to RDP sessions just as they do to HTTPS. RDP servers running older Windows Server versions may not support TLS 1.3, check the OS version and update or remediate.
Additional check: RDP Network Level Authentication (NLA) uses Kerberos or NTLM. Kerberos PKINIT (used in smart-card authenticated RDP sessions) is covered in the authentication protocol layer above. If your organization uses smart card authentication for RDP, track the Kerberos/AD PQC roadmap separately.
If your organization operates an internal Certificate Authority (Active Directory Certificate Services, Vault PKI, EJBCA, etc.), the root CA certificate is the single most critical cryptographic asset in your network. Every certificate in your PKI chains to it. Migrating the root CA is a multi-phase project: new PQC root generation, new intermediate CAs, re-issuance of all certificates, trust store updates on all endpoints, and validation that all systems accept the new chain.
Lead time: Internal CA root migration typically takes 6–18 months depending on the scale of the PKI and the number of endpoints that need trust store updates. This is the item where "start now" applies most forcefully, even if PQC CA software is not yet available in production form, the planning and testing should begin immediately.
HSMs are the root of trust for key generation and storage in most enterprise PKIs. If the HSM does not support ML-KEM or ML-DSA key operations, it cannot generate or store PQC keys, which means the entire PKI migration is blocked until the HSM is updated or replaced. Check the firmware version of every HSM in the environment against the vendor's PQC support announcement.
HSM vendor status: Thales Luna Network HSM, Entrust nShield, and AWS CloudHSM have all published PQC roadmaps. Verify your specific model and firmware level. Some older HSM hardware may not be upgradeable to support PQC, in that case, hardware replacement may be required before the PKI migration can proceed.
Network infrastructure devices, firewalls, load balancers, switches with management interfaces, all implement TLS and/or IPsec. Their cryptographic capabilities are determined by firmware. A load balancer running firmware from 2021 will not support ML-KEM key exchange even if the upstream library theoretically does, the firmware must be updated.
Network change management: Firmware updates to production network devices are high-risk changes that require change management approval, maintenance windows, and rollback plans. Build the firmware update schedule into the migration plan with appropriate lead time for change approval cycles.
If your organization signs DNS zones with DNSSEC, the Zone Signing Key (ZSK) and Key Signing Key (KSK) algorithms are CBOM entries. Document the current algorithm (RSA or ECDSA), the key size, and the rotation policy. DNSSEC algorithm migration requires coordination with your DNS registrar (for the DS record in the parent zone) and your DNS hosting platform (for the actual signing operation).
What to monitor: Your DNS registrar's announcement of PQC DNSSEC algorithm support. ICANN's guidance on root zone KSK management for PQC. IETF draft specifications for PQC DNSSEC algorithms. This is a medium-term item because the ecosystem dependencies (registrar, parent zone, resolver support) must align before you can migrate.
Network configurations drift. A developer deploys a new service with a default TLS configuration. A load balancer is reconfigured during an incident and the cipher suite list is inadvertently reverted to a weaker profile. Without continuous monitoring, these regressions go undetected.
Implementation: Tools like Qualys SSL Labs API, testssl.sh in a scheduled job, or a dedicated certificate monitoring platform (Keyfactor, Venafi) can be configured to run periodic scans and alert on: weak cipher suites, TLS 1.0/1.1 enabled, certificates within 30/60/90 days of expiry, and, once hybrid PQC groups are deployed, absence of the hybrid key exchange group on a configured endpoint.
A cipher suite policy document defines the approved TLS configuration for each class of endpoint in the organization: which TLS versions are permitted, which cipher suites are approved, which key exchange groups are required, and which are prohibited. This document, enforced via configuration management (Ansible, Chef, or cloud-native policy tools), ensures that every new deployment inherits the correct TLS posture rather than a developer's default.
PKIMM 2.0.0 mapping: Cipher-suite and protocol documentation is assessed under the Governance Cryptography category, not under Key Management or Certificate Management. Those two Management categories no longer include the retired requirements “Cryptographic cipher suites and protocols are documented and maintained” and “Certificate cipher suites are documented.”
PQC relevance: As hybrid PQC groups become available, they are added to the approved list. As classical-only groups are phased out, they are moved to the prohibited list. The policy document is the mechanism by which the organization's TLS posture evolves over time without requiring manual intervention on each individual endpoint.
Network migration is largely gated on vendor firmware release schedules. An organization that is waiting for its VPN gateway vendor to release PQC support needs to know when that release is expected, when it enters general availability, and what the upgrade path looks like. Without a designated team member tracking this, the organization may miss the release and delay migration unnecessarily.
Sources to monitor: Cisco Security Advisories (security.cisco.com), Palo Alto Networks security blog, Fortinet product lifecycle notices, Juniper Security Advisories, and the IETF TLS and IPsec working group mailing lists for protocol-level PQC developments.
Network protocol entries (VPN configurations, TLS cipher suites, SSH key algorithms, DNSSEC signing keys) are cryptographic assets that belong in the organizational CBOM, not in a separate network security spreadsheet. Keeping them unified ensures that the CBOM remains the single authoritative inventory and that migration progress is tracked in one place.
Integration approach: Use the same CycloneDX entry format for network assets as for application-layer assets. The assetType field will typically be "protocol" or "certificate", the same schema covers both. A well-maintained CBOM includes network layer entries alongside application and certificate entries, with consistent algorithm, vulnerability status, and priority tier fields across all asset types.
Persona Perspectives
The Network Layer at Your Level
Network migration has very different implications depending on your role and organizational scale.
Persona A — The Motivated Learner
The network protocol layer is where PQC becomes most tangible and most testable. If you have a Linux or macOS machine with OpenSSH 9.0+, hybrid PQC key exchange is already happening when you connect to a server running OpenSSH 9.0+. You can verify this with ssh -vv user@server and look for sntrup761x25519-sha512 in the KEX negotiation output. That is a real post-quantum key exchange happening on your machine today.
Similarly, if you want to see TLS hybrid key exchange in action, Chrome and Firefox have been testing X25519MLKEM768 in production. Use a browser developer tool or Wireshark to inspect a TLS handshake and look for the key_share extension, if a hybrid group is negotiated, you are seeing PQC in the wild.
These hands-on observations are excellent material for a portfolio, a blog post, or an interview answer to "how do you know PQC is being deployed?" The answer is: because you checked.
Persona B — The SMB Decision-Maker
For Meridian Creative Agency, and for your organization, the most actionable items on the network checklist are the ones that require the fewest moving parts. Here is what you can do right now, without waiting for any vendor:
This week: Ask your IT vendor or MSP to check the OpenSSH version on your servers. If they are running 9.0+, hybrid PQC SSH key exchange is already active. If not, a package update is usually all that is required, this is a low-risk, high-impact action.
This month: Ask your web hosting provider or CDN (if you use one: Cloudflare, AWS CloudFront, etc.) whether they have enabled X25519MLKEM768 on their TLS endpoints. Cloudflare has been running hybrid PQC TLS in production since 2023. If your website is behind a modern CDN, your public-facing TLS key exchange may already be partially PQC-protected with no action required on your part.
This quarter: Ask your VPN provider (WireGuard deployment, cloud VPN, or MSP-managed VPN) for their PQC key exchange roadmap. This is the highest-priority item for your remote team, it is the channel through which all internal business data flows.
Persona C — The IT Professional
The single most impactful action you can take today, with the tools you almost certainly already have, is to check your OpenSSH versions and your TLS library versions. Both have had hybrid PQC support available for some time and deployment may be simpler than expected.
OpenSSH: Run a quick Ansible playbook or SSH command against your server fleet to collect versions. Sort by version. Every server running 9.0+ already has hybrid key exchange available, confirm it is not disabled by explicit KexAlgorithms config that excludes the hybrid group. If it is, remove the explicit restriction and let the default take effect.
TLS: Check your OpenSSL version on application servers and load balancers. OpenSSL 3.5 (released 2025) includes ML-KEM support. If you are running OpenSSL 3.5+ and your load balancer or web server supports the X25519MLKEM768 group, you can add it to the TLSv1.3 groups configuration today. Test in staging first, but this is a config-file change, not a rebuild.
Internal CA: Begin the CA migration planning process now, even if the PQC CA software is not yet production-ready. Scope the PKI, map all certificate-consuming systems, and design the new CA hierarchy on paper. When the software is ready, you will be able to execute quickly because the design is already done.
Comprehension Check
3 QuestionsQuestion 1 of 3
A TLS session uses ECDHE for key exchange and AES-256-GCM for bulk encryption. An adversary captures the full TLS handshake and session data today and stores it. What is their post-quantum attack strategy, and which part of the session does it target?
Question 2 of 3
An organization adds the X25519MLKEM768 hybrid key exchange group to its TLS 1.3 server configuration. A client that does not support this group attempts to connect. What happens?
Question 3 of 3
An organization running OpenSSH 9.2 on all servers checks the SSH key exchange algorithm in use and confirms that sntrup761x25519-sha512@openssh.com is being negotiated with most clients. However, two legacy Windows clients running PuTTY 0.76 are still negotiating curve25519-sha256. Is this a problem, and what is the correct action?