top of page

Quantum Computers Are Getting More Powerful — Here's What That Really Means

  • Writer: Gammatek ISPL
    Gammatek ISPL
  • Aug 13
  • 6 min read

By Gammatek ISPL, Industrial Systems & Compliance Analyst at Gammatek ISPL 

Last updated: August 2026 | 11 min read


Diagram showing the connection between 2026 quantum computing breakthroughs and industrial network encryption risk
2026's quantum hardware gains are real — and they're now colliding with a hard deadline for industrial encryption.
Author credibility block: Gammatek ISPL covers emerging technology risk for manufacturing, chemical, and pharmaceutical plants at Gammatek ISPL, with direct experience auditing cryptographic and compliance readiness across industrial facilities. This piece draws on NIST's 2026 post-quantum cryptography guidance, recent hardware research disclosures, and Gammatek's own client-readiness assessments conducted this year.

Why You Should Care


If your plant collects sensitive data today — production data, safety records, supplier contracts, proprietary process parameters — and that data is encrypted with standard RSA or ECC encryption, there's a real possibility someone is copying it right now, not to read it today, but to decrypt it later once a powerful enough quantum computer exists. Security researchers call this "harvest now, decrypt later." Every day of delay leaves that window of vulnerability open longer, and 2026 is the year this stopped being theoretical: real hardware progress and real government deadlines both landed this year. Here's what actually happened, and what it means for your plant specifically.


What Actually Happened in Quantum Computing This Year


It's worth separating hype from substance here, because quantum computing headlines have cried wolf before. But 2026 brought several breakthroughs backed by peer-reviewed or technically detailed disclosures, not just press releases:


Multiple organizations demonstrated exponential error suppression this year, meaning logical error rates now decrease as more qubits are added instead of getting worse — the opposite of how earlier-generation quantum systems behaved. Google's Willow processor, a 105-physical-qubit superconducting chip, showed logical error rates dropping by roughly a factor of 2.14x with each increase in surface-code lattice size, which researchers describe as the first hardware-scale confirmation that fault-tolerant quantum computing follows the scaling curves theorists had predicted for years.

Separately, D-Wave announced what it calls scalable, on-chip cryogenic control for gate-model qubits in early 2026 — addressing a long-standing bottleneck where adding more qubits required disproportionately more control hardware, space, and complexity. If that holds up at scale, it removes one of the practical barriers between "impressive lab demo" and "commercially deployable machine."


A third claim is worth flagging with more caution: in June 2026, a company called AIX Global Innovations published a report claiming to have achieved a fault-tolerant quantum computing milestone on rented IBM hardware back in April. This is a single company's own report rather than independent peer-reviewed replication, so it belongs in the "watch closely, don't treat as settled fact yet" category — a useful reminder that not every 2026 quantum announcement carries the same evidentiary weight.


The honest summary: quantum computers are still not able to break real-world encryption today. But the rate of credible progress accelerated meaningfully in 2026, and the gap between "years away" and "actively worth planning for" narrowed in a way that changed how seriously governments and security bodies are now treating the timeline.


Why This Matters Beyond the Lab: The Encryption Problem


Most of the internet — and most industrial networks — still rely on RSA and ECC encryption to protect data in transit and at rest. Both are mathematically secure against classical computers, but both are specifically the type of problem a sufficiently powerful quantum computer is expected to be able to solve. That's not a controversial claim; it's the reason NIST has spent years building replacement standards.

This is precisely why "harvest now, decrypt later" is treated as a live risk rather than science fiction: an attacker doesn't need a working quantum computer today to benefit from stealing your encrypted data today. They just need one eventually — and industrial data (proprietary formulations, safety and compliance records, long-term supplier contracts) often stays sensitive for years or decades, which is exactly the kind of data worth stealing now and waiting to decrypt.


The Deadlines Are No Longer Hypothetical


Until this year, post-quantum cryptography lived mostly in guidance documents. That changed in the final week of June 2026, when the US government issued a cluster of documents within days of each other that converted the transition from direction into obligation.

Executive Order 14412, signed June 22, 2026, requires federal agencies to migrate their highest-value and highest-impact systems to NIST-approved post-quantum algorithms for key establishment by the end of 2030, and for digital signatures by the end of 2031. Agencies were also required to name a migration lead by late July 2026 and submit a full migration plan shortly after.

This isn't purely a US federal story, either — similar migration deadlines are landing across the EU, UK, Australia, Canada, and Japan in roughly the same window, and nearly every jurisdiction is requiring a full cryptographic inventory as the first mandatory step before anything else can happen.

For plants that supply into regulated industries, government contracts, or multinational supply chains, these deadlines tend to cascade downward — even if your plant isn't a federal agency, your customers or partners who are will start asking you to demonstrate PQC readiness well before 2030.


Why This Is a Harder Problem for Industrial Plants Than for Offices


This is where the quantum story stops being abstract and becomes an operational problem specific to manufacturing, chemical, and pharma environments:

  • Equipment lifespan mismatch. A corporate laptop gets replaced every 3-5 years. A PLC or SCADA system on a plant floor often runs for 15-30 years. Cryptographic algorithms embedded in legacy industrial hardware can't simply be "patched" the way a software application can — some require physical hardware replacement.

  • Six structural bottlenecks slow real migration, and these compound rather than happen one at a time: legacy system complexity, a shortage of specialists who understand both OT and cryptography, slow procurement cycles typical of capital-intensive plants, incomplete records of what cryptography is even in use, vendors that aren't PQC-ready yet, and the need to coordinate the transition with outside partners and suppliers.

  • The inventory problem comes first. The essential first step is a thorough inventory to separate systems that can be patched from those that have reached end-of-life and need physical replacement — and most industrial plants have never built this inventory, because their cryptography was set once during initial installation and never revisited.

  • Crypto-agility as the real target. Rather than treating this as a one-time patch, the better long-term architecture separates application logic from the cryptographic provider entirely, so algorithms can be swapped through a central policy engine without rewriting the underlying software — a meaningfully different design philosophy than most legacy OT systems were built with.


What NIST Actually Standardized


Standard

Purpose

What to ask vendors

FIPS 203 (ML-KEM)

Key establishment (replacing RSA/ECC key exchange)

"Is your key exchange ML-KEM compliant?"

FIPS 204

Digital signatures

"Are your signed firmware/software updates PQC-signed?"

FIPS 205

Backup/alternative signature scheme

"Do you support a fallback signature algorithm?"

These three algorithms, built on lattice-based mathematics, are the official government-vetted standards — and a genuinely useful filter when evaluating any vendor now marketing itself as "quantum-safe." Proprietary "quantum-safe" solutions that haven't gone through NIST's standardization process are worth treating with real skepticism, since interoperability and independent vetting are the entire point of using a public standard in the first place.


Implementation Considerations for Plant Security Teams

This isn't a project to start in 2029. Based on how these migrations have played out elsewhere, here's a realistic sequence:

  1. Build a cryptographic inventory first — every system, device, and communication channel using encryption, prioritized by how long the underlying data needs to stay confidential.

  2. Flag "harvest now, decrypt later" risk explicitly — data with a long confidentiality shelf life (formulations, long-term contracts, safety records) gets prioritized over short-lived data, regardless of system size.

  3. Separate patchable systems from end-of-life hardware — this determines your capital planning timeline, not just your IT roadmap.

  4. Ask every vendor renewal or new purchase whether it's FIPS 203/204/205 compliant — this becomes a standard procurement question going forward, the same way "is this ISO 27001 aligned" became standard a decade ago.

  5. Build crypto-agility into new deployments — anything you're installing new in 2026 should be architected so its cryptography can be swapped without a full system rebuild.

  6. Document all of this for audit purposes — because whether or not your plant is directly regulated, your customers, insurers, or partners are increasingly likely to ask.

Where This Connects to Plant Compliance More Broadly


Quantum readiness is, at its core, a documentation and audit-trail problem before it's a hardware problem — you can't demonstrate progress on a migration you haven't inventoried, and you can't inventory systems you're not already tracking systematically. This is the same underlying challenge Gammatek's platform is built to solve for physical safety and process compliance: turning a sprawling, hard-to-track set of systems into a documented, audit-ready record.

If your plant is trying to figure out what's actually running on your network before you can even start a PQC conversation with regulators or partners, that's the same foundational work as any other compliance inventory — and it's worth tackling with the same rigor.




 
 
 

Comments


bottom of page