The security argument for acting on post-quantum cryptography does not depend on believing a cryptographically relevant quantum computer is imminent. It depends on how long your data stays sensitive.
Encrypted traffic can be captured and stored now and decrypted later, once capability exists. For data with a short confidentiality life, such as a session token or a price quote, that is irrelevant. For health records, legal files, source code, government communications, and industrial process data, a decryption event a decade from now still causes the harm it would have caused today. That is the "harvest now, decrypt later" problem, and it makes the relevant deadline the age of your most sensitive long-lived data, not the arrival of the machine.
The work itself is mundane and slow. It begins with a cryptographic inventory: which systems use which algorithms, in which protocols, with which key lengths, under which certificates, including embedded devices, vendor appliances and code signing, all of which tend to be discovered late. Most organisations do not have this inventory and are surprised by its size.
Replacement then proceeds through hybrid schemes that run classical and post-quantum algorithms together, which is how the transition is being staged in practice. A hybrid key exchange derives a shared secret from both a conventional algorithm and a post-quantum one, so the result stays secure as long as either holds. That hedging matters because the post-quantum algorithms are comparatively young: they have survived public analysis, but they have not accumulated the decades of attempted attacks behind the schemes they are replacing, and at least one candidate in the standardisation process was broken during it.
Larger key and signature sizes have real effects on constrained devices and on protocols with tight packet budgets, so the migration is not a drop-in substitution. Some post-quantum signature schemes produce signatures an order of magnitude larger than the elliptic-curve equivalents in use today. On a fast connection that is invisible. On a metering device reporting over a low-bandwidth radio link, or in a protocol designed to complete a handshake inside a single network round trip, it is an engineering problem that has to be designed around rather than absorbed.
For Canadian firms the pressure is likely to arrive commercially before it arrives legally, through the supply chain. Security requirements travel downhill: a small vendor to a bank or a federal department will be asked about its cryptographic roadmap well before any statute compels it.
The inventory problem is worth dwelling on because it is the part organisations consistently underestimate. Cryptography is not concentrated in a security product; it is distributed through everything. It is in the TLS terminating at the load balancer, the certificates authenticating service-to-service calls, the signing keys on the software build pipeline, the VPN concentrator, the code-signing certificate on firmware shipped to customers, the encrypted database columns, the backup archives, and a payment terminal in a branch office that nobody has thought about in six years. Producing a complete list of where cryptographic material lives, what algorithms it uses and who controls its rotation is a multi-month exercise in a mid-sized organisation, and most discover during it that they cannot answer basic questions about systems they depend on.
Embedded and operational technology is the hardest category, which matters disproportionately in Alberta. Industrial control systems in the field have service lives measured in decades, limited compute headroom, and update paths that may require a physical visit to a remote site. A firmware signing scheme baked into a device shipped in 2020 and expected to run until 2045 will need to be migrated, and the cost of that migration is a function of decisions made years before anyone was thinking about post-quantum cryptography. Organisations operating large fleets of remote field equipment should be asking vendors about cryptographic agility now, because the answer determines whether the eventual transition is a software update or a truck roll.
There is also a procurement dimension developing faster than the regulatory one. Large customers have begun asking suppliers to describe their post-quantum migration plans as part of standard security questionnaires. For a small Canadian software vendor selling into a bank, a hospital network or a federal department, that question is likely to arrive in a contract renewal well before any statute requires anything. Being able to answer it credibly is becoming a commercial qualification, and being unable to answer it is starting to cost deals.
None of this requires panic, and the vendors selling urgency should be treated with the scepticism any security vendor selling urgency deserves. The standards exist, the algorithms are published, the major platform providers have migration paths in progress, and the transition will happen largely through software people already run. What it requires is that the work start early enough to be done deliberately rather than under a deadline.
The practical near-term step for most organisations is not to buy anything. It is to produce the inventory, identify data with a confidentiality life longer than five years, and ask existing vendors for their post-quantum roadmaps in writing. That work is useful regardless of when the technology arrives, because an organisation that knows where its cryptography lives is better positioned against every other class of security problem as well.
Sources
Figures in this article are drawn from the sources above. Spotted an error? Tell us and we will correct it.

