Launching a Post-Quantum Cryptography (PQC) Readiness Assessment

The cryptographic foundation of Web3 is under a long-term, predictable threat. Quantum computers pose a significant risk to the public-key cryptography that secures digital signatures and key exchanges on networks like Ethereum, Solana, and Bitcoin. While large-scale, fault-tolerant quantum computers are not yet operational, the data encrypted today is vulnerable to "harvest now, decrypt later" attacks. A PQC readiness assessment is a systematic audit to identify these vulnerabilities before they can be exploited.

This process moves beyond theoretical discussion to actionable inventory. It involves cataloging every system component that relies on vulnerable algorithms, such as ECDSA (Elliptic Curve Digital Signature Algorithm) and RSA, which are used for wallet signatures, node authentication, and TLS connections. For developers, this means examining smart contract libraries, consensus client software, RPC endpoints, and key management systems. The goal is to create a precise map of cryptographic dependencies across your entire stack.

The assessment provides a clear roadmap for migration, which is not a simple algorithm swap. Transitioning to post-quantum cryptography (PQC) standards like CRYSTALS-Kyber (for key encapsulation) and CRYSTALS-Dilithium (for digital signatures)—recently standardized by NIST—requires careful planning. Changes can affect performance, interoperability, and even the fundamental logic of systems like multisig wallets or cross-chain bridges. An early assessment allows for phased testing and integration, minimizing disruption.

For blockchain organizations, the business case is clear. Proactive assessment mitigates future regulatory, operational, and reputational risk. As quantum computing advances, regulators and users will increasingly demand quantum-resistant security. Projects that can demonstrate a credible migration plan will maintain trust and compliance. The assessment is not an expense but an investment in the longevity and resilience of your protocol, dApp, or infrastructure service in the post-quantum era.

The first prerequisite is cryptographic inventory. You must create a comprehensive map of all systems using cryptography within your organization. This includes identifying asymmetric algorithms (like ECDSA for signing and ECDH for key agreement), symmetric ciphers (AES), and hash functions (SHA-256). For blockchain projects, this inventory is critical and must cover wallet key generation, transaction signing, consensus mechanisms, and secure communication channels between nodes or smart contracts. Tools like code scanners and dependency checkers can automate parts of this discovery process.

Next, define the assessment scope with precision. Will you evaluate your entire technology stack or focus on a specific high-value subsystem, such as a custodian wallet or a cross-chain bridge protocol? The scope should be informed by a risk analysis, prioritizing components that handle long-lived secrets (e.g., root keys for a multi-signature wallet) or are critical to network consensus. A clearly documented scope prevents scope creep and aligns all stakeholders on the goals, deliverables, and timeline of the assessment.

Technical readiness is also essential. Your team needs access to the source code, architecture diagrams, and system documentation for the in-scope components. You should also establish a test environment that mirrors production, as PQC migration testing should never be conducted on live mainnets. For developers, this means having a dedicated testnet or a local development chain (like a Hardhat or Anvil instance) configured with the current cryptographic libraries, such as OpenSSL or libsecp256k1.

Finally, assemble your assessment team. This requires cross-functional expertise: cryptography specialists to analyze algorithm dependencies, blockchain developers who understand the codebase, and infrastructure engineers responsible for deployment. For many organizations, engaging with external PQC auditing firms that have experience with blockchain systems, like Chainscore Labs or Trail of Bits, is a practical approach to gain the necessary depth of expertise for a thorough evaluation.

A cryptographic inventory is a comprehensive list of all cryptographic primitives, algorithms, and libraries used across your technology stack. This includes the code you write, the dependencies you import, and the protocols you interact with. For a Web3 project, this inventory must cover on-chain smart contracts, off-chain backend services, developer tooling, and any client-side applications. The goal is to identify every instance where cryptography secures data or transactions, such as digital signatures in wallets, hash functions in Merkle trees, or encryption in storage layers.

Start by auditing your source code repositories. Use automated tools like grep or specialized SAST (Static Application Security Testing) scanners to search for imports and calls related to cryptography. For example, in a Solidity codebase, you would look for the use of ecrecover, keccak256, or the Crypto library in Vyper. In JavaScript/TypeScript projects, audit packages like ethers.js, web3.js, libsodium, or node-forge. Create a spreadsheet or structured document to log each finding with its location, purpose, and the specific algorithm (e.g., ECDSA with secp256k1, SHA-256, AES-256-GCM).

Next, examine your infrastructure and external dependencies. This includes the consensus mechanisms of the blockchains you deploy on (which may use BLS signatures or VDFs), oracle networks, cross-chain bridge protocols, and key management systems. Review the documentation for any third-party APIs or services you integrate. For instance, using The Graph for indexing or Chainlink for oracles involves trusting their cryptographic implementations. Document these external trust boundaries, as their migration to PQC will be outside your direct control but critical to your system's overall security posture.

Finally, analyze the data flows and persistence layers. Identify what sensitive data is encrypted, where keys are stored, and how identities are established. This covers user wallet private keys (often secured with mnemonic phrases using BIP-39), encrypted database fields, TLS certificates for your frontend, and session management tokens. Understanding these data flows reveals which cryptographic elements are most vulnerable to a quantum attack, such as long-lived public keys used for wallet addresses or static data encrypted for long-term storage.

The first actionable step is to conduct a systematic audit of your entire technology stack. This involves cataloging every component that uses cryptographic primitives vulnerable to quantum attacks, primarily ECDSA (Elliptic Curve Digital Signature Algorithm) and SHA-256. Focus on three core layers: the application layer (smart contracts, wallets, dApps), the consensus layer (validator/client software), and the network layer (peer-to-peer communication, RPC providers). Tools like static analysis (SAST) for Solidity or Vyper can automate the discovery of ecrecover calls and keccak256 hashing within your contracts.

For smart contracts, dependencies are often explicit. Audit your import statements and linked libraries. Key areas include: - Signature verification (ecrecover, OpenZeppelin's ECDSA.sol) - Merkle proof verification - Randomness generation (VRF) - Any hash function usage (for commitments or unique IDs). For off-chain components, examine wallet SDKs (like ethers.js, web3.js), transaction signing processes, and the cryptographic libraries used by your backend services or oracles. The goal is to create a comprehensive dependency graph linking each feature to its underlying crypto primitive.

Beyond your direct code, you must assess external dependencies. This includes the underlying blockchain's consensus mechanism (e.g., Ethereum's LMD-GHOST/Casper FFG still uses ECDSA for validator signatures), any cross-chain bridge or layer-2 protocol you integrate, and key management solutions. For example, if your dApp uses a multisig wallet like Safe, you need to understand its signing scheme. Document each dependency's version and the specific functions used, as migration paths will differ for a library function versus a core protocol rule.

A practical method is to run your audit in two parallel tracks. First, perform code-level analysis using tools specific to your stack. For Ethereum, Slither or Mythril can flag cryptographic operations. Second, perform protocol-level analysis by reviewing the documentation and specifications of any integrated third-party protocol or infrastructure provider. Record findings in a structured format, such as a spreadsheet or a dedicated audit tool, noting the component, its purpose, the vulnerable algorithm (e.g., ECDSA over secp256k1), and its criticality to system operation.

This map is not just a list; it's the foundation for your risk assessment and migration plan. It allows you to prioritize components based on impact—user-facing signature schemes are typically highest priority—and to identify components outside your direct control, which may dictate your timeline. A thorough dependency map is the single most important artifact for planning a realistic and secure transition to post-quantum cryptography.

With your cryptographic inventory complete, you must now prioritize which assets to migrate first. This is a risk-based decision. Critical systems with high-value data or long-term security requirements should be your top priority. This includes root Certificate Authorities (CAs), hardware security modules (HSMs) managing master keys, and core blockchain consensus mechanisms. Systems with shorter lifespans or lower sensitivity can be scheduled for later phases. Consider factors like data sensitivity, system lifetime, regulatory requirements, and the complexity of the cryptographic implementation itself.

For each prioritized asset, define a clear migration strategy. The primary path is cryptographic agility: refactoring systems to use abstracted cryptographic libraries (like liboqs) that allow algorithm swapping without major code changes. For legacy systems where this is impossible, a hybrid approach is recommended. This involves combining a current algorithm (like ECDSA) with a PQC algorithm (like Dilithium) in a dual-signature scheme, ensuring security even if one algorithm is broken. Document the chosen strategy, required dependencies (e.g., library versions like OpenSSL 3.2+ with PQC support), and any necessary architectural changes.

Your action plan must be a phased roadmap, not a single switch-flip. Phase 1 typically involves lab testing: deploying PQC algorithms in isolated testnets, sandboxed environments, or non-production blockchain forks to evaluate performance and compatibility. Phase 2 is a controlled pilot, such as implementing hybrid signatures for a subset of validator nodes or a specific smart contract function. Phase 3 is full production rollout, followed by Phase 4 for deprecating and removing the legacy classical cryptography. Assign clear owners, timelines, and success metrics (e.g., transaction latency, signature size overhead) for each phase.

Integrate this plan with your existing Software Development Lifecycle (SDLC) and operational procedures. Update your key management policy to define generation, storage, and rotation procedures for PQC keys. Modify your incident response plan to include scenarios related to cryptographic compromise. Ensure your DevOps pipelines can build and deploy the new PQC-enabled libraries. This systemic integration is crucial for maintaining security during and after the transition.

Finally, establish a monitoring and validation framework. After deploying a PQC algorithm like Falcon-512, you must actively monitor system performance and security. Use tools to verify that signatures are correctly generated and validated using the new primitives. Plan for algorithm agility from the start; NIST may update its recommendations (FIPS 203, 204, 205), and your systems should be designed to incorporate future changes. The action plan is a living document that must be reviewed and updated as standards evolve and your deployment experience grows.

Your assessment has identified critical vulnerabilities in your cryptographic inventory, from TLS certificates and digital signatures to blockchain consensus mechanisms. The next phase is to develop a migration roadmap. This is not a one-time upgrade but a multi-year program. Prioritize systems based on risk: data with long-term sensitivity (e.g., genomic data, state secrets, blockchain private keys) must be protected first. Establish clear crypto-agility as a core design principle, ensuring future algorithms can be deployed without major architectural overhauls.

Begin with hybrid cryptography implementations. Libraries like OpenSSL 3.0+ and liboqs support combining classical algorithms (e.g., ECDSA) with PQC algorithms (e.g., Dilithium) in a single signature. This provides immediate protection against "harvest now, decrypt later" attacks while maintaining compatibility. For blockchain developers, explore testnets implementing PQC schemes, such as those using SPHINCS+ for smart contract authentication or FrodoKEM for encrypted mempools. Monitor standardization bodies like NIST for final recommendations on FIPS-approved algorithms.

Continuously monitor the ecosystem. The PQC landscape is evolving rapidly. Subscribe to updates from NIST, IETF, and consortiums like the PQCRYPTO project. Engage with your technology vendors to understand their migration timelines for hardware security modules (HSMs), cloud KMS, and signing services. For ongoing governance, integrate PQC tracking into your existing software bill of materials (SBOM) and vulnerability management processes to maintain visibility into your cryptographic posture as dependencies update.

Finally, contribute to the community. Share non-sensitive findings from your assessment, participate in working groups, and test early implementations. The transition to post-quantum security is a collective effort. By starting your journey now, you secure not only your own assets but also help build a more resilient cryptographic foundation for the entire Web3 ecosystem and beyond.