Quantum Computers Are Not a Future Problem

The conversation around post-quantum cryptography has shifted. For years it sat in the "important but not urgent" category -- something to monitor, something to plan for eventually. That changed in August 2024 when NIST published its first three finalised post-quantum cryptographic standards, and it has accelerated sharply since.

Government mandates are landing. Browser vendors are shipping hybrid quantum-safe connections in production. The CA/Browser Forum has voted unanimously to compress certificate lifetimes to 47 days. And adversaries are already collecting encrypted traffic to decrypt later.

For CTOs and security leaders, the question is no longer whether post-quantum cryptography matters. It is whether your infrastructure can absorb the change -- or whether you are building on a foundation that will need to be torn up and replaced.

What actually happened at NIST

In August 2024, after an eight-year evaluation process, NIST released three finalised standards for post-quantum cryptography. These are not drafts or candidates. They are approved, ready-to-deploy algorithms.

In March 2025, NIST added HQC as a fifth algorithm -- a code-based backup for ML-KEM, with finalisation expected in 2027. The critical point: these standards are published, approved, and implementable today. The gap is no longer in the cryptography. It is in the infrastructure.

Harvest now, decrypt later is not hypothetical

The most immediate quantum risk is not that someone will break your encryption tomorrow. It is that someone is recording your encrypted traffic today, storing it cheaply, and waiting for a cryptographically relevant quantum computer (CRQC) to make decryption trivial.

Intelligence agencies in multiple countries have warned publicly that this is already happening at scale. For any data with multi-year sensitivity -- intellectual property, financial records, strategic communications, cryptographic key material -- the effective security window may already be closing.

The timeline for a CRQC varies by estimate. IonQ's roadmap targets 2028. Forrester's 2026 assessment places Q-Day as a plausible risk by 2030. The Global Risk Institute considers a CRQC quite possible within ten years and likely within fifteen. It does not matter which estimate is right. What matters is whether your infrastructure can adapt before it has to.

The regulatory pressure is real and accelerating

Governments are not waiting for Q-Day to set deadlines.

Apple deployed PQ3 -- a post-quantum protocol -- in iMessage starting with iOS 17.4. And Google has made the most consequential move of all -- one that reshapes the entire landscape for certificate infrastructure.

Google just declared X.509 isn't enough

In February 2026, Google made an announcement that should have been front-page news for every security team: Chrome will not adopt post-quantum-signed X.509 certificates for public trust. The signatures are too large and the performance cost too high for the open internet.

Instead, Chrome is building an entirely new certificate format: Merkle Tree Certificates (MTCs). Under this model, a CA signs a single "Tree Head" representing potentially millions of certificates, and the "certificate" sent to the browser is a lightweight proof of inclusion in that tree. The result: quantum-resistant TLS authentication data shrinks from roughly 14,700 bytes down to as little as 736 bytes -- potentially smaller than today's classical certificate chains.

The real problem is not algorithms -- it is infrastructure

The cryptographic algorithms are ready. The challenge is that most organisations' trust infrastructure was not designed to absorb this kind of change.

Consider what a post-quantum migration actually involves. Every certificate in your estate -- root, intermediate, and leaf -- eventually needs to support post-quantum algorithms. Every system that validates a certificate needs to understand the new signature formats. Every key exchange in every TLS handshake needs to negotiate post-quantum parameters. Every piece of signed code, every firmware image, every authentication token needs to be re-evaluated.

And the hardest part is not the leaf certificates. The 47-day lifetime mandate will force automation for anyone who has not already adopted it. Leaf certificates are replaceable by design.

The hard part is the foundation.

Root certificates are created once and trusted for ten years or more. A root certificate created today will still be in active use in 2036 -- well within the window where post-quantum cryptography is expected to be necessary. Unlike leaf certificates, root certificates cannot be rotated on a schedule. Replacing a root requires coordinated updates across every system, service, and dependency that trusts it. Done under pressure, it is one of the most disruptive operations in infrastructure security.

The hybrid approach: future-proofing without disruption

The practical solution is hybrid certificates -- certificates that carry both a classical signature (ECDSA or RSA) and a post-quantum signature (ML-DSA) simultaneously.

This is not a compromise. It is a deliberate engineering strategy. A hybrid certificate works with every existing system today because those systems validate the classical signature and ignore what they do not recognise. When post-quantum validation becomes enforceable, systems can verify the embedded post-quantum signature without any certificate reissuance.

Inside your own trust boundaries -- internal APIs, service-to-service communication, Kubernetes workloads, air-gapped environments -- you control both the issuing CA and the validating endpoints. You are not waiting for browser vendors to agree on a new format. You are not waiting for the IETF to finalise MTC specifications. You are not waiting for CAs to rebuild their infrastructure around Merkle trees. Hybrid X.509 certificates work today, in your infrastructure, with your existing tooling.

The public web's PQC path is uncertain and evolving. Your private trust foundation does not need to wait for it.

This is the approach [cyphrs] has taken with its on-premises certificate authority. The cyphrs-ca tool enables infrastructure teams to create root and intermediate certificates that combine ECDSA with ML-DSA (FIPS 204) post-quantum signatures. The certificates are standard X.509, compatible with existing infrastructure, and carry the post-quantum material as embedded data that becomes verifiable when systems are ready. No migration. No parallel certificate hierarchies. No reissuance under pressure.

What a PQC readiness plan actually looks like

For CTOs and security leads evaluating their quantum readiness, the work breaks into four phases -- and the first two should be underway now.

The gap between Phase 2 and Phase 4 is the window where preparation pays off. Organisations that embed post-quantum capability now have years of runway. Organisations that wait will face a compressed, high-pressure migration when enforcement arrives.

Shorter lifetimes and post-quantum are the same problem

The 47-day certificate lifetime mandate and the post-quantum transition are often discussed as separate challenges. They are not. They are converging forces that together reshape how organisations must think about certificate infrastructure.

Shorter lifetimes force automation. You cannot manually manage certificates that expire every 47 days across hundreds or thousands of endpoints. This drives adoption of ACME-based automation, centralised policy management, and continuous monitoring -- exactly the operational capabilities that PQC migration also demands.

Organisations that build this automation now -- using tools like [cyphrs] ACME ARI for public certificate lifecycle and [cyphrs] Trust CA for private certificate issuance -- are simultaneously building the infrastructure they will need for PQC migration. The automation that renews a certificate every 47 days is the same automation that can rotate a certificate to a post-quantum algorithm when the time comes.

And mutual TLS adds another dimension. As machine-to-machine communication grows -- particularly with the rapid expansion of AI agents and autonomous systems -- every service and every agent becomes an identity that needs certificate-based authentication. Post-quantum readiness is not just about protecting web traffic. It is about ensuring that the identity layer for your entire infrastructure is built on cryptography that will survive the quantum transition.

The cost of waiting

The Boston Consulting Group has warned that starting PQC migration in 2030 will already be too late. The market for enterprise cryptographic migration is projected to exceed $15 billion by 2030, and the organisations paying the most will be those migrating under deadline pressure rather than on their own schedule.

The actions available today -- cryptographic inventory, hybrid root certificates, automated lifecycle management -- are low-cost, low-disruption, and high-leverage. They do not require betting on a specific quantum timeline. They simply ensure that the infrastructure you build now is the infrastructure that carries you through the transition, whenever it arrives.