Canada's PQC Roadmap

1. What Canada’s roadmap is—and is not

The Canadian Centre for Cyber Security publication is titled Roadmap for the Migration to Post-Quantum Cryptography for the Government of Canada. Its document version is ITSM.40.001, its status is current, and its publication date is June 23, 2025. The document describes itself as the Cyber Centre’s recommended roadmap for migrating nonclassified IT systems within the Government of Canada to PQC. It outlines stakeholders, execution phases, milestones, and governance to coordinate departmental planning. C11

That scope matters. In the Government of Canada context, “nonclassified” systems manage unclassified, Protected A, and Protected B information. The cited roadmap states that departments handling classified systems or systems handling Protected C information must contact the Cyber Centre for advice on migrating commercial equipment. The roadmap therefore should not be presented as a single migration rule for all information classifications, all Canadian businesses, or all levels of government. [C3]1

The roadmap also reflects an evolving standards environment. The Cyber Centre states that its recommendations for PQC algorithms are provided in ITSP.40.111 and that, as network-security standards support PQC algorithms, it will update its guidance on securely configuring network protocols in ITSP.40.062. Vendors are incorporating PQC into products, but the Government of Canada migration is expected to require significant commitment and take several years. [C5]1

2. Canadian governance and accountability

The Cyber Centre is the Government of Canada’s lead technical authority for information technology security. Its stated roles include promoting awareness of the quantum threat, providing cryptographic recommendations, and advising departments on incorporating cryptography into a strong cybersecurity posture. Treasury Board of Canada Secretariat is responsible for a whole-of-government approach to security management through policy leadership, strategic direction, and oversight. Shared Services Canada manages IT infrastructure and services for many departments and agencies and is engaged in modernization work relevant to PQC migration. C21

The cited Canadian roadmap says that, in May 2024, Treasury Board published the Government of Canada’s Enterprise Cyber Security Strategy, identifying transition to standardized PQC as a key action for protecting Government of Canada information and assets from the quantum threat. It further says Treasury Board will issue necessary policy instruments requiring responsible officials to establish departmental PQC migration plans and report progress under existing departmental reporting processes. This distinguishes an announced policy direction and planned instruments from a claim that the cited roadmap itself is already a generally applicable regulation. [C6]1

The IT security tripartite—Treasury Board Secretariat, Shared Services Canada, and the Cyber Centre—provides advice, guidance, oversight, and direction on Government of Canada-wide cybersecurity initiatives such as migration to PQC. The Government of Canada Enterprise Architecture Review Board provides a governance mechanism for assessing whether proposed enterprise systems align with the enterprise architecture framework. Compliance with Cyber Centre cryptographic recommendations forms part of the Government of Canada target enterprise architecture aligned with Treasury Board strategic direction and policy instruments. [C8]1

For a department, accountability should therefore be treated as distributed but coordinated: business and system owners identify critical services and risk; security and architecture functions establish technical direction; procurement and suppliers provide product evidence; Shared Services Canada may control shared infrastructure; and departmental officials remain responsible for planning and reporting within applicable Government of Canada authorities. The evidence supports this governance model for the federal context, but it does not provide a legal opinion about responsibility in any organization outside that context. C2[C8]1

3. The practical migration sequence

The strongest immediate action is discovery, not indiscriminate algorithm replacement. The Cyber Centre says departments need to understand their cryptography usage and analyze IT infrastructure, hardware, software, and data across the entire enterprise. The cited migration guidance from the UK National Cyber Security Centre similarly begins with identifying key services and applications, recording the data held—including expected lifetime and value to an adversary—and identifying how data is protected in transit and at rest. C521

1. Establish scope and governance. Record which systems are nonclassified and identify any classified or Protected C systems requiring Cyber Centre advice.
2. Create a cryptographic inventory covering applications, services, libraries, devices, certificates, key-management systems, protocols, remote access, backups, and supplier-managed components.
3. Map cryptography to data and business services. Record confidentiality, integrity, authentication, data lifetime, exposure, and dependencies rather than counting algorithms alone.
4. Prioritize systems whose data must remain confidential or trustworthy for many years, systems supporting essential services, externally exposed services, and systems with long procurement or replacement cycles.
5. Assess migration options: upgrade, re-platform, replace, retire, tolerate risk temporarily, or seek a compensating control. Legacy systems that cannot support PQC need an explicit treatment decision.
6. Build migration work into normal technology and infrastructure lifecycles. The Cyber Centre specifically recommends starting early to use existing IT lifecycle budgets as far as possible.
7. Test performance, interoperability, certificate and key-management behavior, operational procedures, monitoring, rollback, and supplier support before production deployment.
8. Maintain a roadmap and evidence trail so departmental plans and progress reports can be updated as policy instruments, standards, and Cyber Centre guidance evolve.

Prioritization should reflect both cryptographic exposure and replacement difficulty. The cited guidance describes legacy systems, long-lived physical infrastructure, outdated protocols, and systems that cannot transition to PQC-compatible operation as planning challenges. Industrial control and operational-technology environments add remote access, wireless field devices, sensors, proprietary protocols, resource constraints, difficult servicing, and devices that may not be upgradeable or replaceable. In those environments, integrity can be critical even where confidentiality requirements are lower, because faulty readings or commands can cause control-system failures. C132

4. Standards, algorithms, and implementation assurance

The cited standards bundle includes three final NIST Federal Information Processing Standards, each published August 13, 2024: FIPS 203 specifies ML-KEM, a module-lattice-based key-encapsulation mechanism; FIPS 204 specifies ML-DSA, a module-lattice-based digital-signature standard; and FIPS 205 specifies a stateless hash-based digital-signature standard. FIPS 203 provides three ML-KEM parameter sets with different security-strength and performance tradeoffs. C15[C17]345

A standardized algorithm is not the same as a secure product or deployment. FIPS 203 states that its security guarantees depend on conditions including protection of randomness, decapsulation keys, and shared secrets. FIPS 204 and FIPS 205 state that conformance does not ensure that a particular implementation is secure and that a conforming product does not guarantee security for the overall system. The responsible authority must ensure that the overall implementation provides an acceptable level of security. C18[C20]345

Procurement and architecture reviews should therefore request more than an algorithm name. They should examine implementation assurance, module validation where applicable, secure key generation and storage, certificate and identity binding, protocol support, parameter choices, update paths, logging, failure handling, and the vendor’s plan for responding to changes in standards or guidance. The cited FIPS 204 evidence also emphasizes that digital signatures are useful when bound to an identity and that implementation requirements include fresh approved randomness for key generation. C2134

Crypto-agility is a useful design objective during this transition. German federal guidance recommends making cryptographic mechanisms flexible enough to respond to developments, implement future recommendations and standards, and replace algorithms whose security is no longer adequate. That guidance is not a Canadian mandate, but it supports a vendor-neutral engineering principle consistent with a multi-year migration and evolving protocol guidance. [C23]6

5. Hybrid cryptography: useful transition, not automatic safety

Hybrid schemes or protocols combine a PQC component with an existing traditional algorithm. ETSI explains that hybrid deployment can mitigate vulnerabilities in a PQC implementation or provide backward compatibility during migration. It can reduce some bandwidth, computation, and latency overheads by pairing a PQC algorithm with a traditional elliptic-curve algorithm, but it increases protocol, implementation, and key-management complexity. [C24]7

Hybrid design must be specific to the use case. The security requirements may differ for confidentiality and authentication. Algorithm negotiation needs downgrade protection, and an inappropriate hybrid construction can be less secure than a properly deployed non-hybrid PQC mode. ETSI also cautions against deploying PQC algorithms that have not undergone standardization or received sufficient analysis, even within a hybrid scheme. [C25]7

A department should document why a hybrid mode is needed, which component provides which security property, how downgrade attacks are prevented, how keys and certificates are managed, and how the organization will move from hybrid to a purely post-quantum configuration when confidence and interoperability permit. The cited ETSI document describes eventual migration to purely post-quantum algorithms and protocols as a way to avoid hybrid overhead and continued reliance on traditional components known to be vulnerable to quantum adversaries. [C26]1

6. How to interpret dates and external guidance

Canada’s cited roadmap is dated June 23, 2025 and says the Government of Canada migration will take several years. It encourages early action and identifies planning phases, milestones, and governance, but the cited passages do not provide a single universal completion date for every department or system. Departments should therefore use the applicable departmental planning and reporting processes and monitor the policy instruments and updated Cyber Centre guidance identified in the roadmap. C1[C6]1

The UK NCSC guidance published March 20, 2025 gives indicative dates for UK industry, government, and regulators, including a 2028 discovery and goal-setting milestone. Its audience and jurisdiction are explicitly UK-oriented. ENISA, ETSI, and German guidance provide technical or strategic context, while NIST FIPS 203–205 provide U.S. federal standards. These materials can inform architecture and risk discussions, but none should be represented as a Canadian statutory deadline on the cited evidence. C4C1621

Conclusion

Canada’s PQC Roadmap is best understood as a current, federal Government of Canada planning framework: it covers nonclassified systems, assigns roles across the Cyber Centre, Treasury Board Secretariat, Shared Services Canada, and departmental governance, and calls for early, enterprise-wide discovery and migration planning. It does not, on the cited evidence, create a universal Canadian deadline. Organizations should separate applicable authority from recommendations, classify system scope, inventory cryptography and data lifetimes, prioritize hard-to-replace and high-consequence assets, test standardized implementations, and treat hybrid cryptography as a carefully engineered transition rather than a guarantee. C1C6[C18]123457