Mitigating the Quantum Threat

Mitigation is not a single upgrade, because the quantum threat arrives through two different mechanisms that affect different parts of a system on different timelines.

Confidentiality Risk (HNDL)

If a system uses quantum-vulnerable key establishment today, an attacker can record encrypted traffic and attempt to decrypt it later once a CRQC exists. This is the harvest-now, decrypt-later attack, and it means the damage is being done now, even though the decryption happens in the future.

Authorization Risk (HNFL)

If a system relies on elliptic curve signatures for authorization, and an attacker can recover private keys from public keys, they can forge signatures and authorize transfers. For blockchains, this is the existential risk: not just theft, but a collapse of the ownership model itself — if anyone can produce a valid signature, signatures no longer prove ownership.

NIST guidance anticipates long transition periods and explicitly discusses hybrid approaches (running classical and post-quantum algorithms in parallel) as a pragmatic bridge. For digital assets, however, blockchains cannot typically deploy signature changes easily — strategies that require two full ecosystem migrations (first to hybrid, then to PQ-only) are often not viable. Most networks will need to aim for a single, well-planned migration.

Implementing Post-Quantum Cryptography in Protocols

Layer 1: Off-Chain Key Establishment

Key establishment is not the dominant risk driver for blockchains themselves, but it is a material risk surface for the broader digital asset ecosystem. Exchanges, custodians, wallets, validators, sequencers, bridges, and infrastructure providers all operate private control planes that carry sensitive data and high-impact administrative actions. These channels are plausible targets for long-term interception.

This work is low-coordination, high-leverage, and can be rolled out without user migrations. For digital asset operators, upgrading TLS and SSH to support post-quantum key exchange should be treated as an immediate baseline requirement, not a future roadmap item. If your infrastructure is not already running post-quantum key exchange, you are behind the security baseline that the rest of the Internet established in 2025.

Layer 2: Signature Ecosystems & Trust Roots

Post-quantum signatures are slower to deploy than post-quantum key establishment because signatures sit inside long-lived trust systems. Certificates, code signing, firmware signing, secure boot, and internal service authentication all depend on signature formats and verification logic that is widely deployed and difficult to update.

For digital assets, this layer matters because it is a common path to catastrophic loss. If an attacker can subvert software distribution or signing, they do not need to break the chain directly. They can ship a malicious wallet update, a compromised hardware wallet firmware, or a tampered node binary. That is why post-quantum signatures need to be treated as part of the supply chain and operational security program, not only as a future on-chain upgrade.

The IETF’s PQC engineering guidance makes the asymmetry clear: PQ key exchange is relatively self-contained, while PQ signature migration requires broader ecosystem changes across certificates, certificate authorities, HSMs, and trust anchors. The IETF LAMPS working group is actively defining how ML-DSA, SLH-DSA, and composite signatures are encoded in X.509 certificates. Adoption will be incremental: the first post-quantum certificates are expected in 2026, but broad availability and browser trust is unlikely before 2027. For digital asset organizations, high-value trust roots — release signing, firmware integrity, and custody signing services — should be the immediate priority, with broader PKI and application-layer migration following as standards and tooling mature.

Layer 3: On-Chain Authorization and Consensus Validation

On-chain signatures are the primary quantum risk for blockchains. Any change to the authorization mechanism implies changes to transaction formats, relay policies, fee markets, block propagation assumptions, and developer tooling.

Hybrid or dual-signature strategies — running classical and PQ signatures in parallel during a transition — are recommended by NIST and make sense in many contexts. On-chain, however, they are substantially harder to justify for three reasons.

• Economic Overhead. Carrying and verifying multiple signatures per transaction increases bandwidth and validation cost, reducing throughput or raising fees during the transition period. On chains that are already capacity-constrained, this is not a marginal cost.
• Operational Complexity. Wallets, exchanges, and custodians must support multiple signing paths and multiple address or account types, which increases failure modes during migration. Anyone who has lived through a major protocol upgrade knows that the number of things that can go wrong scales faster than the number of changes.
• Ecosystem Coordination. Unlike browsers and web servers, blockchains cannot generally change authorization formats invisibly. A hybrid approach can imply two full migrations for users and infrastructure: first into a hybrid state, and later into a post-quantum-only state. Each migration requires wallet updates, exchange integration work, custodian re-certification, and user key rotation at scale.

This is a structural difference between blockchains and the Internet protocols that have already begun their PQ transition. In TLS, hybridization is deployed without end users doing anything. On a blockchain, signature schemes and validation rules are part of the protocol, and the migration burden is carried by every wallet and every actor that signs transactions.

The implication for planning is that many networks will aim for a single major signature migration on-chain, supported by a migration mechanism that can move users safely without requiring a second coordinated transition. Getting this right as one migration, not two, is the central design challenge of blockchain PQC.

“Getting this right as one migration — not two — is the central design challenge of blockchain PQC.”