You already know every technology in this lesson. That is the point. This is not a teaching lesson, it is a reframing lesson. For each of ten systems familiar from a first security or networking course (Security+ is one example), the format is the same: you know what this is; here is where the quantum vulnerability lives; here is where it sits on the migration checklist; here is the current status of its replacement path. Two to three minutes per system. Let's move.
Unit 2 progress
By the end of this lesson you will be able to
Identify the specific quantum vulnerability in each of ten familiar systems
Map each system to its migration track (key exchange, certificate, or both)
State the current migration status for each system, live, in progress, or early planning
Explain why IoT and smart card migration are harder than TLS migration
Identify which systems have the longest migration lead time and why
Part 1 — Vulnerability spectrum reference
Before the tour, a quick reference to the vulnerability spectrum from Lesson 0.2. Every system in this tour uses RSA or ECC somewhere, both are in the broken column. The key question for each system is where RSA or ECC appears and what migration looks like for that specific context.
Vulnerability spectrum — quantum impact by algorithm type
Algorithm
Quantum impact
Migration urgency
RSA (all key sizes)
Broken — Shor's
Urgent
ECDH / ECDSA (all curves)
Broken — Shor's
Urgent
Ed25519 / X25519
Broken — Shor's
Urgent
AES-128
Weakened — Grover's
Upgrade to AES-256
AES-256
Quantum-resistant
No action required
SHA-256
Weakened — Grover's
Upgrade to SHA-384+
SHA-384 / SHA-512
Quantum-resistant
No action required
Part 2 — The ten-system tour
Select each system. The format is consistent: what you already know, where the vulnerability lives, migration track, and current status.
1 of 10
Why it is becoming mandatory
The systems on this tour are the technical "why you should migrate" layer. Three regulatory frameworks now add a "why you must" layer for organizations in scope. These are the enforcement mechanisms that turn a technical necessity into a compliance deadline. Lesson 2.5 and Lesson 2.6 treat them in depth.
Financial sector: DORA
EU financial entities (banks, insurers, investment firms, payment institutions, and their ICT third-party providers) are subject to the Digital Operational Resilience Act, in force and being enforced from 17 January 2025. DORA's ICT risk management framework, including Chapter V third-party risk, is the enforcement mechanism: boards are accountable for managing evolving ICT risk, which includes cryptographic risk even though DORA does not name PQC. The January 2026 G7 CEG statement on financial-sector PQC migration signals that supervisors expect this work inside existing DORA frameworks.
EU regulated sectors: NIS2
The NIS2 Directive covers essential and important entities across 18 critical sectors in all EU member states. Article 21 requires cryptography and encryption as a security measure, and requires entities to address cybersecurity in their supply chain, including products and services from direct suppliers. PQC readiness of ICT suppliers is increasingly a due-diligence question under NIS2. Penalties reach €10M or 2% of global turnover for essential entities.
Canada: CCCS ITSM.40.001
The Canadian Centre for Cyber Security published ITSM.40.001 in June 2025, with a companion SPIN effective 9 October 2025. Government of Canada departments must submit an initial PQC migration plan by April 2026, complete high-priority (HNDL-susceptible) systems by the end of 2031, and complete remaining systems by the end of 2035. Annual progress reporting to Treasury Board Secretariat is a Policy on Government Security obligation, not optional guidance.
Part 3 — The migration complexity hierarchy
Not all systems are equally hard to migrate. The difficulty depends on how deeply the cryptography is embedded, how many devices need updating, and who controls the update timeline. This hierarchy shapes your prioritization.
Easiest — software configuration
TLS key exchange (update library version + enable hybrid), browser TLS (auto-updated), cloud service TLS (vendor controls). These migrate via configuration or vendor updates with no hardware dependency.
Moderate — ecosystem dependencies
VPN appliances (firmware update required, vendor timeline), S/MIME and email signing (client + server both need updating), digital signatures (depends on CA ecosystem), SSH (configurable but requires key rotation across all servers).
Hardest — hardware-bound or long lifecycle
Smart cards (physical replacement required for hardware-bound keys), HSMs (firmware update or hardware replacement), IoT devices (hardcoded algorithms, no update mechanism in many cases), timestamping authorities (long-lived archives require backward-compatible verification).
Comprehension check
Question 1 of 3
Why is IoT device migration considered the hardest category in the quantum migration complexity hierarchy?
Question 2 of 3
PGP email encryption and S/MIME email signing both use RSA or ECC. Why does PGP present a uniquely difficult migration challenge compared to most other systems?
Question 3 of 3
Timestamping authorities use RSA or ECDSA to sign timestamps. Why does this create a specific long-term archival problem?