About this tool
About this tool
This tool scores your blockchain deployment's quantum exposure across six weighted dimensions: chain type and signature scheme, network structure and governance, on-chain data sensitivity, Harvest Now, Decrypt Later (HNDL) exposure, migration complexity, and key management practices. The scoring model is grounded in NIST post-quantum cryptography standards (FIPS 203, FIPS 204, FIPS 205) and the NSA CNSA 2.0 migration framework, and reflects the specific risk that Shor's algorithm, executed on a cryptographically relevant quantum computer, can recover ECDSA or RSA private keys from public keys, breaking the signature security that underpins every major blockchain protocol. Eight questions produce a directional exposure tier and sector-specific migration guidance. The output is an assessed exposure estimate, not a formal security audit; it does not inspect node software, key management infrastructure, or smart contract code.
How the scoring works
This tool calculates an exposure score from six weighted dimensions. Chain type and on-chain data sensitivity each carry the highest individual weight because, in combination, they determine both the severity of a quantum compromise and the difficulty of preventing it.
The scoring formula: Score = (Chain type × 0.20 + Network structure × 0.15 + Data sensitivity × 0.20 + HNDL exposure × 0.15 + Migration complexity × 0.20 + Key management × 0.10) × 20.
Chain type and signature scheme (weight: 20%): the protocol your deployment uses and its underlying signature algorithm. ECDSA on secp256k1 or P-256 is the most widely deployed signature scheme across major blockchain protocols and is directly vulnerable to Shor's algorithm. RSA-based signing faces the same threat. Chains using ed25519 or post-quantum signature schemes are materially better positioned. Permissioned enterprise chains with known participants have a narrower and more governable migration scope than permissionless public chains with thousands of anonymous validators.
Network structure and governance (weight: 15%): the size and governance model of your validator or participant set. A migration to quantum-safe signature schemes requires coordinated protocol upgrades across all nodes. A small permissioned network with a defined governance process can execute a hard fork or protocol upgrade on a planned schedule. A global public chain with anonymous validators, contentious governance history, and diverse node software versions faces a migration coordination problem that has no clear precedent. Governance capacity is a primary constraint on how quickly migration is achievable even after post-quantum standards are finalised.
On-chain data sensitivity (weight: 20%): the sensitivity of the information recorded on-chain. Data that is permanently immutable on-chain cannot be deleted if future decryption becomes possible. Sensitivity determines what the consequence of retrospective exposure is.
HNDL exposure (weight: 15%): whether the transaction data, smart contract state, or off-chain data referenced by on-chain records is subject to Harvest Now, Decrypt Later collection. The chain's immutability means historical transactions are available indefinitely for retrospective decryption once a CRQC is operational.
Migration complexity (weight: 20%): the practical difficulty of migrating your deployment to quantum-safe algorithms. Factors include whether participants can coordinate a protocol upgrade, whether smart contracts would need to be redeployed, whether hardware wallets or HSMs need firmware updates, and whether cross-chain interoperability would be broken by an asymmetric migration.
Key management practices (weight: 10%): how private keys are generated, stored, and rotated in your deployment. Keys derived from BIP32/BIP39 hierarchical deterministic wallets expose every derived key once a master key is compromised.
Important Information About How We Use This Data
No account is required. Anonymised results are recorded for sector-level benchmarking.
Anonymised country, industry, and results data are recorded for sector-level benchmarking. No email, name, or company details are transmitted or stored. Individual respondents cannot be identified from the anonymised data.
If you choose to download your results as a PDF, that file is generated locally in your browser. Your name and company (if entered) are used only for the PDF and are not transmitted to any server.
For questions about how Quantum Security Defence handles personal data, see our privacy policy.
Blockchain Quantum Exposure Scanner
Eight questions. Results are a directional exposure tier with sector-specific guidance.
Which sector best describes your blockchain deployment?
Select the sector that best describes the primary use case of this blockchain deployment. Sector determines which regulatory frameworks and migration obligations are most relevant to your deployment, and which sector-specific context appears on your results page.
The Industry selection is required and recorded anonymously. Your industry may impact your score. Be sure to choose your nearest industry category.
About You
Name and company are used only within your browser session. They are not stored or transmitted.
Name and company are used only within your browser session. They are not stored or transmitted.
What type of blockchain deployment is this, and which signature scheme does it use?
Select the description that most closely matches your deployment. The signature scheme determines the specific quantum vulnerability. ECDSA on secp256k1 (Bitcoin, Ethereum) and ECDSA on P-256 (many permissioned chains) are both vulnerable to Shor's algorithm. Ed25519 (Solana, Cardano, some Hyperledger configurations) uses a different elliptic curve and is in the same vulnerability class (the concrete attack cost differs, but both are broken by Shor's algorithm). Chains using ML-DSA (NIST FIPS 204), SLH-DSA (NIST FIPS 205), or other post-quantum signature schemes are not vulnerable to Shor's algorithm.
Your answer is used to calculate your score. Results data is recorded anonymously for benchmarking. No email, name, or company details are transmitted or stored.
How many participants or validators does your network have, and how is protocol governance handled?
Migration to quantum-safe signature schemes requires all nodes to upgrade to software that supports the new scheme. For public chains, this requires broad consensus across an anonymous, distributed validator set. For permissioned chains, it requires coordination across all known participants. Governance capacity, that is the practical ability to plan, schedule, and execute a protocol upgrade across all participants, is a primary constraint on migration timelines.
Your answer is used to calculate your score. Results data is recorded anonymously for benchmarking. No email, name, or company details are transmitted or stored.
How sensitive is the data recorded or referenced on this chain?
On-chain data is typically permanent: once committed, it cannot be deleted. Consider the sensitivity of the data in your deployment's most sensitive transactions or records. If sensitive information is stored in encrypted form on-chain, the ciphertext and any on-chain references to off-chain data are both potentially subject to future retrospective decryption. Select the category that applies to your highest-sensitivity on-chain data.
Your answer is used to calculate your score. Results data is recorded anonymously for benchmarking. No email, name, or company details are transmitted or stored.
Is the sensitive data in your deployment subject to Harvest Now, Decrypt Later risk?
Harvest Now, Decrypt Later (HNDL) is a data collection strategy in which an adversary captures encrypted data today and retains it for decryption once a CRQC becomes available. For blockchain deployments, HNDL exposure applies to any transaction or record that requires ongoing confidentiality beyond the projected CRQC availability window. The NSA CNSA 2.0 framework sets 2030 as the target transition date for key establishment in national security systems; organisations managing data with multi-decade confidentiality requirements face HNDL risk on shorter timescales. Where sensitive data is publicly accessible on-chain, it is by definition already available for collection.
Your answer is used to calculate your score. Results data is recorded anonymously for benchmarking. No email, name, or company details are transmitted or stored.
How complex would a quantum-safe migration be for this deployment?
A migration to post-quantum signature schemes requires updating node software, reissuing signing keys, and in most cases redeploying or migrating smart contracts. Cross-chain bridges, hardware wallets, HSMs, and client software may all require updates. The difficulty varies substantially: a private single-operator chain can plan and execute this unilaterally, while a public chain with an anonymous global validator set depends on community consensus that has no guaranteed path or timeline. The NIST FIPS 204 (ML-DSA) signature standard is available now; the constraint is deployment feasibility, not algorithm availability.
Your answer is used to calculate your score. Results data is recorded anonymously for benchmarking. No email, name, or company details are transmitted or stored.
How are private keys managed in your deployment?
Key management practices affect both the attack surface available to a future adversary and the operational complexity of a key migration. BIP32/BIP39 hierarchical deterministic wallets are widely used for managing large numbers of derived keys from a single master key; a quantum adversary recovering the master key from its public key would compromise all derived keys. HSM-backed key management with hardware attestation reduces some risks but does not alter the underlying cryptographic vulnerability if the HSM uses ECDSA. Post-quantum key generation and storage changes the risk profile fundamentally.
Your answer is used to calculate your score. Results data is recorded anonymously for benchmarking. No email, name, or company details are transmitted or stored.
Does your deployment face formal regulatory obligations regarding cryptographic security?
Select the description that best reflects the regulatory environment your deployment operates in. Some sectors face specific guidance or emerging requirements on post-quantum cryptography. The NSA CNSA 2.0 framework, published in 2022, sets transition timelines for US national security systems; the NIST post-quantum standards (FIPS 203, 204, 205) are the algorithm reference for all sectors. Sector-specific regulators in finance, healthcare, and critical infrastructure are beginning to issue quantum migration guidance. Understanding your regulatory obligations is distinct from, but related to, your technical exposure. This question is informational and does not affect your exposure score.
Your answer is used to display relevant regulatory context on your results page. Results data is recorded anonymously for benchmarking. No email, name, or company details are transmitted or stored.
Need expert guidance?
Commission a formal blockchain quantum migration assessment
Our PQC migration specialists work with financial institutions, enterprise blockchain operators, and government agencies on quantum cryptographic risk programmes. We can assess your deployment's full migration path and build a phased delivery roadmap.
QSECDEF Intelligence
Blockchain quantum security updates as the risk picture evolves
The quantum threat to blockchain infrastructure is advancing. We track protocol-level post-quantum migration roadmaps, NIST standards developments, and sector-specific regulatory guidance.
- Protocol migration announcements (Ethereum, Hyperledger, Corda)
- NIST FIPS 203/204/205 implementation guidance updates
- Sector-specific regulatory quantum migration guidance
- Monthly PQC and blockchain security digest