Quantum Computing and Cybersecurity

No. There is no cryptographically relevant quantum computer, meaning a machine able to break RSA-2048 or the elliptic curve keys used in TLS, in public existence today. Cloudflare's own October 2025 review of the field put it bluntly: today's quantum computers are "simply not good enough today to crack any real-world cryptographic keys" (Cloudflare, October 2025).

What has changed is the estimate of how big such a machine needs to be. A 2025 paper from Google Quantum AI estimated that RSA-2048 could be factored in under a week by a machine with fewer than one million noisy qubits, a much lower figure than earlier estimates. Nobody has built that machine. Nobody can tell you the year it arrives either, and any vendor who quotes you a date is selling something.

The reason to act anyway is the time lag. An attacker who records your encrypted traffic or steals an encrypted backup in 2026 can sit on it. If that data still matters when the hardware exists, it is exposed. So the useful question for a small company is not "when does quantum arrive?" but "how long does my data need to stay secret, and how long will it take us to change our cryptography?"

The standards are done. On August 13, 2024, NIST published three: FIPS 203 (ML-KEM, formerly CRYSTALS-Kyber) for key exchange, and FIPS 204 (ML-DSA) and FIPS 205 (SLH-DSA) for digital signatures. NIST told administrators to start integrating them "immediately, because full integration will take time" (NIST, August 2024). In March 2025 NIST added HQC as a backup key exchange algorithm built on different mathematics, with a final standard expected in 2027 (NIST, March 2025).

The deadlines come from three documents:

Sources: NIST IR 8547 draft, the Cyber Centre roadmap and NSM-10. IR 8547 was still an initial public draft at the time of writing, so treat its dates as NIST's stated direction rather than a rule in force.

None of these applies directly to a private SaaS company. They reach you through customers. The Canadian roadmap explicitly recommends that departments put clauses in contracts requiring vendors to support post-quantum cryptography and cryptographic agility. If you sell to federal departments in either country, or to banks and insurers who follow them, expect the question in security questionnaires before 2030.

Privacy law is quieter. PIPEDA's safeguards principle and Quebec's Law 25 both require security measures appropriate to the sensitivity of the information, and HIPAA and the FTC Safeguards Rule set similar expectations in the US. None of them names post-quantum algorithms. Where they bite is sensitivity over time: a regulator looking at a breach of 15-year-old health records is unlikely to accept that the encryption was considered fine in 2026.

We use one rule in assessments. Add how many years your data must stay confidential to how many years a cryptographic change takes in your stack. If that total runs past the early 2030s, the data belongs in the first wave. Here is how that plays out, and some vendors will disagree with the right-hand column:

If you are unsure which row you sit in, our data security and privacy work starts with exactly this classification: what data you hold and how long it has to stay secret.

A lot of the transport layer has moved without you. Chrome switched to hybrid ML-KEM key exchange (X25519MLKEM768) in Chrome 131, after enabling the earlier Kyber version for all desktop users in 2024 (Google Security Blog). Cloudflare reported that by late October 2025 the majority of human-initiated traffic to its network used post-quantum encryption. Apple turned on quantum-secure TLS in the URLSession and Network frameworks in iOS 26 and macOS 26, and iMessage has used its PQ3 protocol since iOS 17.4 (Apple Platform Security).

So if your public app sits behind Cloudflare or another CDN that has turned it on by default, a Chrome user connecting to it today is probably already getting post-quantum key exchange. On a cloud load balancer, check whether you have selected its post-quantum TLS policy; that is usually a one-line change. Either way, it is real progress at little or no cost.

Here is what those vendors do not cover:

That list is where a small company's quantum work actually lives. Our cloud security controls reviews already check TLS versions and key management, so this is an extension of existing work rather than a new project.

This is the part most quantum articles leave out.

It will not move your breach risk in 2026. In our experience, the incidents that hurt companies your size tend to come from phished credentials, missing MFA, over-permissioned SaaS admin accounts, exposed secrets in code and unpatched edge devices. A post-quantum migration fixes none of those. If you still have TLS 1.0 endpoints or certificates nobody owns, those are the first job, and they happen to be the groundwork for PQC too.

It will not require new hardware. ML-KEM keys and ciphertexts are larger than elliptic curve ones, which matters for embedded devices and very constrained networks, but ordinary servers, laptops and phones handle them without trouble.

It will not get you a SOC 2 or ISO 27001 exception, in either direction. Auditors test whether your cryptography policy exists and is followed (ISO 27001 Annex A 8.24 covers use of cryptography). No mainstream audit framework fails you today for using RSA. A policy that names post-quantum migration as a planned control does read well, though.

And it does not justify a standalone "quantum program" with its own budget line. For a 30 to 200 person company, this is a workstream inside your existing security plan.

This is the sequence we run when a client asks us to get them "quantum ready" without boiling the ocean. Each step has one owner and one output.

None of this needs specialist quantum expertise. It needs someone to own it. If you have a virtual CISO, it belongs on their roadmap; if you do not, our pricing page shows the vCISO tiers, which start from US$2,000 a month.

Expect it in three places first. Enterprise security questionnaires will add a line asking whether you have a post-quantum transition plan, and the honest answer from the 90-day work above is enough. Government buyers in Canada will follow the Cyber Centre's guidance on procurement clauses, and US federal buyers will follow NIST's dates. And in the defence supply chain, CMMC Level 2 requires FIPS-validated cryptography, so the migration path there runs through validated modules, on the vendors' timeline, not yours.

For SOC 2 and ISO 27001, the practical move is to fold post-quantum migration into your existing cryptography policy and risk register through your GRC program, so it is reviewed on the same cycle as everything else.

Pull your TLS scan results and your key inventory, or admit you do not have one. That single gap tells you whether quantum readiness is a configuration exercise or a project. If you want an outside baseline first, run our free cybersecurity baseline assessment, then book a call and we will tell you which row of the shelf-life table you sit in and what the next 90 days should look like.