Post-quantum encryption is no longer optional — here’s what changed in 2026

The transition to post-quantum cryptography has been discussed in security circles for a decade. For most of that time it was treated as a long-horizon problem: quantum computers capable of breaking RSA-2048 or elliptic-curve cryptography were plausibly 10–20 years away, and the urgency was calibrated accordingly. That calculus has changed.

Three developments in the past 24 months have moved post-quantum cryptography from “important future project” to “active compliance obligation” for regulated firms: the finalisation of NIST standards in August 2024, the accelerating evidence of harvest-now-decrypt-later collection operations by state actors, and regulatory frameworks in the EU and US that have begun explicitly referencing quantum-resistant cryptography requirements.

This article explains what post-quantum cryptography means in practical terms, what has changed in the regulatory and threat landscape, and what regulated firms — law firms, financial advisers, accountants, consultancies — need to do and why HubSecure has shipped ML-KEM-768 by default rather than treating it as an optional feature.

What post-quantum cryptography actually means

Most encryption used today in professional software — TLS for web traffic, RSA for key exchange, ECDSA for digital signatures — derives its security from mathematical problems that are hard for classical computers to solve. Factoring large integers (RSA) and computing discrete logarithms on elliptic curves (ECDH, ECDSA) are the two dominant families. They are computationally infeasible on today’s best classical hardware at adequate key sizes.

A sufficiently large quantum computer running Shor’s algorithm can solve both of these problems in polynomial time — meaning it can break RSA-2048 and ECC-256 efficiently. The question has always been how large “sufficiently large” is, and how far away we are from reaching it. Current estimates from NIST, NSA, and the UK’s NCSC converge on a range of roughly 10–15 years before cryptographically relevant quantum computers (CRQCs) are operational — though some researchers argue this timeline is accelerating.

Post-quantum cryptography (PQC) refers to classical algorithms — algorithms that run on today’s hardware — whose security does not depend on the integer factoring or discrete logarithm problems. NIST’s selected algorithms are based on different mathematical structures: lattice problems (ML-KEM, ML-DSA), hash-based signatures (SLH-DSA), and code-based cryptography (HQC, in draft). These problems remain hard for quantum computers to solve with known algorithms.

The critical point is that post-quantum algorithms are available, standardised, and implementable today on standard hardware. The transition does not require waiting for anything — it requires making the engineering decision to adopt standards that are already published and already being required by leading government and financial institutions.

Harvest-now-decrypt-later: the threat that makes waiting unacceptable

The most important argument for beginning PQC migration now — rather than when quantum computers are actually capable of breaking RSA — is harvest-now-decrypt-later (HNDL). The attack is simple: a sophisticated adversary intercepts and stores encrypted network traffic today, at scale, with the intention of decrypting it years from now once quantum computing capability has advanced sufficiently.

This is not speculative. The US National Counterintelligence and Security Center (NCSC), GCHQ, and multiple allied intelligence agencies have assessed that nation-state actors — primarily China, but not exclusively — have been conducting bulk collection of encrypted traffic for this purpose. The NSA’s decision to mandate PQC migration for National Security Systems was partly driven by the assessment that HNDL collection is active and extensive.

For regulated firms, the implication is direct. Data you transmit today — client communications, M&A negotiations, regulatory filings, financial plans — that is encrypted with RSA or ECDH may be in an adversary’s archive right now. Whether it ever becomes decryptable depends on when CRQCs become operational. But you cannot retroactively protect data that has already been captured. The only way to protect long-lived confidential communications against HNDL is to use post-quantum key exchange for communications that occur now.

This reframes the migration urgency. The question is not “when will quantum computers be able to break encryption?” — it is “how long do your most sensitive communications need to remain confidential?” For a law firm handling a major litigation matter, the answer may be 10–20 years. For a financial adviser managing a client’s wealth across decades, similar. If the data you are protecting today needs to remain confidential for longer than the expected time to cryptographically relevant quantum computers, HNDL is a present risk, not a future one.

The NIST standards: what ML-KEM, ML-DSA, and SLH-DSA actually are

The three NIST standards published in August 2024 cover the two most fundamental cryptographic operations: key establishment (agreeing on a shared secret over an untrusted channel) and digital signatures (proving authenticity and integrity of data).

ML-KEM (Module Lattice Key Encapsulation Mechanism, formerly Kyber) is the primary standard for key exchange. It replaces ECDH and RSA key exchange in TLS and other protocols. The “768” in ML-KEM-768 refers to the parameter set and corresponds to approximately 192-bit classical security — the same security level as AES-192. It is the most widely deployed variant and the one recommended by NIST for most applications, balancing security margin against performance overhead.

ML-DSA (Module Lattice Digital Signature Algorithm, formerly Dilithium) is the primary standard for digital signatures. It replaces ECDSA and RSA signatures for signing certificates, code, messages, and documents. Performance at the ML-DSA-65 level is competitive with current ECDSA implementations on modern hardware.

SLH-DSA (Stateless Hash-Based Digital Signature Algorithm, formerly SPHINCS+) is a hash-based signature scheme that provides a different mathematical foundation from the lattice-based algorithms — useful as a backup or in high-assurance contexts where you want diversity of cryptographic assumptions.

For most applications — encrypted web traffic, encrypted messaging, document signing — the relevant transition is to hybrid schemes that use both a classical algorithm (ECDH or RSA) and ML-KEM simultaneously. Hybrid schemes provide security against both classical adversaries today and quantum adversaries in the future. They are the recommended migration path because they require no reduction in classical security during the transition period.

Regulatory pressure: DORA, the US executive orders, and what is coming next

The regulatory environment around post-quantum cryptography has shifted substantially since 2023. What was previously guidance has become requirements for certain sectors, and draft requirements elsewhere.

In the United States, the National Security Memorandum on Promoting United States Leadership in Quantum Computing (NSM-10, May 2022) established the policy framework. NSA CNSA 2.0 set specific timelines for National Security Systems. The subsequent cybersecurity executive orders of 2024 and early 2025 extended quantum risk to critical infrastructure operators and required agencies to begin inventorying cryptographic assets against a PQC migration framework.

In the EU, the Digital Operational Resilience Act (DORA) entered into force for financial entities in January 2025. DORA does not explicitly mandate post-quantum cryptography, but its ICT risk management requirements — specifically Article 6(2)(c)’s requirement to “protect data at rest and in transit” and Article 9’s requirement to maintain up-to-date asset inventories — are being interpreted by leading supervisory authorities as requiring firms to assess quantum risk and maintain cryptographic agility. The EBA and ESMA have both referenced quantum risk in their 2025 supervisory priorities.

In the UK, the NCSC published updated guidance on post-quantum cryptography in early 2026, explicitly recommending that regulated sectors begin migration assessments in 2026 and aim for production deployments of post-quantum key exchange by 2028–2030. The FCA has included quantum risk in its 2026 Technology and Cyber Resilience Survey, signalling that it will form part of supervisory assessments.

For law firms, the SRA has not yet issued PQC-specific guidance, but the combination of solicitor confidentiality obligations under Principle 7 and the NCSC guidance creates a clear professional obligation to assess whether current encryption is adequate to protect client communications across their expected confidentiality horizon.

Why HubSecure ships ML-KEM-768 by default

The decision to ship ML-KEM-768 as the default key encapsulation mechanism in HubSecure — rather than as an opt-in feature — was driven by three considerations.

First, the performance overhead of ML-KEM-768 versus ECDH-256 is negligible in practice. ML-KEM-768 key generation and encapsulation/decapsulation operations complete in microseconds on modern hardware. The bandwidth cost of the larger key material (approximately 1,184 bytes for an ML-KEM-768 public key versus 64 bytes for an ECDH-256 public key) is measurable but not significant for the communication patterns of professional services applications. There is no meaningful user experience cost to defaulting to the stronger algorithm.

Second, the HNDL threat applies to all users, not just those with high-profile matters. A small accounting firm may not feel like a nation-state target, but bulk collection is bulk collection — it does not discriminate by firm size. If your client communications are encrypted with classical cryptography and captured by an HNDL operation, the fact that you are not the primary target is no protection when decryption becomes feasible.

Third, making PQC opt-in creates a two-tier security model where the less technically aware users — often the smaller, more resource-constrained firms — get weaker default security. A platform that takes security seriously for regulated firms should not make the most protective settings available only to those who know to ask for them.

In practice, HubSecure uses a hybrid scheme: X25519 + ML-KEM-768 for key exchange in all encrypted communications. This means that communications are protected by both classical and post-quantum key exchange simultaneously. Compromising the communication requires breaking both algorithms — the classical algorithm protects against adversaries today, and the post-quantum algorithm protects against future quantum adversaries including HNDL collection that is occurring now.

Digital signatures for document integrity and authentication use ML-DSA-65 by default, with fallback verification of legacy ECDSA signatures for interoperability during transition periods. Certificate validation uses the existing PKI infrastructure but with quantum-resistant binding where the relying party supports it.

The implementation is based on open-source, publicly audited implementations of FIPS 203–205 rather than proprietary cryptography. This is the correct approach: cryptographic implementations should be public, auditable, and built on standards. HubSecure does not invent cryptography — it implements NIST’s standards correctly and by default.

For regulated firms evaluating platforms in 2026, the question to ask every vendor is simple: “What algorithm does your platform use for key exchange in encrypted communications, and what is your post-quantum migration roadmap?” A vendor that cannot answer clearly is a vendor that is not taking the question seriously. NIST’s standards have been final for nearly two years. There is no longer a good reason for a security-oriented platform to be shipping RSA or bare ECDH as its key exchange mechanism.

The transition to post-quantum cryptography will take the industry a decade to complete fully — every piece of software that does cryptography needs to be updated, every certificate infrastructure needs to be migrated, every hardware security module needs firmware updates. That decade starts now. The firms and platforms that start in 2026 will be ahead of mandatory regulatory requirements when they crystallise. The ones that wait for mandates will be in remediation mode rather than ahead of the curve.