Post-Quantum Cryptography: Should You Care in 2026?

An attacker who wants your data in ten years does not need to break your encryption today. They need to record it today. Encrypted traffic crossing a network, backups shipped to a third party, signed documents in an archive — anything captured and stored is a bet that the mathematics protecting it will fail before the data stops mattering. For most public-key cryptography in use today, that bet has a credible path to paying off, and the people most able to make it are well-resourced and patient.

This article is for CTOs, security leads and protocol teams deciding how much attention this deserves in 2026. We explain which primitives break, what has been standardised, what hybrid key exchange means in practice, why blockchains have a specific exposure, and what a proportionate response looks like — one that avoids both panic migration and the equally expensive mistake of doing nothing.

The real threat: harvest now, decrypt later

A cryptographically relevant quantum computer running Shor's algorithm would recover an RSA or elliptic-curve private key from its public key in hours rather than the age of the universe. No such machine exists. Today's hardware is noisy and small, and the gap to a fault-tolerant machine with enough logical qubits to attack a 2048-bit modulus or a 256-bit curve is large. Nobody can give you a reliable date, and anyone who does is selling something.

But the threat does not require the machine to exist yet. Key exchange in TLS, VPNs and messaging mostly uses elliptic-curve Diffie-Hellman. An adversary who records the handshake and ciphertext can, once a capable machine exists, recover the session key from the exchanged public values and decrypt everything. That traffic's confidentiality has a shelf life equal to the time until the machine arrives.

So the question for each piece of data is: how long must it stay secret, and does it cross a quantum-vulnerable channel? Medical records, government communications, long-lived intellectual property and legal privilege plausibly need confidentiality beyond any reasonable estimate of the timeline. Session cookies and yesterday's price feed do not.

Signatures are different, and the difference matters for the rest of this article. A signature forged in the future cannot retroactively change what was authorised in the past, provided the verifier checked it at the time. The signature problem arrives when the machine does: any public key that has been exposed can then be used to forge new signatures from its owner.

What is and is not at risk

Primitives that break

• RSA encryption and signatures, at every key size in practical use. Larger moduli buy almost nothing against Shor.
• Finite-field Diffie-Hellman and DSA.
• Elliptic-curve cryptography: ECDH key agreement, ECDSA and EdDSA signatures, on every standard curve. This includes secp256k1, the curve that secures Bitcoin and Ethereum account keys, and Ed25519 used across Solana and most modern SSH and signing deployments.

Primitives that survive with larger parameters

• Symmetric encryption such as AES. Grover's algorithm offers at most a quadratic speed-up against brute force, which in effect halves the key length. AES-256 remains comfortably secure; AES-128 drops to roughly 64-bit security against a quantum adversary, which is why guidance converges on 256-bit keys for long-lived data.
• Hash functions such as SHA-2 and SHA-3. Preimage resistance degrades modestly under Grover and existing output sizes retain ample margin. Keccak-256, which Ethereum uses for addresses and state, is in this category.
• HMAC, KDFs and AEAD constructions built on the above.

The problem is therefore concentrated in key exchange and signatures. Bulk encryption and integrity are fine, which narrows the migration considerably.

The standards, as they stand

NIST finalised its first three post-quantum standards in August 2024; these are the algorithms to expect vendors to ship.

• ML-KEM (FIPS 203), derived from CRYSTALS-Kyber: a lattice-based key encapsulation mechanism, the replacement for ECDH and RSA key transport.
• ML-DSA (FIPS 204), derived from CRYSTALS-Dilithium: a lattice-based signature scheme, the general-purpose replacement for ECDSA and RSA signatures.
• SLH-DSA (FIPS 205), derived from SPHINCS+: a stateless hash-based signature scheme. Slower, with much larger signatures, but its security rests only on hash functions, which makes it the conservative choice for firmware signing and long-lived roots of trust.

In March 2025 NIST selected HQC, a code-based key encapsulation mechanism, as a backup to ML-KEM built on different mathematics, with a standard to follow. A standard for FN-DSA, based on Falcon, is also in progress; it offers smaller signatures than ML-DSA at the cost of a more delicate implementation. The stateful hash-based schemes XMSS and LMS were standardised earlier for narrow uses such as firmware signing.

On timelines, NIST's draft transition guidance (IR 8547) proposes deprecating quantum-vulnerable public-key algorithms around 2030 and disallowing them in its standards by 2035. Those dates describe when US federal systems and their vendors will stop accepting RSA and ECC, not when a quantum computer arrives. For a commercial organisation they are a useful proxy for when the ecosystem around you will have moved.

These standards are new. Expect parameter guidance to be refined, implementations to have bugs, and side-channel results to appear. That is not a reason to wait; it is a reason to deploy in hybrid mode.

Hybrid key exchange: what is already happening

The pragmatic pattern for key agreement is hybrid: run a classical ECDH exchange and an ML-KEM encapsulation in the same handshake and derive the session key from both secrets. An attacker must break both. If ML-KEM has a flaw, the classical component still protects you today; if a quantum computer arrives, the ML-KEM component protects you then.

This is not theoretical. Hybrid exchange combining X25519 with ML-KEM-768 is deployed by default in major browsers and large CDN and cloud providers, so a substantial share of public TLS 1.3 traffic already negotiates it when both ends support it. The cost is a little bandwidth — ML-KEM public keys and ciphertexts are around a kilobyte against 32 bytes for X25519 — and negligible compute. Most organisations get this on public web traffic by updating a load balancer or CDN setting.

Where it does not come for free: internal services on older TLS stacks, VPNs with fixed cipher configurations, embedded devices, custom protocols with hand-rolled key exchange, and anything that pins a certificate chain or cipher list. These are where a harvest-now attacker gets the best return, and where an inventory is needed before anything can change.

Signatures are harder to deploy hybrid because certificate chains, protocol formats and hardware tokens all carry size assumptions; ML-DSA signatures are a few kilobytes against 64 bytes for ECDSA. Certificate authorities and PKI formats are still working out what that means, and we would not expect a typical enterprise to replace its PKI signature algorithms in 2026. The work now is making sure you could.

Crypto-agility and the inventory

The most valuable thing an organisation can do in 2026 is know where its cryptography is. Most do not. Algorithms are chosen implicitly by a library default, a cloud setting, a vendor appliance, or a developer who copied a snippet a decade ago. The cost of a migration is dominated not by the new algorithm but by finding every place the old one is used and what depends on it.

A cryptographic inventory records, for every system: the algorithms and key sizes in use, their purpose (key exchange, signature, encryption at rest, authentication), what data they protect and how long it must remain confidential or authentic, where the keys live, who owns the configuration, and whether the algorithm can be changed without a redesign. The last field is crypto-agility, and it is the property worth engineering for. A service that reads its cipher suite from configuration migrates in an afternoon; one that hard-codes curve parameters into a wire format needs a new protocol version.

Prioritise with two questions: how long must this data stay secret or trustworthy, and how exposed is it to capture? Long-lived secrets on channels an adversary could record go first.

What it means for blockchains

Public blockchains have an exposure most enterprise systems do not: the signature verification key is public by design, and often published long before it is needed.

On Bitcoin, a pay-to-public-key-hash address exposes only a hash of the key until the first spend. When funds are spent, the public key appears in the transaction, and if the address is reused — or an older output type published the key directly — that key sits permanently on the chain. On Ethereum, every externally owned account that has sent a transaction has revealed its public key, and account reuse is the norm. Any such key is a target for future forgery: derive the private key from the public one and sign a transfer. Funds behind unexposed hashes have a window; funds behind exposed keys do not.

Three consequences follow. Address reuse is a quantum-era risk, and wallets that generate a fresh key per receipt are better positioned. Dormant funds whose owners cannot migrate — lost keys, unmaintained contracts — are the hardest problem, with no consensus on what a chain should do about them. And the signature schemes must change, which is a governance problem as much as a cryptographic one.

Block space is the engineering constraint. A post-quantum signature of several kilobytes in place of 64 bytes of ECDSA multiplies the size of every transaction. Aggregation, account abstraction that lets each account choose its verification logic, and size-optimised schemes are the active areas, and several chains have started designing for the transition. For a protocol team today: avoid designs that assume a fixed signature size or curve, and if you implement account abstraction or a custom verifier, make the signature scheme a replaceable module rather than a constant.

Hash-based commitments, Merkle trees and proof-of-work are unaffected in any way that matters. The account signing layer is what needs to move.

What to do now, proportionately

Recommendations differ by what you are.

• Any organisation: enable hybrid key exchange on public-facing TLS and VPNs, which usually means updating software and configuration rather than buying anything. Move long-term symmetric keys to 256 bits. Start the inventory with systems carrying data whose confidentiality life exceeds five years.
• Organisations with regulated or long-lived data — finance, health, legal, government suppliers: complete the inventory, map it to retention requirements, and build a roadmap with the 2030 and 2035 marks as planning anchors. Ask every vendor in the critical path for their post-quantum plan in writing, and treat no answer as a risk.
• Products with long field lifetimes — embedded devices, vehicles, industrial equipment, anything shipped with a root of trust it cannot easily update: design the signature and update mechanism now so it can accept SLH-DSA or ML-DSA, because devices shipped this year will still be in service when the deadline passes.
• Blockchain protocols and wallets: stop address reuse where the architecture allows, make signature verification replaceable, follow the chain's own transition proposals, and put the question in your threat model rather than treating it as someone else's problem.

Avoid both mistakes

The first mistake is to treat this as an emergency and rip out working cryptography for implementations that are new, untested in production, and sometimes not even standardised. We have reviewed deployments where a team replaced a mature ECDH stack with a bespoke lattice implementation, introduced a timing side-channel, and ended up less secure against present-day attackers for protection against a hypothetical one. Hybrid exists to avoid this trade.

The second mistake is to wait for a definitive date. There will not be one. Progress in quantum hardware arrives as incremental papers, not a press release, and the organisations that announce a cryptographically relevant machine will not be the first to have one. A migration that takes five years must begin before anyone can prove it is necessary, and the harvest-now adversary is already collecting.

The right posture is deliberate: inventory, hybrid where it is cheap, agility where you build, and a roadmap with real dates for the hard parts.

How we run a crypto inventory assessment

An engagement runs in three phases.

Discovery combines scanning with interviews. We scan TLS endpoints, SSH servers, VPN concentrators and certificate stores for negotiated algorithms, key sizes and protocol versions; review code and configuration for library usage and hard-coded parameters; and talk to the owners of each system to learn what the data is and how long it must be protected. For Web3 clients we add the signing layer: key generation, address derivation, custody, and any custom signature verification in contracts.

Classification tags every cryptographic use with the primitive, its quantum status, the data's confidentiality or integrity lifetime, exposure to capture, and the effort to change. This produces a prioritised list rather than a frightening one.

The roadmap sets out what to change and in what order, separating the hybrid steps that can be done now from the structural changes that need design work, with vendor questions and test criteria for each migration. Where the client is building rather than buying, we review the implementation choices — library, parameter sets, side-channel considerations, key handling — with the same care as any other cryptographic review.

Practical next steps

Turn on hybrid key exchange where it is a configuration change. Pick your longest-lived secret and ask what channel it crosses; begin the inventory there. Ask your three most critical vendors for their plan. If you build protocols, make the signature scheme a parameter. Then set a date to revisit, because the standards and the hardware will both have moved.

Our cryptographic review and inventory services are on the services page; reach the team on Telegram.