The Post-Quantum Readiness Playbook for Canadian Healthcare

A practical migration framework for hospitals, provincial health authorities, and Caribbean health ministries. Sections 1–3 are written for executive teams and board risk committees; Sections 4–7 are working instruments — a cryptographic inventory methodology, a phased migration framework, an architectural position on sovereignty, and a 90-day plan that can be started the week this document is read. Version 1.0, August 2026.

1. Executive summary

Every hospital in Canada currently protects personal health information with mathematics that has a known expiry date.

The encryption securing your provincial network connections, your clinician remote access, your medical device telemetry, your backup archives, and your inter-facility referrals depends on two hard problems: factoring large integers and computing discrete logarithms over elliptic curves. A sufficiently capable quantum computer solves both efficiently using Shor’s algorithm. When that machine exists, RSA, Diffie–Hellman, ECDH, and ECDSA do not weaken. They fail completely.

This is not a novel observation, and it is not the reason this playbook exists. The reason is that the timeline moved in 2026, and Canadian healthcare has not adjusted to it.

In August 2024, the U.S. National Institute of Standards and Technology finalized the first three post-quantum cryptographic standards — ML-KEM (FIPS 203), ML-DSA (FIPS 204), and SLH-DSA (FIPS 205) — and NIST’s project lead, Dustin Moody, told administrators to “start integrating them into their systems immediately, because full integration will take time” [1]. NIST’s transition guidance set 2030 for the deprecation of 112-bit-strength public-key cryptography and 2035 for its disallowance [2]. Canada’s Cyber Centre published a matching roadmap in June 2025: federal high-priority systems migrated by the end of 2031, remaining systems by the end of 2035 [4].

Then, in the space of six weeks in the spring of 2026, three things happened.

On 25 March 2026, Google announced a 2029 deadlinefor its own post-quantum migration, explicitly stating that it “isn’t taking current transition guidelines for granted,” and — critically — that it had re-prioritized post-quantum migration for authentication services, not just encryption [10]. On 30 and 31 March, two independent research results collapsed the estimated cost of a cryptographically relevant quantum computer. Google researchers reported compiled Shor circuits capable of solving the 256-bit elliptic curve discrete logarithm problem — the mathematics behind the P-256 curve in near-universal use — on “fewer than 500,000 physical qubits in a few minutes,” an approximately twentyfold reduction, and disclosed the result via zero-knowledge proof rather than publishing the circuits [13]. This followed Craig Gidney’s May 2025 finding that RSA-2048 could be factored with fewer than one million noisy qubits, itself a twentyfold reduction on prior estimates [12]. Separately, a Harvard–Caltech–AWS group showed Shor’s algorithm executable “at cryptographically relevant scales with as few as 10,000 reconfigurable atomic qubits” [14]. On 7 April, Cloudflare — which already carries post-quantum encryption for more than 65% of the human traffic it serves — moved its own target to 2029, and wrote plainly: “Q-Day has been pulled forward significantly from typical 2035+ timelines” [11].

Why healthcare is structurally worse off than banking

Canadian financial institutions received a direct instruction. The Office of the Superintendent of Financial Institutions issued a Technology Risk Bulletin on quantum readiness in 2024, followed by a five-phase framework in March 2026 that opens by describing cryptographically relevant quantum computers as “a credible threat to the encryption that protects financial records, customer data, and critical assets” [8]. OSFI’s Guideline B-13 already obliges federally regulated institutions to “implement and maintain strong cryptographic technologies,” and Guideline B-10 pushes that obligation through the vendor supply chain [32].

Healthcare received nothing comparable. There is no PHIPA regulation, no Ontario Health directive, and no federal health portfolio guidance that names post-quantum cryptography as an obligation for hospitals. Ontario’s flagship public-sector cyber security statute — the Enhancing Digital Security and Trust Act, 2024, enacted by Bill 194 — gives the Minister power to set binding technical cyber security standards, but defines “public sector entity” as institutions under FIPPA and MFIPPA, children’s aid societies, and school boards [24]. Ontario hospitals are not captured. The province took the power to mandate cyber security standards for school boards and did not take it for the organizations holding the most sensitive records in the province.

Meanwhile the underlying exposure is worse in healthcare than in finance for four reasons that no regulatory silence changes:

The argument that should change your risk register

The most important fact in this playbook is not about quantum computers. It is about Ontario administrative law.

In June 2025, Ontario’s Information and Privacy Commissioner released PHIPA Decision 284, arising from the October 2023 ransomware attack on TransForm Shared Service Organization and the five hospitals it served [9]. Counsel for the hospitals argued that ransomware encryption of 192 virtual servers — where the attacker’s script encrypted container-level virtual infrastructure without any human viewing the contents, and where the data was fully restored from backups — was not a “use” or “loss” of personal health information and therefore triggered no duty to notify.

The investigator accepted the factual premise and rejected the legal conclusion. At paragraph 89: “I also accept the custodians’ evidence in this case that the threat actor did not view or access the personal health information in the servers that have been encrypted.” At paragraph 91: “I find that in this case, the threat actor’s encryption amounted to unauthorized use of personal health information... The encryption of the containers and servers had the effect of transforming the personal health information contained therein, such that it was unavailable and inaccessible to authorized users.”

Read that holding against the harvest-now-decrypt-later threat. Ontario’s regulator has now held, three times across PHIPA Decisions 253, 254, and 284, that liability under section 12(2) does not require an adversary to have comprehended the data. It requires an unauthorized act performed over personal health information and a resulting loss of the custodian’s authorized control. “They have not read it yet” is not a defence that Ontario’s privacy regulator has accepted.The adversary copying your ciphertext today is in the same doctrinal posture as the adversary who encrypted TransForm’s servers: an unauthorized cryptographic act over PHI that the custodian is statutorily obliged to protect for decades.

This converts quantum risk from a technology forecast into a present-tense compliance question under PHIPA section 12(1): whether continuing to protect fifty-year-lifetime health data with algorithms that Canada’s own Cyber Centre has scheduled for phase-out remains a step “that is reasonable in the circumstances.”

What this playbook asks you to do

1. Reject the 2035 mental model. Plan to 2029 for authentication and long-lived confidentiality; treat 2035 as the compliance backstop.
2. Build a Cryptographic Bill of Materials before you buy anything. You cannot migrate cryptography you cannot enumerate. Section 4 provides the methodology and template.
3. Put the Cyber Centre’s contract clauses into every procurement now. ITSM.00.501 requires vendors to support post-quantum key establishment and digital signatures by the end of 2026— a deadline more aggressive than the federal government’s own internal milestones, and one you can adopt today without waiting for a regulator [7].
4. Prioritize authentication alongside encryption.Long-lived trust anchors — root certificates, code-signing keys, VPN and remote-access credentials, device firmware verification keys — are the assets where a quantum-capable adversary walks in the front door rather than reading yesterday’s traffic.
5. Treat sovereignty as a cryptographic control, not a marketing position. Where keys live, and under whose jurisdiction, determines who can compel their production.

If your organization has done nothing on this file, the Cyber Centre’s two-page ITSAP.00.017 is the briefing document to circulate first [30]; Section 7 of this playbook is what to do the week after.

2. The threat landscape

2.1 What actually breaks

Modern healthcare systems use two categories of cryptography, and they face fundamentally different quantum futures.

Asymmetric (public-key) cryptography— RSA, Diffie–Hellman, elliptic curve Diffie–Hellman, ECDSA, EdDSA — is used to establish session keys and to prove identity. Its security rests on problems that Shor’s algorithm solves in polynomial time on a quantum computer. This category does not degrade gracefully. It breaks.

Symmetric cryptography and hash functions— AES, SHA-2, SHA-3 — face only Grover’s algorithm, which provides a quadratic speed-up against brute-force search. The practical consequence is a halving of effective key strength, which is why NIST states that “all NIST-approved symmetric primitives that provide at least 128 bits of classical security are believed to meet the requirements of at least Category 1 security” [2], and why the Cyber Centre continues to recommend AES-128, AES-192, and AES-256 [6].

2.2 “Harvest Now, Decrypt Later” in a healthcare context

Harvest now, decrypt later requires no quantum computer today. It requires only storage and patience: an adversary intercepts and retains encrypted traffic or exfiltrates encrypted archives now, and decrypts when capability arrives. NIST states the problem directly, and names healthcare when doing so — the threat “underscores the necessity of acting immediately, especially for data with long-term sensitivity, such as government secrets or medical records” [2].

Google’s security leadership was blunter in February 2026: “malicious actors are not waiting until a Cryptographically Relevant Quantum Computer is ready. They are likely already carrying out ‘store now, decrypt later’ attacks and collecting encrypted data, just waiting for the day when a quantum computer can unlock it” [31].

The standard tool for reasoning about this is Mosca’s inequality. Let X be the number of years your data must remain confidential, Y the number of years your migration will take, and Z the number of years until a cryptographically relevant quantum computer exists. If X + Y > Z, you are already exposed [2]. Recent healthcare-specific work adds a term worth separating out: T_discovery, the time required to locate legacy cryptographic primitives across a health network, which for a hospital is rarely less than several months and is frequently the binding constraint [15].

Run the arithmetic honestly for a Canadian hospital:

For any hospital holding paediatric or genomic data, X + Y exceeds Z by a margin that no reasonable adjustment of assumptions closes. The inequality is already violated. This is not a reason for fatalism; it is the reason the sequencing in Section 5 prioritizes long-lived confidentiality and long-lived trust anchors over uniform coverage.

2.3 The 2026 inversion: authentication became the urgent problem

Until 2026, the standard prioritization was straightforward. Encryption first, because harvest-now-decrypt-later creates retroactive exposure; signatures later, because authentication “remains secure as long as the cryptographic algorithms and keys used to perform the authentication are secure when the authentication is performed” [2]. A forged certificate is only useful when the forgery is possible, so a distant Q-Day makes signature migration deferrable.

An imminent Q-Day inverts this. Cloudflare’s formulation deserves to be read by every hospital CISO in the country:

Google reached the same conclusion independently and acted on it: “we’ve adjusted our threat model to prioritize PQC migration for authentication services... We recommend that other engineering teams follow suit” [10]. This risk has been usefully named “Trust Now, Forge Later”— the authentication counterpart to harvest now, decrypt later, under which every certificate signed with classical cryptography during the transition period accumulates forgeability exposure [28].

For healthcare, the authentication-first threat model lands on a specific and uncomfortable list:

• Clinician and vendor remote access.PHIPA Decision 284 records that the segmented portion of the TSSO network supporting Bluewater Health’s on-premises EMR “allowed BWH’s third-party vendor to access the network directly to provide related services including maintenance,” and that network segments were “interconnected and accessed via secure virtual private networks (VPNs)” [9]. VPN key establishment and authentication is precisely what ML-KEM and ML-DSA replace. The attack’s root cause was compromised administrator credentials whose method of compromise forensics could not determine— and where provenance is unknown, interception cannot be excluded.
• Medical device firmware verification. A device that will accept a firmware image signed with RSA-2048 in 2032 will also accept a forgedfirmware image signed with a broken RSA-2048 key in 2032, and it has no way to tell the difference. NIST notes that where signature-verification code cannot be updated post-manufacture, “it is important for the devices to be designed to require quantum-resistant signatures on the executables” [2].
• Automated software update channelsacross the clinical estate — the highest-leverage remote code execution path in any hospital.
• Provincial PKI and federation trust anchors. Root and intermediate certificate authorities, SAML and OIDC signing keys underpinning single sign-on across a health region.
• Code-signing and integrity keys for locally developed integration engines and HL7 interfaces.

2.4 The threat actor, specified

Vague threat modelling produces vague budgets. The healthcare-specific literature offers a concrete adversary profile worth adopting into your risk register: a state-sponsored actor, organized criminal group, or well-resourced insider-capable adversary “able to conduct passive network interception across WAN links, cloud interconnects, partner networks, and vendor-managed device infrastructure,” which in the near term has no quantum computer but for which “large-scale storage and traffic collection are feasible,” and which in the long term “obtains or rentsaccess to a fault-tolerant quantum computer” [15].

That last phrase carries the weight. Quantum computing is being commercialized as a cloud service. Your adversary does not need to build the machine. They need a credit card and the ciphertext they collected years earlier.

Primary confidentiality targets in a health system are encrypted clinical archives, genomic repositories, research data-sharing transfers, telemedicine sessions, and identity-provider traffic. Primary integrity targets are signatures used for software updates, medical-device firmware validation, certificate chains, audit records, and clinician identity assertions [15].

2.5 The scale precedent Canadian healthcare already has

Nothing in this section is hypothetical for Canadian hospitals. The TransForm incident provides calibrated, regulator-verified figures for what a cryptographic failure costs a Canadian health system [9][29]:

• 516,000+ peoplehad personal health information exfiltrated, including names, addresses, dates of birth, social insurance numbers, diagnoses, treatment information, and health card numbers — subsequently published on the dark web.
• 192 virtual servers encrypted, exceeding 800 terabytes, including application servers supporting clinical care and diagnostic testing such as point-of-care testing. Bluewater Health temporarily lost access to its own EMR.
• Approximately 150 GB exfiltrated via three compromised administrator accounts. Multi-factor authentication was not in place at the time; the IPC investigator found its absence “likely a contributing factor.”
• Upwards of $7.5 million in cost. Networks rebuilt from scratch. Cancer treatments and surgeries cancelled.
• Bluewater Health held approximately 20,000 social insurance numbers it was not authorized to collect, including from patients seen between 1999 and 2006, which the investigator found “contributed to the severity of the privacy breach.”

That final point deserves emphasis because it is the cheapest control in this playbook: data minimization is a post-quantum control. Data you never collected cannot be harvested. Records you have lawfully disposed of cannot be decrypted in 2033. Before spending a dollar on cryptographic migration, retire the data you should not be holding.

3. Regulatory context

3.1 The standards themselves

NIST finalized three post-quantum standards on 13 August 2024, following a process begun in 2015 that evaluated 82 candidate algorithms from 25 countries [1]. Canada’s Cyber Centre recommends all three in ITSP.40.111, version 5, effective 29 May 2026 [6].

Two constraints from the Cyber Centre matter for procurement conversations. First: “Organizations should only use post-quantum public-key encryption and signature schemes that comply with the final, published standards... to protect information or systems” [6]— which disqualifies vendors shipping pre-standardization Kyber variants or proprietary “quantum-safe” schemes. Second, on the choice between signature schemes: “SLH-DSA does not require state management but has inferior performance and larger signatures than ML-DSA and the stateful hash-based signature schemes” [6].

One further datapoint is useful when a vendor claims that post-quantum requirements are premature. The U.S. National Security Agency’s Commercial National Security Algorithm Suite 2.0 requires ML-KEM-1024 and ML-DSA-87 for national security systems, with exclusive use of CNSA 2.0 algorithms mandated by 2033 and earlier deadlines for software and firmware signing [40]. The most conservative cryptographic buyer in the world has already set its dates.

3.2 Canada’s phase-out dates — and the hybrid permission inside them

ITSP.40.111 v5 introduced explicit phase-out dates. The precise wording is more permissive, and more useful to a hospital, than the headline suggests [6]:

The countervailing discipline comes from the Cyber Centre’s migration roadmap, which defines completion strictly: quantum-vulnerable algorithms must be “disabled, isolated or tunnelled,” not merely supplemented [4][27]. Cloudflare makes the same point operationally: “Adding support for PQ cryptography is not enough. Systems must disable support for quantum-vulnerable cryptography” [11]. A server that negotiates ML-KEM with modern clients and silently falls back to ECDH for everything else has not migrated; it has added an option. Downgrade paths are the most common way a migration project reports success without delivering it.

3.3 What binds the federal government — and why hospitals should read it anyway

Treasury Board’s Security Policy Implementation Notice on post-quantum migration took effect 9 October 2025 and applies to any Government of Canada information system employing cryptography, including “network services, operating systems, applications, code development pipelines and all physical information technology assets” [5]. Its schedule:

Canadian hospitals are provincially regulated and are not in Schedules IV and V of the Financial Administration Act, so this notice does not bind them. It matters for three reasons nonetheless.

First, the April 2028 data schema is a government-mandated CBOM. Departments must record, for each system: components employing cryptography; their location (external-facing or internal); current algorithms and protocols; hosting platform; system dependencies; vendor and product version per component; service contracts and expiry dates; expected refresh year; responsible point of contact; migration priority; and migration status [5]. That list is a ready-made schema for a hospital cryptographic inventory, and Section 4 of this playbook adopts it.

Second, the procurement clause deadline is already in force. Any health-sector vendor that also sells to the federal government is, as of April 2026, being asked for PQC support and cryptographic agility in federal contracts. Hospitals asking the same questions are not asking for something exotic.

Third, and most usefully, ITSM.00.501 (1 September 2025) contains the exact language and — critically — a more aggressive deadline than the government’s own migration milestones [7]:

The Cyber Centre’s rationale answers the single most common objection a hospital will hear from its EMR or PACS vendor — we do not support that yet:

You contract for the date, not for the vendor’s current state. This is the most immediately actionable item in this playbook, it requires no capital, and it can be implemented by amending your standard procurement templates this quarter.

3.4 What binds Canadian hospitals: PHIPA, PIPEDA, and the elastic standard

Canadian health privacy law contains no algorithm list. It contains a standard of reasonableness that algorithm lists progressively define.

PHIPA section 12(1) requires a health information custodian to “take steps that are reasonable in the circumstances to ensure that personal health information in the custodian’s custody or control is protected against theft, loss and unauthorized use or disclosure” [38]. PIPEDA’s Principle 4.7 requires safeguards “appropriate to the sensitivity of the information,” a technology-neutral standard that has always tracked the evolving state of practice [39].

Ontario Health’s own Electronic Health Record Retention Policy, updated April 2026, obliges retention “in accordance with the Personal Health Information Handling Standard and industry security standards and best practices,” and requires agents to take steps “reasonable in the circumstances” to protect retained records against theft, loss, and unauthorized use or disclosure [22].

Each of these is an elastic clause. The mechanism by which post-quantum cryptography becomes legally required in Canadian healthcare will almost certainly not be a PQC regulation. It will be the ordinary operation of a reasonableness standard against a changed state of practice:

1. NIST standardized the algorithms in August 2024 [1].
2. The Cyber Centre recommended them and published phase-out dates for their predecessors [6].
3. The Cyber Centre published model contract clauses requiring vendor support by end of 2026 [7].
4. Mainstream products shipped support; more than 65% of human web traffic to Cloudflare is already post-quantum encrypted [11].
5. At that point, continuing to protect a fifty-year-lifetime paediatric record with an algorithm your national cryptographic authority has scheduled for phase-out is difficult to characterize as reasonable.

The compliance exposure is not a future fine. It is the retroactive assessment of a decision you are making now, conducted after an incident, by a regulator applying a standard that will have moved. PHIPA Decision 284 demonstrates the pattern precisely: the attack occurred in October 2023, the finding of a notification failure was issued in June 2025, and the custodians’ argument that their own precedent-contrary reading was correct did not survive [9].

3.5 Why the regulators have not acted — and why the gap is the risk

Four structural facts explain the silence, and each one is itself a finding.

The federal cyber security statute is still not in force. The Critical Cyber Systems Protection Act, originally Part 2 of Bill C-26, died on the Order Paper in January 2025 and was reintroduced as Bill C-8 in June 2025, passing Senate third reading on 4 June 2026. Penalties reach $15 million per violation per day. But in four years of legislative process, quantum computing was raised once — by Senator Mohamed-Iqbal Ravalia — and the sponsor’s answer was that “there was no direct discussion at the committee level,” the bill being “generic at this stage — so the regulatory process can deal with issues around quantum computing and artificial intelligence.” Regulation lead times of 12 to 24 months for Part 2 place enforceable obligations in late 2027 to mid-2028 at the earliest, and PQC-specific obligations realistically in 2028–2029 [28].

Ontario’s public-sector cyber security statute excludes hospitals. As set out above, the Enhancing Digital Security and Trust Act, 2024defines “public sector entity” to exclude health information custodians [24].

Health Canada’s medical device cybersecurity guidance predates the standards by five years. The Pre-market Requirements for Medical Device Cybersecurityguidance was adopted 17 June 2019 and took effect 26 June 2019. It contains no reference to post-quantum cryptography and no cryptographic agility requirement. Its bill-of-materials definition covers “commercial, open source, and off-the-shelf software and hardware components” — an SBOM-style definition that does not extend to cryptographic assets [18]. Two hooks remain available: the guidance states that “Health Canada considers cybersecurity a component of the medical device’s design and lifecycle,” and that “risk management is required for all medical devices throughout their lifecycle.” A device whose cryptography expires mid-lifecycle is arguably a lifecycle risk-management failure even under the 2019 text.

Even the federal government is behind its own schedule.Shared Services Canada’s 2025–26 Departmental Plan said it “will create a comprehensive quantum readiness action plan” — future tense, roughly three months before the April 2026 deadline. The 2026–27 plan, published in April 2026, states that “in 2026-2027... SSC will identify and prioritize changes that will be required to implement enhanced security measures and mitigate this future risk” — still future tense, still Phase 1 language. No public compliance statistics exist for how many departments met the April 2026 planning deadline [28].

Why this is dangerous rather than reassuring.Regulatory vacuums in Canadian healthcare do not persist; they close abruptly. The pattern is consistent — an incident, an IPC investigation, a set of recommendations, and then a compressed compliance timeline imposed on organizations that had no time to plan. The Cyber Centre has already articulated the cost consequence: migration costs “may be reduced by utilizing existing IT equipment lifecycles and system modernization plans. To do so, it is critical to perform the initial phases of this plan quickly to identify where these cost efficiencies can be leveraged. Delays resulting in rushed procurement will increase costs” [4].

Organizations that begin now fund migration from ordinary refresh budgets. Organizations that wait for a provincial mandate will be told what to do in approximately 2029 to 2031, given eighteen months to do it, and will pay a premium for every device, licence, and consultant in a market where every other health organization in the country is buying simultaneously.

3.6 What the banks are doing that hospitals are not

OSFI’s March 2026 Technology Risk Bulletin organizes quantum readiness into five phases, and the framework transposes to healthcare almost without modification [8]:

OSFI’s fifth phase contains the most under-appreciated recommendation in the entire Canadian regulatory corpus: rehearse for early arrival. Every hospital in Canada now runs ransomware tabletop exercises. Almost none have run the exercise that begins: credible reports indicate ECDSA P-256 has been broken; your certificate authority, your VPN concentrator, and your vendor remote access are all affected; you have 72 hours.

There is one further asymmetry worth noting. NIST’s National Cybersecurity Center of Excellence migration project has assembled a consortium of more than sixty organizations, including at least five major banks — JPMorgan Chase, Wells Fargo, HSBC, Santander, M&T Bank — plus SWIFT. It includes exactly one healthcare organization, CVS Health [17]. Healthcare is materially under-represented in the standards conversation that will determine its own migration path.

On a more encouraging note for sovereignty-minded buyers, that same consortium includes four Canadian cryptographic firms — ISARA in Waterloo, InfoSec Global in Toronto, and Crypto4A and Entrust in Ottawa. Canada has genuine domestic post-quantum capability. A sovereign migration does not require importing every component.

3.7 The Ontario lever that already exists

Ontario does not need new legislation to require post-quantum cryptography in healthcare. It needs to use an authority it created in 2021.

The Digital Health Information Exchange (DHIEX)framework, established by sections 26 to 34 of O. Reg. 329/04 under PHIPA and in force since 1 January 2021, is described by Ontario Health as “the regulatory framework that gives Ontario Health the ability to define and implement the health information standards and requirements for use in interoperability specifications,” and it “provides the ability to monitor and address compliance with the standards” [19][20]. Ontario Health’s stated role includes “actively working with vendors and health information custodians through a program to monitor and ensure compliance.”

The scope is expanding. Effective 1 January 2025, O. Reg. 329/04 was amended to require accredited community pharmacies and Integrated Community Health Service Centres to contribute specified personal health information to the provincial EHR in compliance with Ontario Health’s interoperability specifications [19]. The population of organizations legally compelled to connect to the provincial EHR — and therefore the provincial cryptographic attack surface — is growing by regulation.

There is a closing window attached to this recommendation. On 19 March 2026, Ontario announced the creation of a province-wide primary care medical record system under its Primary Care Action Plan — a system being designed now that will be in service well beyond 2035. If post-quantum readiness is not specified at procurement, Ontario will have constructed a quantum-vulnerable provincial asset in 2026–2028 and will pay to retrofit it in the 2030s. The same logic applies to every provincial EHR modernization currently in flight and to every Caribbean national EHR and biobank in design.

4. The Cryptographic Bill of Materials for hospitals

4.1 The premise

You cannot transition to quantum-safe algorithms if you do not know what algorithms you are using today. This sounds trivial. In practice it is the reason most migration programmes fail, and it is where a hospital’s first six to twelve months of effort belong.

A Cryptographic Bill of Materials (CBOM)is an inventory of cryptographic assets and their dependencies. The authoritative standard is the CycloneDX CBOM, which originated as IBM’s CBOM project and was upstreamed into the CycloneDX 1.6 specification in April 2024; CycloneDX itself is now an international standard, ECMA-424 [16]. CycloneDX defines a crypto-asset component type with cryptography-specific fields, enabling “detailed representation of cryptographic assets within a system... including algorithms, keys, certificates, and their relationships to software components” [16]. A CBOM may be embedded within an SBOM or linked to one via BOM-Link. It augments an SBOM rather than replacing it.

A well-built CBOM answers questions a hospital cannot currently answer: Are any 1024-bit RSA keys still in use? Where do we rely on SHA-1 or 3DES? Which certificates and keys are nearing expiry? Which of our systems will still be running in 2035 on cryptography scheduled for phase-out in 2030? [16]

The immediate return is not limited to quantum. A CBOM is the artifact that lets you answer, within hours rather than weeks, “are we affected?” the next time a cryptographic library vulnerability is disclosed. The quantum transition is the reason to build it; incident response is why you will keep it.

4.2 Discovery: four methods, none of them sufficient alone

NIST’s NCCoE migration project frames cryptographic discovery as one of two core workstreams, aimed at helping organizations “learn where and how cryptography is being used to protect the confidentiality and integrity of your organization’s important data and digital systems” [17]. No single technique achieves coverage in a hospital environment. Four are required, and their blind spots are as important as their capabilities.

4.3 The hospital CBOM schema

The schema below adopts the field structure that Treasury Board requires of federal departments by April 2028 [5], extended with health-sector fields: data classification, retention obligation, and clinical criticality. Adopting the federal schema is deliberate — it aligns your inventory with the direction Canadian public-sector practice is travelling, and it produces a document your auditors and any future provincial programme will recognize.

Section A — System and cryptographic detail

Section B — Data and clinical context (healthcare extension)

Section C — Vendor, lifecycle, and migration

4.4 Risk stratification: how to prioritize

Uniform migration is not achievable and not desirable. Stratify by a two-axis test: confidentiality lifetime (does harvest-now-decrypt-later apply?) and trust-anchor longevity (does trust-now-forge-later apply?).

P4 deserves particular attention because it is where hospitals differ most sharply from banks. Medical devices carry 10–15 year field lifespans, rely on cryptography for secure boot, remote monitoring, updates, and data protection, and frequently run ultra-low-power hardware that limits any ability to retrofit compute-heavy cryptography later [26]. The Cyber Centre’s own guidance on connected medical devices already treats this class of asset as a distinct security problem for Canadian health organizations [34]. The blunt formulation from the device security literature is worth quoting to your biomedical engineering colleagues: “If static algorithms like RSA or ECC are hardcoded today, your device could be functionally secure now — but obsolete later” [26].

For P4 assets, the practical control is architectural rather than cryptographic: place the quantum-vulnerable device inside a segment whose boundary is protected by post-quantum key establishment, so the device’s classical cryptography never traverses a network an adversary can intercept. This is the healthcare-appropriate reading of the Cyber Centre’s requirement that quantum-vulnerable algorithms be “disabled, isolated or tunnelled” [4].

4.5 Mapping dependencies you do not control

Three dependency classes will not appear in any internal scan, and each requires an explicit workstream.

Vendor systems.Your EMR, PACS, laboratory information system, pharmacy system, and clinical engineering platforms each contain cryptography you cannot inventory directly. Appendix C provides the questionnaire. Note that a CBOM is not yet a regulatory requirement for medical device manufacturers in Canada or the United States — CBOMs “are not explicitly required by the FDA, but they are becoming a best practice” [26]. The obligation must therefore be created contractually, which is precisely what ITSM.00.501’s clauses accomplish [7].

Cloud and hosted services.For every hosted service handling PHI, record the cryptographic posture of the transport, the storage encryption, and — most importantly — the key custody model. Section 6 addresses why this matters beyond algorithm selection.

Provincial health networks. Your connections to provincial infrastructure are cryptographically dependent on decisions made by the provincial authority, not by you. Inventory each interface, record the negotiated protocol and cipher suite, and open a formal enquiry with the provincial authority regarding its post-quantum roadmap. If the answer is that no roadmap exists, that answer belongs in your risk register with a named accountable executive, because the exposure is yours regardless of whose infrastructure creates it.

5. The PQC migration framework

The framework below follows the three execution phases of the Cyber Centre’s federal roadmap — Preparation, Identification, Transition — expanded to four phases to separate validation, and calibrated to a 2029 operational deadline rather than the federal 2031/2035 milestones [4]. The phases are expected to overlap; treat the month ranges as sequencing guidance, not gates.

Phase 1 — Discovery and assessment (months 1–6)

Governance first.The Cyber Centre’s guidance on the Preparation phase is directly reusable by a hospital: establish a committee with a dedicated migration lead; include at least one senior management member for executive buy-in; and include non-technical stakeholders from finance, project management, procurement, and asset management [4]. That last instruction is the one most often skipped and most consequential — post-quantum migration is executed through procurement and capital planning far more than through engineering.

Assign two named roles:

• PQC Migration Executive Lead— accountable for quantum risk, financial planning, and board reporting. In a hospital this should sit with the CISO or, where the role exists, the executive accountable for privacy and security jointly. The federal analogue is the Designated Official for Cyber Security [4].
• PQC Migration Technical Lead— responsible for cross-organizational coordination, the CBOM, and vendor engagement.

Your migration plan must name individuals responsible for execution, financial planning, education strategy, procurement policy for new equipment, and the approach to identifying vulnerable systems [4].

Phase 2 — Hybrid implementation (months 6–18)

Hybrid key establishment combines a classical algorithm with a post-quantum one so that the result “remains secure if at least one of the component algorithms is secure” [2]. It is the correct default for healthcare for three reasons: it hedges against implementation flaws in new algorithms; it preserves interoperability with partners who have not migrated; and Canada’s phase-out language explicitly contemplates it, disallowing classical algorithms only when used without a post-quantum companion [6].

NIST is equally clear about the cost: hybrid solutions “add complexity to implementations and architectures, which can increase security risks and costs during the transition,” and are “typically expected to be temporary measures that lead to a second transition to cryptographic tools that use only PQC algorithms” [2]. Plan the second transition when you plan the first. Every hybrid deployment should carry a documented date for disabling its classical component.

Sequenced work, in priority order

1. Internet-facing and partner-facing TLS termination. Deploy X25519+ML-KEM hybrid key exchange at load balancers, reverse proxies, and API gateways. This is the highest-coverage, lowest-risk change available: it protects the largest volume of PHI in transit and is broadly supported in current mainstream products.
2. Site-to-site and remote-access VPN. Migrate IKEv2 key establishment to ML-KEM-based groups. Prioritize any tunnel carrying vendor remote access, given that vendor direct network access and VPN interconnection were structural features of the TransForm compromise [9].
3. Privileged and administrative access. SSH and jump-host key exchange to hybrid; begin re-issuing administrative credentials with post-quantum signatures where supported. Treat every long-lived administrative key as a P1 trust anchor.
4. PKI planning and pilot.Do not re-root your certificate authority hierarchy casually. Model the change, pilot ML-DSA certificate issuance in a non-clinical zone, and validate that every consuming system — including appliances and devices — can parse the larger certificate sizes. Certificate and signature size growth is the most common source of hybrid failure in practice.
5. Backup and archive key hierarchy. Your AES-256 archive encryption is quantum-resistant; the key-wrapping, key-escrow, and key-transport mechanisms around it usually are not. Migrating the wrapping layer protects decades of stored PHI in a single change.
6. Crypto-agility remediation.For each system where the CBOM records agility as absent or partial, either open a vendor commitment or schedule replacement. NIST’s guidance on achieving crypto agility (CSWP 39) is the reference [25].

Healthcare-specific interfaces

Phase 3 — Full PQC transition (months 18–36)

Phase 3 is where migrations are actually completed, and where most programmes stall. The defining task is removing the classical fallback, because supporting post-quantum cryptography and having migrated are not the same condition. The Cyber Centre requires that quantum-vulnerable algorithms be “disabled, isolated or tunnelled” [4]. Cloudflare’s warning about downgrade attacks applies directly: a system offering both will negotiate the weaker option whenever an adversary can influence the negotiation [11].

Phase 4 — Validation and continuous monitoring (ongoing from month 12)

Validation is not a closing phase; it runs concurrently from the first hybrid deployment.

• Functional and performance validation. Post-quantum algorithms impose larger keys, larger signatures, and different performance characteristics. Testing must verify device performance, compatibility with third-party components, and usability under cryptographic load [26]. In clinical settings, validate against latency-sensitive workflows explicitly — image retrieval, point-of-care testing, and medication administration.
• Negotiation monitoring. Instrument your gateways to report which key exchange was actually negotiated, per connection, and alert on classical fallback. This is the only reliable evidence that migration has occurred rather than been enabled.
• CBOM as a living artifact. Re-baseline quarterly. Integrate CBOM generation into your build pipelines for in-house software and require updated CBOMs from vendors at each major release.
• Standards watch. FIPS 206 (FN-DSA) remains in development [15]; HQC standardization is expected in 2027 [3]; protocol guidance including ITSP.40.062 will be updated as post-quantum protocol standards land [6]. Assign a named owner for standards monitoring.
• Q-Day rehearsal.Adopt OSFI’s fifth-phase recommendation: “plan and rehearse responses if CRQC arrives sooner than expected, including disaster recovery and incident response” [8]. Run the tabletop annually. The scenario is not academic — an IBM Quantum Safe executive has stated he “can’t rule out quantum ‘moonshot attacks’ on high value targets as early as 2029” [11].

6. The sovereign approach

6.1 Migration is a key-custody decision, not only an algorithm decision

Most published migration guidance treats post-quantum readiness as an algorithm substitution problem: replace ECDH with ML-KEM, replace ECDSA with ML-DSA, verify interoperability, done. That framing is incomplete, because the migration necessarily touches the one thing that determines who can access patient data regardless of algorithm strength: where the keys live, and whose law reaches them.

Every post-quantum migration involves generating new key material for essentially every trust relationship in the organization. This is the largest re-keying event most health systems will ever undertake. It is therefore also the best opportunity in a generation to correct key-custody arrangements that were never deliberately chosen — and the worst possible moment to entrench new ones by default.

6.2 Why a cloud-mediated migration introduces new risk

Three specific risks arise when post-quantum migration is delivered primarily through hyperscale cloud services.

Jurisdictional exposure to the keys themselves. A cryptographically perfect ML-KEM implementation provides no protection against a lawful production order served on the entity holding the keys. Where key management is operated by a provider subject to foreign jurisdiction, the migration has strengthened the algorithm while leaving the access path through the legal system untouched. For a Canadian health information custodian with PHIPA obligations, and for a Caribbean health ministry building a national biobank, this is the more consequential exposure of the two.

Loss of cryptographic agility to a third party’s roadmap.If your post-quantum posture is whatever your cloud provider enables by default, your migration timeline is theirs. That may be favourable — the hyperscalers are ahead of most healthcare vendors — but it is not a decision you control, and it is not one you can evidence to a regulator asking what steps you took that were reasonable in the circumstances.

Concentration of the trust anchor.Consolidating certificate issuance, key wrapping, and identity signing into a single external platform creates precisely the concentration the TransForm incident illustrated at a smaller scale, where “nearly all of those applications were housed together within one segmented portion of the TSSO network” [9]. The governance lesson from that case is worth restating: TransForm was a non-profit founded, funded, and board-governed by the hospitals themselves. Third-party risk cannot be managed away by controlling the third party. It is managed by architecture.

None of this is an argument against cloud services for healthcare workloads. It is an argument that key custody is a separable decision from compute location, and that post-quantum migration is the moment to separate them.

6.3 The sovereign architecture

The defensible pattern for Canadian and Caribbean health data has four properties.

Hardware security modules.Specify FIPS 140-3 validated modules with post-quantum algorithm support, validated under the Cryptographic Module Validation Program — which the Cyber Centre operates jointly with NIST, so a CMVP certificate carries Canadian standing directly [7]. Require ML-KEM and ML-DSA in the module’s approved mode, not as a non-validated extension. Confirm that firmware update paths for the HSM itself use post-quantum signatures, since an HSM whose own firmware verification is RSA-based has an authentication weakness at the root of your key hierarchy.

Canadian supply available.Four Canadian firms participate in NIST’s migration consortium — ISARA (Waterloo), InfoSec Global (Toronto), Crypto4A and Entrust (Ottawa) [17]. Crypto4A manufactures post-quantum-capable HSMs in Canada. Sovereignty here is not aspirational; there is a domestic supply chain.

6.4 CyberChain’s position

CyberChain Technologies builds private, sovereign AI and cryptographic infrastructure for regulated organizations, on the premise that for health data the location and legal control of keys and models is a clinical governance question, not an IT preference. Our approach to post-quantum readiness in healthcare rests on four commitments:

1. Keys and models stay in jurisdiction. On-device, on-premises, and air-gapped deployments, so that no foreign legal instrument reaches patient data or the keys protecting it.
2. Discovery before procurement. We will not sell a hospital cryptographic infrastructure before it has a CBOM, because the inventory determines what is actually needed and routinely reduces the required spend.
3. Contractual crypto-agility, adopted from the Cyber Centre. ITSM.00.501 clauses in every agreement, including our own [7].
4. Alignment with PHIPA, PIPEDA, and Cyber Centre guidance as published, with an explicit second-transition plan attached to every hybrid deployment.

6.5 A note for Caribbean health ministries

The Caribbean is in an unusually strong position, for a reason that will not last.

CARICOM is building genomic and digital health capability now. At CARPHA’s 70th Annual Health Research Conference in April 2026, Secretary-General Dr Carla Barnett described a future in which “genomic research enables us to tailor non-communicable disease treatments to our uniquely complex genetic heritage,” and framed the governance requirement in terms this playbook adopts without modification: innovation “must be anchored by regional sovereignty,” addressing “who owns the data generated in our clinics? how do we ensure our citizens are not just ‘data points’ for external extraction?” and “how do we build a ‘Biobank’ that protects our biological assets while advancing global science?” [23]

Two facts should shape those design decisions.

Genomic data has the longest confidentiality lifetime of any health data, because it identifies relatives — including descendants not yet born — and it cannot be reissued. Financial credentials can be replaced after a breach; “genomic information, pediatric histories, psychiatric records, reproductive histories, and family-linked phenotypes remain persistently identifying and scientifically informative” [15]. Under Mosca’s inequality, genomic data has an effectively unbounded X, which means no future migration date is early enough. It must be protected with post-quantum cryptography from the moment of collection.

Small populations with distinctive genetic heritage are the highest-value harvest targets available.The characteristics that make a Caribbean biobank scientifically valuable — distinctive, well-defined population genetics — are the same characteristics that make its contents easy to re-identify and disproportionately informative to anyone who obtains it.

The opportunity is that systems still in design cost a fraction to build correctly compared with retrofitting. A national EHR or biobank specified today with hybrid post-quantum key establishment, domestic key custody, and ML-DSA certificate chains will require no migration programme at all. The Caribbean can skip the retrofit that Canadian hospitals are now facing— but only for systems not yet procured, and only if post-quantum requirements enter the specification before the contract is signed. Appendix C’s questionnaire is written to be usable as procurement criteria for exactly that purpose.

7. Quick-start actions: the 30-60-90 day plan

Nothing in this section requires capital approval, a business case, or a vendor. It requires roughly one full-time equivalent of coordination effort and the attention of an executive sponsor. The objective at day 90 is a funded, board-endorsed roadmap.

Days 1–30: Establish authority and begin discovery

Days 31–60: Assess, pilot, and educate

Days 61–90: Roadmap, budget, and board endorsement

8. Appendices

Appendix A — Glossary

Appendix B — CBOM template

Reproduce as a spreadsheet, one row per cryptographic component. Fields marked ★ are the minimum viable subset if resourcing forces a reduced first pass: Asset ID ★, System name ★, Component ★, Exposure ★, Algorithm(s) and key size ★, Protocol and version, Cryptographic function ★, Hosting platform and region, Cryptographic module and CMVP certificate, Data classification ★, Longest retention obligation ★, Confidentiality lifetime (X, years) ★, Clinical criticality, HNDL exposure ★, Trust-anchor status ★, Vendor and product version ★, Contract expiry date, Expected refresh year, Vendor PQC roadmap status and committed date ★, Crypto-agility ★, Migration priority (P1–P4) ★, Migration status ★, Accountable owner ★, Discovery method(s) used, Last verified date.

Worked example row

Appendix C — Vendor assessment questionnaire

Issue to every vendor with access to, or custody of, personal health information, and to medical device manufacturers. Responses in writing, with a stated deadline. Use as procurement evaluation criteria for new acquisitions.

Section 1 — Cryptographic transparency

1. Provide a Cryptographic Bill of Materials for the product as deployed in our environment, in CycloneDX 1.6 format where available [16]. If unavailable, list all cryptographic algorithms, key sizes, protocols, and certificate types used for data in transit, data at rest, authentication, and software or firmware signing.
2. Identify every use of RSA, Diffie–Hellman, ECDH, ECDSA, or EdDSA in the product, and the key sizes or curves used.
3. Confirm whether any component uses SHA-1, SHA-224, 3DES, or AES-128, and where.
4. State the cryptographic modules used and their CMVP certificate numbers, if validated.

Section 2 — Post-quantum roadmap

1. Does the product currently support ML-KEM (FIPS 203) for key establishment? If yes, in which version and configuration? If no, state the committed release date.
2. Does the product currently support ML-DSA (FIPS 204) or SLH-DSA (FIPS 205) for digital signatures? If no, state the committed release date.
3. Will you commit contractually to supporting post-quantum key establishment and digital signature schemes compliant with ITSP.40.111 by the end of 2026, consistent with the Cyber Centre’s recommended contract clauses in ITSM.00.501 [7]?
4. Confirm whether post-quantum support will be delivered as a maintenance upgrade under the existing agreement, or will require a new licence, new hardware, or additional cost. State amounts if applicable.
5. Does the product support hybrid key establishment (for example X25519+ML-KEM)? Can classical-only key exchange be disabled by configuration?

Section 3 — Cryptographic agility

1. Can cryptographic algorithms, parameter sizes, key lengths, and crypto periods be configured without replacing software or hardware components [7]?
2. Does the product support vendor-signed patches and updates? What algorithm signs them, and can the verification algorithm be updated in the field?
3. What is the maximum certificate and signature size the product can process? Have you tested with ML-DSA certificates?

Section 4 — Medical devices (where applicable)

1. State the expected supported field lifespan of the device from date of manufacture.
2. Is the cryptography used for secure boot, firmware verification, and remote communication updatable in the field, or fixed in hardware?
3. Would a change of cryptographic algorithm require a Health Canada licence amendment? If so, what is your projected timeline, and have you initiated it [18]?
4. What are the memory, compute, and power constraints that would limit adoption of post-quantum algorithms on this device?
5. If the device cannot be migrated, what isolation or gateway architecture do you recommend and support?

Section 5 — Key custody and jurisdiction

1. Where are cryptographic keys protecting our data generated, stored, and backed up? State country and legal entity.
2. Can we retain sole custody of key material — customer-managed or customer-held keys — including for backups?
3. Which foreign jurisdictions could compel production of our data or of key material held by you or your sub-processors?
4. Identify all sub-processors with access to key material or unencrypted PHI, and their jurisdictions.

Scoring guidance. Classify each vendor as Ready (post-quantum support shipping today with hybrid configurable and classical disableable), Committed (contractual commitment to a dated deliverable, ideally end of 2026), or Silent(no roadmap or no answer). Escalate every Silent vendor to the contract owner. Where a renewal falls before 2028, make post-quantum support a condition of renewal — the Cyber Centre’s rationale is that specifying the date lets you buy when you need to without waiting for the vendor’s current state to change [7].

Appendix D — References

1. NIST, “NIST Releases First 3 Finalized Post-Quantum Encryption Standards,” 13 August 2024. https://www.nist.gov/news-events/news/2024/08/nist-releases-first-3-finalized-post-quantum-encryption-standards
2. NIST IR 8547 (initial public draft), “Transition to Post-Quantum Cryptography Standards,” November 2024. https://csrc.nist.gov/pubs/ir/8547/ipd
3. NIST, “NIST Selects HQC as Fifth Algorithm for Post-Quantum Encryption,” 11 March 2025. https://www.nist.gov/news-events/news/2025/03/nist-selects-hqc-fifth-algorithm-post-quantum-encryption
4. Canadian Centre for Cyber Security, ITSM.40.001, “Roadmap for the migration to post-quantum cryptography for the Government of Canada,” 23 June 2025. https://www.cyber.gc.ca/en/guidance/roadmap-migration-post-quantum-cryptography-government-canada-itsm40001
5. Treasury Board of Canada Secretariat, “Migrating the Government of Canada to Post-Quantum Cryptography: Security Policy Implementation Notice,” effective 9 October 2025. https://www.canada.ca/en/government/system/digital-government/policies-standards/spin/migrating-government-canada-post-quantum-cryptography.html
6. Canadian Centre for Cyber Security, ITSP.40.111 version 5, “Cryptographic algorithms for UNCLASSIFIED, PROTECTED A, and PROTECTED B information,” effective 29 May 2026. https://www.cyber.gc.ca/en/guidance/cryptographic-algorithms-unclassified-protected-protected-b-information-itsp40111
7. Canadian Centre for Cyber Security, ITSM.00.501, “Recommended contract clauses for cryptography,” 1 September 2025. https://www.cyber.gc.ca/en/guidance/recommended-contract-clauses-cryptography-itsm00501
8. Office of the Superintendent of Financial Institutions, Technology Risk Bulletin, “Quantum Readiness Phases and Timelines,” March 2026. https://www.osfi-bsif.gc.ca/en/risks/technology-cyber-risk-management/technology-risk-bulletin/quantum-readiness-phases-timelines
9. Bluewater Health (Re), 2025 CanLII 56947 (ON IPC), PHIPA Decision 284, 16 June 2025. https://canlii.ca/t/kcpjn
10. H. Adkins and S. Schmieg, Google, “Quantum frontiers may be closer than they appear,” 25 March 2026. https://blog.google/innovation-and-ai/technology/safety-security/cryptography-migration-timeline/
11. Cloudflare, “Cloudflare targets 2029 for full post-quantum security,” 7 April 2026. https://blog.cloudflare.com/post-quantum-roadmap/
12. C. Gidney, “How to factor 2048 bit RSA integers with less than a million noisy qubits,” arXiv:2505.15917, 21 May 2025. https://arxiv.org/abs/2505.15917
13. R. Babbush and H. Neven, Google Research, “Safeguarding cryptocurrency by disclosing quantum vulnerabilities responsibly,” 31 March 2026. https://research.google/blog/safeguarding-cryptocurrency-by-disclosing-quantum-vulnerabilities-responsibly/
14. M. Cain et al., “Shor’s algorithm is possible with as few as 10,000 reconfigurable atomic qubits,” arXiv:2603.28627, 30 March 2026. https://arxiv.org/abs/2603.28627
15. S-P. Wu, S-D. Wu, K-C. Lu, and C-C. Wu, “Post-quantum cryptography for healthcare: securing medical data, connected devices, and digital health infrastructure,” Frontiers in Health Services, vol. 6, 16 July 2026. https://doi.org/10.3389/frhs.2026.1901282
16. OWASP CycloneDX, “Cryptography Bill of Materials (CBOM).” https://cyclonedx.org/capabilities/cbom/
17. NIST National Cybersecurity Center of Excellence, “Migration to Post-Quantum Cryptography” (NIST SP 1800-38). https://www.nccoe.nist.gov/applied-cryptography/migration-to-pqc
18. Health Canada, “Guidance Document: Pre-market Requirements for Medical Device Cybersecurity,” effective 26 June 2019. https://www.canada.ca/en/health-canada/services/drugs-health-products/medical-devices/application-information/guidance-documents/cybersecurity/document.html
19. Ontario Health, “Digital Health Information Exchange (DHIEX).” https://www.ontariohealth.ca/digital/standards/info-exchange.html
20. O. Reg. 329/04 under the Personal Health Information Protection Act, 2004. https://www.ontario.ca/laws/regulation/r20569
21. College of Physicians and Surgeons of Ontario, “Medical Records Management,” June 2022. https://www.cpso.on.ca/physicians/policies-guidance/policies/medical-records-management
22. Ontario Health, “Electronic Health Record Retention Policy and Procedure,” INF-009.02-PP, April 2026. https://ontariohealth.ca/about/privacy/resources/ehr-retention-policy.html
23. CARICOM, “CARICOM Secretary-General: AI, Genomics and Digital Health Will Transform Caribbean Public Health,” 22 April 2026. https://caricom.org/caricom-secretary-general-ai-genomics-and-digital-health-will-transform-caribbean-public-health/
24. Bill 194, Strengthening Cyber Security and Building Trust in the Public Sector Act, 2024, S.O. 2024, c. 24. https://www.ola.org/en/legislative-business/bills/parliament-43/session-1/bill-194
25. NIST CSWP 39, “Considerations for Achieving Crypto Agility: Strategies and Practices.” https://nvlpubs.nist.gov/nistpubs/CSWP/NIST.CSWP.39.pdf
26. Medcrypt, “What is post-quantum cryptography — and why should medical device makers care,” 24 June 2025. https://www.medcrypt.com/blog/what-is-post-quantum-cryptography---and-why-should-medical-device-makers-care
27. M. Ivezic, “Canada’s PQC Regulatory Framework,” December 2025, updated June 2026. https://postquantum.com/quantum-policies/canada-pqc-regulatory-framework/
28. M. Ivezic, “Canada’s PQC Framework: Sound Design, Stalled Execution,” 5 June 2026. https://postquantum.com/post-quantum/canada-pqc-framework-bill-c8-stalls/
29. CBC News, “Privacy investigator in Ontario hospital cyberattack outlines missteps, chances to improve,” 18 June 2025. https://www.cbc.ca/news/canada/windsor/ransomware-privacy-commissioner-hospitals-1.7564336
30. Canadian Centre for Cyber Security, ITSAP.00.017, “Preparing your organization for the quantum threat to cryptography.” https://www.cyber.gc.ca/en/guidance/preparing-your-organization-quantum-threat-cryptography-itsap00017
31. K. Walker and H. Neven, Google, “The quantum era is coming. Are we ready to secure it?” 6 February 2026. https://blog.google/innovation-and-ai/technology/safety-security/the-quantum-era-is-coming-are-we-ready-to-secure-it/
32. Office of the Superintendent of Financial Institutions, Guideline B-13, “Technology and Cyber Risk Management,” effective 1 January 2024. https://www.osfi-bsif.gc.ca/en/guidance/guidance-library/technology-cyber-risk-management
33. Canadian Medical Protective Association, “A matter of records: retention and transfer of clinical records.” https://www.cmpa-acpm.ca/en/advice-publications/browse-articles/2003/a-matter-of-records-retention-and-transfer-of-clinical-records
34. Canadian Centre for Cyber Security, ITSAP.00.132, “Cyber security for connected medical devices,” 5 November 2021. https://www.cyber.gc.ca/en/guidance/cyber-security-connected-medical-devices-itsap00132
35. NIST FIPS 203, “Module-Lattice-Based Key-Encapsulation Mechanism Standard,” August 2024. https://csrc.nist.gov/pubs/fips/203/final
36. NIST FIPS 204, “Module-Lattice-Based Digital Signature Standard,” August 2024. https://csrc.nist.gov/pubs/fips/204/final
37. NIST FIPS 205, “Stateless Hash-Based Digital Signature Standard,” August 2024. https://csrc.nist.gov/pubs/fips/205/final
38. Personal Health Information Protection Act, 2004, S.O. 2004, c. 3, Sch. A. https://www.ontario.ca/laws/statute/04p03
39. Office of the Privacy Commissioner of Canada, “The Personal Information Protection and Electronic Documents Act (PIPEDA).” https://www.priv.gc.ca/en/privacy-topics/privacy-laws-in-canada/the-personal-information-protection-and-electronic-documents-act-pipeda/
40. National Security Agency, “Commercial National Security Algorithm Suite 2.0.” https://www.nsa.gov/Press-Room/News-Highlights/Article/Article/3148990/

Further reading

• Canadian Forum for Digital Infrastructure Resilience (ISED), “Canadian National Quantum-Readiness: Best Practices and Guidelines” — the Canadian multi-stakeholder “Discover, Assess, Manage” framework.
• NIST SP 1800-38B, “Quantum Readiness: Cryptographic Discovery” — includes a functional test plan for cryptographic discovery tools.
• NIST SP 800-208, “Recommendation for Stateful Hash-Based Signature Schemes” — for firmware and code-signing roots.
• Bank for International Settlements, BIS Papers No. 158, “Quantum-readiness for the financial system: a roadmap.”
• UK National Cyber Security Centre, “Timelines for migration to post-quantum cryptography.”

Ready to measure where you stand? The four quantum-readiness questions in our AI Readiness Assessment map directly to Sections 4 and 5 of this playbook, and the Quantum Threat Intelligence feed tracks the timeline this playbook is built on.

Regulatory positions and standards referenced are current as of August 2026 and are subject to change. Health information custodians should obtain advice from qualified legal counsel and their privacy office regarding the application of PHIPA, PIPEDA, and provincial health privacy legislation to their circumstances.