PQC Workforce Readiness Training and Organisational Change Management

Post-quantum cryptography (PQC) workforce readiness training and organisational change management describe the structured process by which regulated organisations identify role-specific cryptographic knowledge gaps, deliver differentiated training, and govern the cultural and operational transition away from classical algorithms before quantum computers make today’s encrypted data recoverable. For government bodies, financial institutions, healthcare providers, and legal firms operating under EU law, this is not an optional uplift: it is a compliance obligation with a defined timeline.

The Regulatory Clock Is Already Running

The EU PQC Transition Roadmap 2026-2030, published by the NIS Cooperation Group, sets explicit migration horizons that translate directly into workforce obligations. Organisations that treat PQC as a future infrastructure project, rather than a present training and governance problem, will arrive at those horizons without the internal competence to execute a migration safely.

NIST finalised three post-quantum cryptographic standards in August 2024: ML-KEM (FIPS 203), ML-DSA (FIPS 204), and SLH-DSA (FIPS 205). These are now the reference algorithms for procurement, architecture, and compliance purposes across the EU. The ENISA Threat Landscape 2023 identified cryptographically relevant quantum computers as a credible threat within a ten-year horizon, which directly validates the harvest-now-decrypt-later attack model: adversaries intercepting encrypted traffic today can store and decrypt it once quantum capability arrives.

“Organisations that wait for quantum computers to arrive before migrating their cryptography will have already lost the battle. The harvest-now, decrypt-later threat means the clock started years ago.” — ENISA, post-quantum cryptography guidance publications

The IBM Cost of a Data Breach Report 2023 recorded the average breach cost at USD 4.45 million, the highest figure in the report’s history. For regulated sectors, add regulatory fines, supervisory action, and reputational damage. PQC workforce readiness is therefore also a financial risk management measure.

Mapping Role-Specific Competency Gaps

A PQC competency gap analysis must be role-differentiated from the outset, because the knowledge deficit differs fundamentally between a CISO, a network engineer, and a procurement officer.

The gap analysis should be structured in three phases. First, inventory current cryptographic literacy through a baseline assessment, using questionnaires aligned to ENISA’s post-quantum cryptography guidance publications as the reference standard. Second, map each role against the EU PQC Transition Roadmap 2026-2030 milestones to determine which gaps are time-critical. Third, document the findings under ISO/IEC 27001:2022 Clause 7.2, which requires organisations to determine the necessary competence for persons whose work affects information security performance and to retain evidence of that competence.

Designing a Layered PQC Training Programme

A single training module covering all staff is insufficient and will fail both auditors and learners. The programme must operate on three distinct tracks corresponding to the competency levels identified above.

Awareness track for decision-makers

CISOs, board members, and management body members must understand what PQC is, why harvest-now-decrypt-later constitutes a present risk, and what NIS-2 Article 20 requires of them personally. NIS-2 Article 20 mandates that management bodies receive cybersecurity training and approve risk-management measures under Article 21, which explicitly includes cryptographic controls. Training at this level should be delivered in half-day executive workshops and updated annually, with attendance records retained as ISMS evidence.

Implementation track for security and engineering staff

Security architects, network engineers, and DevSecOps practitioners need hands-on knowledge of lattice-based cryptography principles, the specific properties of ML-KEM and ML-DSA, hybrid classical-PQC schemes for transition periods, and crypto-agile architecture patterns. SANS Institute courses covering cryptography (such as SEC575 and SEC504) are beginning to incorporate PQC content. ISC2 has signalled intent to incorporate PQC topics into CISSP and CCSP syllabi updates. ENISA has published dedicated post-quantum cryptography training materials and technical guidelines available at enisa.europa.eu, which serve as the authoritative EU reference for this track.

Procurement and criteria track for compliance and legal teams

Procurement officers and legal counsel must be able to read and evaluate vendor claims about PQC support. This means knowing that ML-KEM replaces Kyber, that ML-DSA replaces Dilithium, and that a vendor claiming “quantum-safe” without naming a NIST-standardised algorithm is making an unverifiable assertion. Training should be delivered as annotated RFP templates combined with short briefings on NIST FIPS 203, 204, and 205 at a non-mathematical level.

Organisational Change Management: Resistance, Vendor Pushback, and Budget Conflicts

The technical migration from classical to PQC algorithms typically meets three types of internal resistance, each requiring a different management response.

Operations teams unfamiliar with lattice-based cryptography often frame PQC migration as unnecessary disruption to stable systems. The CISO should address this by naming the specific regulatory deadline (EU PQC Transition Roadmap 2026-2030) and the specific legal exposure (NIS-2 Article 21 non-compliance) rather than making abstract arguments about quantum computing. Resistance grounded in unfamiliarity is best resolved through the implementation training track described above, not through executive mandates alone.

Vendor pushback is common when procurement contracts do not currently require crypto-agility. Hardware security module (HSM) vendors, PKI providers, and network security appliance manufacturers may cite upgrade timelines extending beyond 2028. The response is to update RFP templates now so that future contracts require evidence of ML-KEM, ML-DSA, and SLH-DSA support and explicit crypto-agility, meaning the ability to swap algorithms through configuration rather than hardware replacement.

Budget prioritisation conflicts arise because PQC migration competes with immediate operational spending. The CISO should structure the PQC programme management office (PMO) with a named executive sponsor, a dedicated budget line, and a phased roadmap aligned to the EU PQC Transition Roadmap milestones. The PMO should produce quarterly evidence packages showing progress against the roadmap, which simultaneously serve as audit documentation under ISO/IEC 27001:2022 and DORA Chapter II.

“Cryptographic agility is not a feature, it is a survival requirement. Systems that cannot swap algorithms without redesign will become liabilities the moment a cryptographically relevant quantum computer emerges.” — NIST National Cybersecurity Center of Excellence, NCCoE Migration to Post-Quantum Cryptography project

Embedding PQC Migration in ISMS Governance

The PQC migration programme becomes auditable only when it is embedded in existing governance structures rather than managed as a standalone project with its own lifecycle.

Under ISO/IEC 27001:2022, the PQC migration should appear in the risk register as a named risk (cryptographic obsolescence), with the training programme recorded as a risk treatment control under Annex A control 8.24 (use of cryptography) and competence evidence retained under Clause 7.2. The NIST CSF 2.0 Govern function provides a complementary policy and accountability layer: organisations should define PQC-specific policies, assign ownership, and record governance decisions in a form that is reproducible for auditors.

NIS-2 Article 21 requires essential and important entities to implement risk-management measures that include cryptographic policies and access controls. A PQC migration programme that is documented, resourced, and tracked against the EU PQC Transition Roadmap 2026-2030 directly satisfies this requirement and provides the evidence trail that national competent authorities will expect when Article 21 compliance is assessed.

For financial institutions, DORA Article 13 requires ICT security awareness programmes to be maintained for all staff and specialist training for ICT staff. The PQC training programme described above maps directly onto this requirement when it is documented with role-differentiated content, delivery records, and a defined refresh cycle. Supervisors including the ECB and national competent authorities may inspect these records during DORA oversight cycles beginning in 2025.

Updating Procurement for PQC: RFPs, Vendor Assessments, and Contract Clauses

Procurement teams represent one of the most consequential control points in the PQC transition. A sovereign infrastructure contract signed today without crypto-agility requirements may lock an organisation into classical cryptography through 2030 or beyond.

RFP templates should require vendors to declare: which of FIPS 203 (ML-KEM), FIPS 204 (ML-DSA), and FIPS 205 (SLH-DSA) they currently support; their documented timeline for full support if not yet available; whether algorithm switching requires hardware replacement or only configuration change (the definition of crypto-agility); and whether their product has been evaluated against ENISA’s post-quantum cryptography guidelines. Vendor assessment questionnaires should require written responses rather than checkbox assertions, and answers should be verifiable through product documentation or third-party audit reports.

Contracts should include a crypto-agility clause requiring vendors to support new NIST-standardised algorithms within a defined period (typically 12 to 18 months of finalisation) and to notify the customer of any dependency on algorithms deprecated by NIST or ENISA. This contractual mechanism converts a technical obligation into an enforceable legal one.

FAQ

Which staff roles need the deepest PQC technical knowledge, and which need only awareness?

Security architects, network engineers, and DevSecOps staff need implementation-level knowledge of ML-KEM, ML-DSA, and SLH-DSA and hands-on experience with crypto-agile design patterns. CISOs, DPOs, and senior management need conceptual awareness sufficient to make risk-informed decisions and satisfy NIS-2 Article 20 training obligations. Procurement and legal teams need enough criteria knowledge to evaluate vendor claims and write enforceable RFP requirements.

Does NIS-2 Article 20 require organisations to specifically train management on post-quantum cryptography?

Article 20 requires that management bodies receive cybersecurity training sufficient to identify and assess risks and their impact on the services the entity provides. While it does not name PQC explicitly, the EU PQC Transition Roadmap 2026-2030 published by the NIS Cooperation Group makes quantum risk a defined compliance horizon, meaning regulators and auditors can reasonably expect management training to cover it.

How should an organisation’s ISMS under ISO/IEC 27001:2022 accommodate PQC migration?

ISO/IEC 27001:2022 Clause 7.2 requires documented competence evidence for all roles affecting information security. A PQC programme should be recorded as a formal project within the ISMS risk treatment plan, with training completion records, algorithm inventory updates, and crypto-agility assessments treated as controlled evidence. The NIST CSF 2.0 Govern function provides a complementary framework for setting policy and accountability structures around the migration.

What should an RFP for sovereign infrastructure include to test genuine PQC readiness?

RFPs should require vendors to name the specific NIST-standardised algorithms they support (ML-KEM, ML-DSA, SLH-DSA), provide evidence of crypto-agility through documented API or configuration-level algorithm switching, specify their migration timeline against the EU PQC Transition Roadmap 2026-2030, and disclose any dependency on classical-only hardware security modules. Vendors that cannot answer these questions in writing should be treated as non-crypto-agile.

How does DORA Article 13 interact with a PQC training programme in financial institutions?

DORA Article 13 requires financial entities to run regular ICT security awareness programmes and specialist training for ICT staff. A PQC training programme satisfies this requirement when it is documented, role-differentiated, repeated on a defined cycle, and tied to the institution’s ICT risk management framework under DORA Chapter II. Supervisors such as the ECB and national competent authorities can inspect training records during DORA oversight cycles.