Module 1 The Quantum Threat to Cryptography

What quantum computers can and cannot do, and how Shor’s algorithm would break RSA, elliptic-curve cryptography and Diffie-Hellman on a cryptographically relevant quantum computer (CRQC). Why symmetric algorithms such as AES and hash functions are less affected. You learn to tell quantum advantage demonstrations from cryptographically relevant capability, and physical qubits from logical ones. You read resource estimates and error-correction results, and build a defensible timeline assessment from the evidence rather than from vendor predictions. You apply Mosca’s inequality to decide when migration has to start. You also work through the harvest-now-decrypt-later (HNDL) and trust-now-forge-later (TNFL) threat models, and identify the assets in your organization that each one applies to.

Module 2 Regulatory and Market Drivers

CNSA 2.0 and the US government timeline, including the January 2027 acquisition gate. EU quantum-readiness initiatives and the NIS2 connection. Sector mandates in financial services (G7 Cyber Expert Group, the PCI DSS cryptographic inventory requirement), telecommunications (GSMA PQ.01–PQ.07) and defense (NSM-10). How supervisors, clients, investors and insurers add pressure beyond regulation. You learn to separate the migration work that regulations mandate from the work your own risk assessment requires, and why your organization needs both.

Module 3 Post-Quantum Standards and Algorithm Selection: NIST and Beyond

How NIST ran the standardization process, and what it produced. ML-KEM (formerly CRYSTALS-Kyber) for key encapsulation. ML-DSA (formerly CRYSTALS-Dilithium) for general-purpose signatures. SLH-DSA (formerly SPHINCS+), the conservative hash-based alternative. FN-DSA (formerly FALCON), still in standardization as FIPS 206, for compact signatures. HQC, the code-based KEM that NIST selected in March 2025 for algorithmic diversity. For each algorithm, you examine the underlying mathematical problem, performance, key, ciphertext and signature sizes, and NIST security categories. You then choose the right algorithm for a deployment: when ML-KEM is the default, when SLH-DSA’s conservative assumptions are worth its larger signatures, and when FN-DSA’s compact signatures matter. We also cover the latest post-quantum algorithm choices outside the NIST process, from other countries and standards bodies.

Module 4 Cryptographic Inventory and CBOM

Finding every place your environment uses cryptography: application code, TLS, SSH and IPsec configurations, certificates, key management, database and disk encryption, hardware security modules and third-party services. In a hands-on exercise, you inventory a sample environment and build a Cryptographic Bill of Materials (CBOM) in a standardized format. You automate discovery where tooling exists and handle the gaps where it does not. You then score each asset with a risk-weighted model to set the migration order.

Module 5 Hybrid Implementations

Hybrid cryptography uses classical and post-quantum algorithms together. BSI and ANSSI recommend it, NIST permits it, and the UK NCSC treats it as an interim step with a planned exit to pure PQC. You cover hybrid key exchange in TLS 1.3, with the concatenation and combiner approaches, and how to construct hybrid signatures. You also cover the performance and bandwidth costs, fallback and negotiation, and what a hybrid exit involves. In the lab, you configure hybrid TLS with open-source libraries.

Module 6 Protocol Migration Assessment

What changes in each protocol. TLS 1.3 has the most mature support, with ML-KEM hybrid key exchange already deployed at scale. SSH migration requires key exchange and host key changes. IPsec migration requires IKEv2 integration. S/MIME migration requires certificate chain changes and affects legacy clients. Code signing depends on trust anchors with long lifetimes. You build an assessment for each protocol in your environment: the required changes, the options available today and a migration sequence. You then test PQC-enabled protocol configurations in the lab.

Module 7 Migration Planning and Prioritization

What a migration involves at each phase, using the PQC Migration Framework: from discovery and inventory through implementation, verification and operational handover. Why organizations need years rather than months to complete one, and where they usually start. You turn the inventory into a roadmap: risk-based prioritization, phased delivery from quick wins to architectural changes, pilot design, testing and validation, and rollback planning. As an exercise, you build the roadmap for the simulated migration program.

Module 8 Running the Migration: Project, Change and Vendor Management

Organizations take years to complete a PQC migration, and the work involves teams far beyond security. You learn the management basics a specialist needs to contribute to that program. PQCM Manager Training covers the same topics in depth for the people who lead it.

• Project management. You break the roadmap into workstreams, milestones and dependencies. You estimate effort from the inventory and report progress in measures a program office can track.
• Technical change management. You take cryptographic changes through change control, with test plans, staged rollouts, maintenance windows, certificate rotation schedules and rollback criteria.
• Organizational change management. You identify the system owners, developers and operations teams each change affects, and plan what each group needs to know and when.
• Vendor management. You assess supplier PQC roadmaps and request cryptographic disclosures such as a CBOM. You also add quantum-safe requirements to procurement and contract renewals, and plan around vendors who have not yet shipped PQC support.

You then turn your Module 7 roadmap into a project plan with owners, change windows and vendor dependencies.

Module 9 Cryptographic Agility

PQC will not be the last cryptographic transition. You learn to design systems that can change algorithms with bounded effort, at the application, protocol and infrastructure layers. You test architecture patterns against one question: how much work does an algorithm change take? You finish with a self-assessment of the systems you work with today.