Short answer: federal departments and agencies in Canada must move their non-classified systems to post-quantum cryptography (PQC) on a fixed timetable. High-priority systems must be finished by the end of 2031 and everything else by the end of 2035. The dates come from the Canadian Centre for Cyber Security’s roadmap, ITSM.40.001. A Treasury Board notice from October 2025 made them required and added dates of its own: since 1 April 2026, new contracts with a digital component must carry post-quantum clauses, and by 1 April 2028 every department must record cryptographic details for its systems in TBS’s Application Portfolio Management tool or a comparable tool. The algorithm guidance, ITSP.40.111, was updated in May 2026 with 2035 phase-out dates. The protocol guidance, ITSP.40.062, still contains no post-quantum settings.
Much of the coverage of Canada’s plan stops at the June 2025 roadmap. This post reads all five documents that now make up the programme, from the Cyber Centre, the Treasury Board of Canada Secretariat (TBS) and the financial regulator OSFI, and sets out what each one requires, what it only recommends, and where they do not yet line up.
The five documents
| Document | Issuer | Current version | What it does |
|---|---|---|---|
| ITSM.40.001, Roadmap for the migration to post-quantum cryptography for the Government of Canada | Cyber Centre | First release, 23 June 2025 | Recommended phases, inventory fields and milestones |
| Migrating the Government of Canada to Post-Quantum Cryptography: Security Policy Implementation Notice (SPIN) | TBS | Effective 9 October 2025 | Turns the roadmap into dated requirements for departments and Shared Services Canada |
| ITSM.00.501, Recommended Contract Clauses for Cryptography | Cyber Centre | First release, September 2025 | Example procurement clauses, including post-quantum support by the end of 2026 |
| ITSP.40.111, Cryptographic algorithms for UNCLASSIFIED, PROTECTED A, and PROTECTED B information | Cyber Centre | Version 5, effective 29 May 2026 | Which algorithms and parameters to use, and when the quantum-vulnerable ones go |
| ITSP.40.062, Guidance on securely configuring network protocols | Cyber Centre | Version 3, January 2025 | TLS, IPsec, SSH and other protocol settings, with no post-quantum configurations yet |
A sixth document matters outside government. In March 2026 the Office of the Superintendent of Financial Institutions (OSFI) published a Technology Risk Bulletin on quantum readiness for federally regulated financial institutions. It is covered at the end of this post.
ITSM.40.001: the roadmap
The roadmap took effect on 23 June 2025 and has not been revised since. It covers non-classified systems, which in the Government of Canada means systems handling UNCLASSIFIED, PROTECTED A and PROTECTED B information. For classified systems and PROTECTED C, departments must contact the Cyber Centre. It sets four milestones:
- April 2026: develop an initial departmental PQC migration plan
- From April 2026, every year: report on progress
- End of 2031: complete the migration of high-priority systems
- End of 2035: complete the migration of remaining systems
“Complete” has a specific meaning. The roadmap says the milestones mean “quantum-vulnerable algorithms are disabled, isolated or tunnelled. That is, rather than just supporting PQC, the quantum risk has been mitigated.” A system that offers ML-KEM but still accepts RSA key exchange from older clients has not finished.
The work runs in three phases, which the roadmap says “will likely overlap”: Preparation, Identification and Transition. In Preparation, a department sets up a committee, names a PQC Migration Executive Lead (the roadmap recommends the Designated Official for Cyber Security or a delegated executive) and writes a plan that covers funding, staff education, procurement and how systems will be found. The plan “must have a cost estimate”, although the first version is not expected to be complete.
Identification is where the roadmap is most specific. It lists the places cryptography lives, from network services, operating systems, applications and code development pipelines to printers, voice over IP telephony, hardware security modules, smart cards and hardware tokens. It then lists 11 fields to record for each system, including the components that use cryptography, vendor and product version, current cryptographic configurations, system dependencies, service contracts and expiry dates, and the expected refresh year.
On method, the roadmap says discovery “should utilize multiple methodologies”, that “Software tools and services will be necessary to complete cryptographic discovery”, and that these may include existing SIEM, network monitoring and inspection, and endpoint detection and response, alongside independent tools that scan “networks, hosts, log files, or source code”. It also gives advice that applies to any inventory project: “It is important to not be overwhelmed in completing the discovery and to begin with an initial, incomplete inventory with actions to iteratively improve the data.”
For priorities, the roadmap points at harvest now, decrypt later (HNDL). Systems protecting the confidentiality of information in transit over public network zones “may be at risk earlier than expected”, and it recommends that any system susceptible to HNDL be a high priority. Information lifespan, support for cryptographic agility and the impact of compromise are the other factors it names.
The Treasury Board notice: what is actually required
The roadmap itself is guidance. It said TBS “will issue the necessary policy instruments”, and on 9 October 2025 TBS did, in a Security Policy Implementation Notice. Its stated purpose is “to reinforce requirements under the Policy on Government Security and the Policy on Service and Digital”. It applies to the organisations listed in section 6 of the Policy on Government Security and to “any GC information system (departmental or enterprise) that employs cryptography”, up to and including PROTECTED B.
The notice keeps the 2031 and 2035 end dates and fills in the years between:
| Date | Requirement |
|---|---|
| 1 April 2026 | Departments and Shared Services Canada (SSC) each develop a high-level PQC migration plan and begin annual progress reporting. SSC’s plan is shared with departments. |
| 1 April 2026 | All contracts with a digital component entered into after this date include procurement clauses supporting PQC compliant with ITSP.40.111, modules certified by the Cryptographic Module Validation Program (CMVP), and cryptographic agility. |
| 1 April 2027 | Plans updated to guide Phase 2, Identification. |
| 1 April 2028 | System records in TBS’s Application Portfolio Management (APM) tool, or a comparable tool, updated with cryptographic, vendor and migration details. High-priority systems identified. Departments engage SSC on upgrade or replacement plans. |
| 1 April 2028 | Plans updated to guide Phase 3, and departments and SSC begin transitioning systems. |
| End of 2031 | Migration of high-priority systems complete. |
| End of 2035 | Migration of remaining systems complete. |
The 2028 register requirement is the one with the most practical weight. Each system record must include, at a minimum, the system components that employ cryptography, their location (for example, external-facing or internal), “Current cryptographic algorithms and protocols employed”, hosting platform, system dependencies, vendor and product version for each component, relevant service contracts and expiry dates, expected refresh year, a responsible point of contact, priority for migration and migration status. That is a cryptographic inventory in all but name, kept in a set format that TBS can review.
The notice also names the high-priority systems more widely than the roadmap: those susceptible to an HNDL threat “or custom applications”. On compliance, TBS will monitor progress and engage senior officials, including the chief information officer, chief security officer, designated official for cyber security and designated official for procurement, when a department misses a deadline. The consequences are those in the Treasury Board’s Framework for the Management of Compliance.
ITSP.40.111 version 5: the 2035 phase-out dates
ITSP.40.111 is the Cyber Centre’s list of recommended algorithms for UNCLASSIFIED, PROTECTED A and PROTECTED B information. Version 4, from March 2025, added the three NIST post-quantum standards. Version 5 took effect on 29 May 2026, and its main change is “phase-out dates for the use of all quantum-vulnerable key establishment schemes and digital signature schemes”.
| Algorithm | By the end of 2030 | By the end of 2035 |
|---|---|---|
| RSA (key establishment and signatures) | Modulus of at least 3072 bits | Use without a post-quantum scheme phased out |
| Finite field Diffie-Hellman and MQV | Field size of at least 3072 bits | Use without a post-quantum scheme phased out |
| Elliptic curve Diffie-Hellman and MQV | P-224 and all binary curves phased out | Use without a post-quantum scheme phased out |
| ECDSA | P-224 and all binary curves phased out | Use without a post-quantum scheme phased out |
| EdDSA | No change | Use without a post-quantum scheme phased out |
| DSA | Phased out | Not applicable |
The 2035 wording is precise. For RSA key establishment, for example, it reads: “The use of RSA without a post-quantum key establishment scheme should be phased out by the end of 2035.” What goes is the classical algorithm used on its own. Classical algorithms used together with a post-quantum scheme are not phased out by this wording, which leaves room for hybrid schemes that pair the two. ITSP.40.111 does not itself use the word hybrid, and it does not name any hybrid construction.
The recommended post-quantum algorithms are broader than in some other national schemes:
- ML-KEM (FIPS 203) at all three parameter sets: ML-KEM-512, ML-KEM-768 and ML-KEM-1024
- ML-DSA (FIPS 204) at all three: ML-DSA-44, ML-DSA-65 and ML-DSA-87
- SLH-DSA (FIPS 205) at all 12 parameter sets
- LMS, XMSS and multi-tree XMSS (NIST SP 800-208), but only “when the signer is not required to rapidly produce signatures and is able to protect and manage private key state”
Compare the US national security rules covered in our CNSA 2.0 post, which allow only the ML-KEM-1024 and ML-DSA-87 parameter sets and do not approve SLH-DSA. A product negotiating ML-KEM-768 can meet ITSP.40.111 while falling short of CNSA 2.0. ITSP.40.111 also adds a condition on maturity: organisations “should only use post-quantum public-key encryption and signature schemes that comply with the final, published standards”.
ITSP.40.062: the gap in the protocol guidance
Algorithms on their own do not secure a connection. ITSP.40.062 is the document that tells departments how to configure TLS, IPsec with IKEv2, SSH, SNMP and S/MIME, and the current version, version 3, dates from January 2025. Its list of TLS supported groups that conform to ITSP.40.111 names secp256r1, secp384r1 and secp521r1 as recommended, with finite field groups from ffdhe3072 upwards as sufficient. No post-quantum or hybrid group appears.
Section 9 explains why. The Cyber Centre expects “to include recommendations for the configuration of post-quantum cryptography in an update to this publication once the protocol standards are finalized”, and in the meantime: “Organizations should wait until the standards for using post-quantum cryptography in protocols are finalized before revising configurations to protect information or systems.” Both the roadmap and ITSP.40.111 say ITSP.40.062 will be updated. As of 20 October 2026, the published page was last modified on 20 February 2025.
This leaves departments with an awkward sequence. Contracts entered into since April 2026 must include clauses supporting PQC, the example clauses ask for that support by the end of 2026, and departments must begin transitioning systems by April 2028, but there is not yet a Canadian configuration baseline that tells an administrator which post-quantum TLS group or IKEv2 exchange to enable. The inventory work does not have to wait for it. Knowing which systems speak which protocols, and on which libraries and appliances, is what lets a department act quickly once the protocol guidance arrives.
ITSM.00.501: the contract clauses
The roadmap mentioned recommended contract clauses that were “available upon request”. They were published in September 2025 as ITSM.00.501, and the Treasury Board notice links to them as the Cyber Centre’s recommendation that new contracts must align with. The example clauses for both products and service providers include:
- “By the end of 2026, cryptographic modules implementing key establishment schemes must support appropriate post-quantum cryptography compliant with” ITSP.40.111
- “By the end of 2026, cryptographic modules implementing digital signature schemes must support appropriate post-quantum cryptography compliant with” ITSP.40.111
The approach lets a department buy from a vendor that does not yet ship PQC, as long as the vendor commits to upgrade the modules by the date in the contract. Other example clauses require CMVP-validated modules, algorithms validated by the Cryptographic Algorithm Validation Program (CAVP), configurable algorithms and key lengths, and support for vendor-signed patches and updates.
Two details are easy to miss. First, for products, clauses that reference ITSP.40.111 “should specify the publication version”, while for service providers they “should not reference a specific version or publication date” so that the contractor keeps up with each new release. A cloud or managed service contract therefore follows ITSP.40.111 version 5 today and whatever comes next. Second, the clauses are examples. The Communications Security Establishment and the Cyber Centre “do not recommend or endorse the use of any particular contracting clause”, and they advise seeking legal and procurement advice.
Outside government: OSFI’s March 2026 bulletin
None of these documents binds private companies. Banks and insurers regulated by OSFI have their own signal: a Technology Risk Bulletin, “Quantum Readiness Phases and Timelines”, dated March 2026. It groups best practice into five phases, from building competency and awareness through inventory, risk assessment and transition to testing and validation, and suggests that institutions might “maintain a centralized inventory of cryptographic assets, including algorithms, protocols, keys, certificates, secrets, and relevant third-party dependencies”. On timing, it notes that published guidelines “generally recommend achieving quantum readiness across all systems by 2035”. The bulletin offers best practices rather than new rules.
What to do with this
For a federal department, the next fixed date is 1 April 2027, when the migration plan must be updated for the identification phase, and the one after that is the April 2028 register update. The register fields line up closely with what a cryptographic discovery exercise produces: algorithms and protocols in use, where each component sits, what it depends on and who supplies it. A department that starts discovery now has a year and a half to turn a first, incomplete inventory into records it can stand behind.
For a supplier to the Government of Canada, the questions to prepare for are the ones in ITSM.00.501: which modules implement key establishment and signatures, whether they will support ML-KEM and ML-DSA by the end of 2026, whether they are CMVP-validated, and whether algorithms and key lengths can be changed without replacing hardware. Being able to show a cryptographic bill of materials for the product answers most of these at once.
In the terms of the Enterprise Cryptographic Exposure Management (ECEM) lifecycle (Discover, Inventory, Assess, Prioritise, Transition, Monitor), Canada’s Preparation and Identification phases cover the first four stages, and the Treasury Board’s 2028 register asks for the output of Inventory and Prioritise in a fixed format. Monitoring is what keeps that register accurate between annual reports.
Frequently asked questions
What are the Government of Canada’s post-quantum deadlines?
Under the Treasury Board’s October 2025 notice, departments needed a high-level PQC migration plan and annual reporting from 1 April 2026, post-quantum clauses in new contracts with a digital component from the same date, an updated plan by 1 April 2027, and cryptographic details for their systems in the APM tool by 1 April 2028. High-priority systems must be migrated by the end of 2031 and all remaining systems by the end of 2035.
Is ITSM.40.001 mandatory?
ITSM.40.001 is the Cyber Centre’s recommended roadmap. The requirements come from the Treasury Board’s Security Policy Implementation Notice of 9 October 2025, which reinforces the Policy on Government Security and the Policy on Service and Digital and applies to the organisations listed in section 6 of the Policy on Government Security. It covers systems up to and including PROTECTED B.
Does ITSP.40.111 allow hybrid post-quantum key exchange?
ITSP.40.111 version 5 phases out RSA, Diffie-Hellman, elliptic curve and EdDSA use without a post-quantum scheme by the end of 2035. Using them together with a post-quantum scheme is not phased out by that wording. The document does not name specific hybrid constructions, and the Cyber Centre’s protocol guidance, ITSP.40.062, does not yet list any post-quantum or hybrid TLS groups.
Which ML-KEM parameter sets does Canada recommend?
ITSP.40.111 recommends all three FIPS 203 parameter sets, ML-KEM-512, ML-KEM-768 and ML-KEM-1024, for UNCLASSIFIED, PROTECTED A and PROTECTED B information. This is broader than the US CNSA 2.0 suite for national security systems, which requires ML-KEM-1024.
Sources: Canadian Centre for Cyber Security, Roadmap for the migration to post-quantum cryptography for the Government of Canada (ITSM.40.001) (June 2025); Treasury Board of Canada Secretariat, Migrating the Government of Canada to Post-Quantum Cryptography: Security Policy Implementation Notice (October 2025); Canadian Centre for Cyber Security, Recommended Contract Clauses for Cryptography (ITSM.00.501) (September 2025); Canadian Centre for Cyber Security, Cryptographic algorithms for UNCLASSIFIED, PROTECTED A, and PROTECTED B information (ITSP.40.111) (version 5, May 2026); Canadian Centre for Cyber Security, Guidance on securely configuring network protocols (ITSP.40.062) (January 2025); OSFI, Quantum Readiness Phases and Timelines (March 2026).
Further reading: CNSA 2.0 and the 1 January 2027 deadline, the NCSC’s 2028, 2031 and 2035 migration timeline and why post-quantum deadlines are really inventory deadlines.