The ‘Crypto-Agile’ Audit: Getting Ready for Quantum Threats

As technology evolves, so do the challenges we face, especially in the world of cybersecurity. One of the biggest emerging threats is quantum computing, which has the potential to crack many of today's cryptographic systems wide open. So, how do we prepare for this? Enter the ‘Crypto-Agile’ Audit.

What is a ‘Crypto-Agile’ Audit?

A 'Crypto-Agile' audit is essentially a thorough review of your cryptographic systems. It focuses on how ready you are to deal with quantum computing threats. The idea is to ensure that your organization can quickly transition to new cryptographic solutions without sacrificing security or performance.

Why Bother?

You might be wondering, “Why should I care about quantum computing?” Well, quantum computers could potentially break traditional encryption methods like RSA and ECC, which are widely used today. This puts sensitive data at risk. Here are a few reasons why you should think about conducting a 'Crypto-Agile' audit:

• Future-Proofing: Preparing now means you won’t be caught off guard later.
• Risk Management: Identifying vulnerabilities helps in mitigating risks before they become major issues.
• Trust Building: Show your clients and stakeholders that you’re serious about security.

Steps to Conduct a ‘Crypto-Agile’ Audit

Here’s a simple roadmap to guide you through the audit process:

1. Inventory Your Cryptographic Assets: Take stock of all the cryptographic systems you're currently using.
2. Assess Vulnerabilities: Identify which of these systems could be compromised by quantum computing.
3. Evaluate Quantum-Resistant Alternatives: Research and decide on newer, quantum-resistant algorithms that can replace your current ones.
4. Plan for Transition: Create a clear strategy for how you will implement these new systems.
5. Continuous Monitoring: Once you’ve made the switch, keep an eye on the landscape. Stay updated on new developments in both quantum computing and cryptography.

Conclusion

In a world where quantum threats are becoming more real, it's crucial to stay ahead of the game. A 'Crypto-Agile' audit is not just a checkbox exercise; it’s a strategic move towards securing your future. By being proactive, you can protect your data and maintain the trust of your clients and stakeholders.

For more info on quantum threats and cryptography, check out this resource.

Who This Is For (and the Keywords You Care About)

• Audience: We're looking at folks like CIOs, CISOs, Heads of Cryptography/PKI, Digital Asset Custody Leads, and Blockchain Platform Owners, especially in banks, exchanges, payment processors, and tokenization initiatives.
• Your Required Keywords: Here are the keywords we’ll be weaving into our content:
  • CNSA 2.0, CNSSP‑15 milestones;
  • FIPS 203/204/205;
  • RFC 9881 (ML‑DSA in X.509);
  • TLS 1.3 ECDHE‑MLKEM hybrid;
  • EntryPoint v0.8, EIP‑7702;
  • ERC‑1271, ERC‑6492;
  • PKCS#11;
  • FIPS 140‑3 Level 3 HSM (Luna, Utimaco);
  • ML‑KEM/ML‑DSA support in HSM firmware;
  • stateful HBS (LMS/XMSS) under SP 800‑208;
  • WebAuthn/P‑256 via RIP/EIP‑7212;
  • zkVM/SP1;
  • STARK “post‑quantum‑friendly.”
• Your PKI team is all set to roll out ML‑DSA certs tomorrow, but there’s a hitch: your custody HSM cluster struggles with signing or verifying them consistently across different partitions. On top of that, your blockchain setup is still geared towards ECDSA/keccak, and your mobile wallet plans to introduce passkeys (P‑256) this quarter. Plus, procurement is pushing for “CNSA 2.0 compliant” language in the RFPs, while the TLS team is testing X25519+ML‑KEM without messing up mTLS. On the bright side, RFC 9881 (ML‑DSA in X.509) is now active, and the drafts for TLS hybrid key exchange are laying out X25519MLKEM768. Even Cloudflare and AWS are running PQ‑TLS in their production environments. So, the real bottleneck isn’t the standards anymore; it’s all about your integration plan, HSM firmware, and smart-account design. (datatracker.ietf.org)
• Regulatory/mission timelines:
  • So, here’s the scoop on CNSA 2.0/NSM‑10: there won't be any enforcement until December 31, 2025. But heads up, all new NSS acquisitions have to meet CNSA 2.0 standards by January 1, 2027. They’re expecting to phase things out by 2030, with full enforcement kicking in by December 31, 2031, and everything should be quantum-resistant by 2035. If you’re onboarding long-lived systems in 2026 without crypto-agility, you’re basically signing up for some costly tech debt down the line. (safelogic.com)
  • The UK’s NCSC is saying you need to identify vulnerable services by 2028, prioritize those upgrades by 2031, and get everything wrapped up by 2035. So, you’ve got a nice little window from 2026 to 2028 to take stock and maybe even run some pilots. (theguardian.com)
• Threat timing:
  • Right now, there’s no CRQC, but keep in mind the “harvest-now-decrypt-later” tactic. This means secrets from 2026 could be at risk of exposure in the 2030s. NIST has given a green light to ML‑KEM, ML‑DSA, and SLH‑DSA, and they’re strongly recommending that you get your migration process started ASAP. (csrc.nist.gov)
• Engineering reality:
  • Let’s be real--your tech stacks are all over the place: you’ve got TLS endpoints, gRPC for microservices, on-chain wallets, firmware signing, and cross-chain bridges. Each of these areas is going to need some customized migration efforts (think hybrid TLS, ML‑DSA X.509, LMS/XMSS for long-lived firmware, and ZK-wrapped verification flows for the chains). Delaying these migrations could lead to release slippages, emergency waivers, and a bigger audit bill when 2027 to 2030 rolls around.

We focus on two key points: 1) signatures and KEMs are going to evolve again; 2) keeping your product roadmaps moving is crucial for your ROI. Our approach is crafted to align with CNSA 2.0 and the requirements of enterprise blockchain, all without the flashy antics of crypto hype.

1) Standards-Anchored Target Architecture (No Guesswork)

• Control-Plane Cryptography:
  • Signatures: Let's start using ML-DSA for X.509 chains right away (check out RFC 9881). We’ll keep SLH-DSA (SPHINCS+) as a backup for special cases or stuff that needs to last a really long time. And we're gearing up for FN-DSA once FIPS 206 wraps up. (datatracker.ietf.org)
  • Key Establishment: We’re piloting TLS 1.3 hybrid groups like X25519MLKEM768 / P-256MLKEM768 using the IETF drafts. Let’s also align with Cloudflare/AWS’s PQ-TLS rollout plans. (ietf.org)
  • Stateful HBS: For signing firmware or quorum configurations, we're implementing LMS/XMSS as per SP 800-208. We're being super strict about state management, ideally using HSM. (csrc.nist.gov)
• Ethereum Account Model Crypto-Agility:
  • We’re looking to use EIP-7702 (hitting mainnet on May 7, 2025) to “attach” smart-account features to EOAs. This way, we can change validation policies without messing with user addresses. We’ll pair this with ERC-1271 for contract-based signature checks and ERC-6492 for pre-deployment signature verifications during onboarding. (blog.ethereum.org)
  • Short-Term UX: We’ll enable passkeys (WebAuthn P-256) through rollup precompiles (RIP/EIP-7212) that a lot of L2s are rolling out in 2024-2025. After that, we’ll lay out a roadmap for post-quantum verification using ZK (details below). (gov.optimism.io)
• ZK as the Post-Quantum Bridge:
  • Just a heads-up, SNARKs aren’t post-quantum friendly, but STARKs are hash-based and pretty much good to go for the future. We’re leveraging zkVMs and STARK-style systems to verify PQ signatures off-chain and then putting succinct proofs on-chain. With Succinct’s SP1 and similar stacks, we can make this happen right now. (arxiv.org)

2) HSM/KMS Enablement Without Forklift Upgrades

• So, the Thales Luna firmware 7.9 (along with T‑Series 7.15.0) now supports those nifty ML‑KEM and ML‑DSA mechanisms with some cool PKCS#11 extensions. On the other hand, Utimaco Quantum Protect bumps things up a notch by adding ML‑KEM, ML‑DSA, plus LMS and XMSS, all with a simulator for integration testing. We're sticking to vendor-defined mechanisms for now and mapping them to FIPS OIDs as they become finalized. You can check out more details here.
• We're also diving into PQ‑TLS pilots using AWS Payment Cryptography and AWS SDKs, running end-to-end tests with CloudTrail's tlsDetails to make sure ML‑KEM is actually in play. If you're interested in learning more, take a look at this link.

3) Solidity and Wallet Migrations You Can Ship in Sprints

• Validation Policy Module:
  • Time to set up a validator module (ERC‑1271) that can handle multiple types of signatures: secp256k1 (ECDSA), P‑256 (through RIP/EIP‑7212 where it's applicable), and ZK‑wrapped ML‑DSA/SLH‑DSA (think off-chain verification leading to on-chain proof). This way, you can keep your signature process flexible without messing with your core business logic. Check out more about it here.
• 7702‑Based “Smart EOA” Rollout:
  • You can maintain the same user addresses while introducing features like sponsor gas, batched operations, session keys, and policy upgrades. This approach works seamlessly with EntryPoint v0.8 along with the new ERC‑7579/7902 capability descriptors. For more details, dive into this link.

4) Procurement-Ready Artifacts (What Your RFP and CAB Need)

• Here are the RFP clauses we provide:
  • “TLS endpoints SHALL support TLS 1.3 hybrid groups X25519MLKEM768 and P‑256MLKEM768 as laid out in draft‑ietf‑tls‑ecdhe‑mlkem; certificate chains SHALL use ML‑DSA according to RFC 9881; firmware signing SHALL utilize LMS/HSS under SP 800‑208 in FIPS 140‑3 Level 3 HSMs; the vendor SHALL document PKCS#11 mechanism IDs for ML‑KEM/ML‑DSA and supply migration runbooks.”
• Packages for CAB/Architecture Board include:
  • A threat model for HNDL (harvest-now-decrypt-later); procedures for key ceremonies related to LMS state management; rollback plans; performance envelopes for PQ-TLS; plus gas and latency baselines for ZK-wrapped verification.

5) Delivery structure and SLAs

• Phase 0 (2-3 weeks): We're kicking things off by taking stock of our crypto inventory across various systems like PKI, TLS, HSMs, Solidity repositories, wallets, and bridges. During this phase, we'll make sure to label every endpoint and contract with details like “algorithm, lib, OID/mech, and upgrade path.”
• Phase 1 (6-8 weeks): Next up, we’ll run a pilot for PQ-TLS and get the ML-DSA issuing CA in action. We’ll also implement the 7702/1271 policy module for one of our production dapps and test some HSM firmware upgrades in a non-production environment.
• Phase 2 (8-12 weeks): Finally, we'll roll things out to our priority services. This includes establishing a ZK-wrapped ML-DSA validation path to an L2, along with solid RFP language and vendor conformance tests.

Practical Examples (Precise, 2026-Ready Patterns)

1) Custody Platform: Firmware Signing + Wallets

• Problem: We’re dealing with ECDSA-signed firmware, seed-phrase wallets, and EOAs that are all stuck with a static signature scheme. Not ideal, right?
• Implementation:
  • Firmware: Let’s switch things up to LMS/HSS (SP 800-208) in the HSM with state replication. We’re also eyeing that roadmap for ML-DSA-87 by 2027. You can read more about this here.
  • Wallets: It’s time to enable passkeys through RIP/EIP-7212 on supported L2s now. Plus, we’ll roll out 7702 so customers can hang on to their EOA while enjoying smart-account perks and signature upgrades down the line. Get the details here.
  • PKI: We need to issue ML-DSA intermediate CAs, set up dual-stack verification in apps, and hold off on hybrid certs until LAMPS wraps up those composites. More info can be found here.
• Outcome: This move should give us an immediate UX boost and keep everything stable -- no address changes needed! Plus, we can cut over firmware without any downtime, and auditors can line up controls with CNSA 2.0.

2) Tokenized Assets / DvP Rails Between L2s

• Problem: The current bridging and settlement code relies on ECDSA, which means it needs to handle on-chain verification of traditional signatures.
• Implementation:
  • We're looking at off-chain verification using ML-DSA/SLH-DSA with a zkVM (think SP1/RISC-Zero class), while keeping on-chain STARK verification in the mix. Plus, we’ll be aggregating proofs to make sure gas costs stay manageable. Check out more on this here: blog.succinct.xyz.
  • For the bridge control plane, we’ll be using PQ-TLS along with ML-KEM authenticated channels for extra security. More details can be found at this link: ietf.org.
• Outcome: This approach keeps the bridge secure against potential HNDL attacks, and it also ensures that verification costs remain predictable, even as we switch up the signature schemes.

3) Exchange: API/mTLS and CA rotation

• Problem: You need PQ-TLS for customer API traffic and inter-service calls, and your CA has to issue ML-DSA leafs without messing things up for clients.
• Implementation:
  • Start with a pilot of X25519MLKEM768 in the canary tier; go with ML-DSA X.509 as per RFC 9881; make sure to verify everything with some Cloudflare/AWS-style telemetry.
  • For the HSM, use Thales 7.9/T-Series 7.15 or Utimaco Quantum Protect firmware to enable PKCS#11 mechanisms for ML-KEM/ML-DSA; kick things off with simulator-first testing. Check it out here.
• Outcome: This leads to a staged rollout while keeping mTLS continuity intact; the procurement team can require CNSA 2.0-capable endpoints in vendor contracts. Take a closer look at CNSA here.

Best Emerging Practices We Recommend in 2026

• Stick to “pure” ML‑DSA certificates as outlined in RFC 9881 for now; it’s best to hold off on any hybrid/composite certificates until LAMPS wraps up the composite ML‑DSA track, which made some good progress through multiple drafts in late 2025. You can check out the details here.
• Go with TLS hybrids (ECDHE+ML‑KEM) for that sweet forward secrecy without locking out clients. Keep an eye on the ECDHE‑MLKEM draft as it pushes toward becoming an RFC. More info can be found here.
• For those super long-lived signatures, like for firmware or root-of-trust, deploy LMS/XMSS as per SP 800‑208 with solid state control. Plan on migrating to ML‑DSA by 2030 to stick to CNSA 2.0 priorities. You can dive deeper here.
• On Ethereum:
  • Get 7702 out the door now to avoid any “address migration” headaches. Make sure to wrap signature verification behind ERC‑1271 and utilize ERC‑6492 for your pre-deploy processes. Check out more here.
  • If you need passkeys, aim for L2s with RIP/EIP‑7212 precompiles today. Once the mainnet standardizes the P‑256 precompile, you’ll be able to unify those paths. More details are available here.
• For ZK:
  • Lean towards STARK‑style systems if you’re looking for “post‑quantum‑friendly” features. Utilize SP1/zkVM ecosystems that are already supporting rollups and can verify any Rust/C code for PQC. Check it out here.

The solid signals you can use, no fluff here

• NIST PQC is legit and final: FIPS 203 (ML‑KEM), 204 (ML‑DSA), and 205 (SLH‑DSA) got the green light on August 13, 2024; FALCON (FIPS 206) is on track for later approval. Check it out here.
• X.509 with ML‑DSA is now standardized: Yep, RFC 9881 was released in October 2025. You can read the details here.
• Hybrid TLS is coming together: IETF drafts are laying out ECDHE‑MLKEM groups and hybrid constructions; the IESG wrapped up some last calls in 2025. Find more info here.
• Zero Trust stacks with PQ-TLS are out there: Cloudflare’s Zero Trust and AWS Payment Cryptography now offer full PQ options from end to end. Check the details here.
• HSMs are making strides: Thales is rolling out Luna 7.9+/T‑Series 7.15 with ML‑KEM/ML‑DSA, while Utimaco Quantum Protect is adding ML‑KEM/ML‑DSA + LMS/XMSS along with a simulator. You can find more info here.
• Ethereum account abstraction has landed: Pectra (May 7, 2025) brought in EIP‑7702; ERC‑1271/6492 are now in use across various stacks, and several L2s are running P‑256 precompiles. Catch the details here.

What You Get with 7Block Labs (and Where to Start)

Crypto‑Agile Audit Deliverables:

• You’ll receive a prioritized inventory that’s mapped to CNSA 2.0 along with your product deadlines.
• We provide a reference design that aligns with standards, including TLS stacks, PKI, HSM, and Solidity wallet policies.
• Plus, you’ll get a sprint plan that comes with measurable KPIs tied to your releases and procurement.

We Implement, Not Just Advise:

• We bring your ideas to life with PQ‑TLS pilots and ML‑DSA issuing CAs.
• We handle HSM firmware upgrades using vendor simulators.
• We also set you up with ERC‑1271 modules and 7702 wallets, along with ZK‑wrapped verification for PQ signatures.

Scalable Engagement:

• Begin with a specific line of business (think tokenization or custody operations) and choose a target chain (like L2 with RIP‑7212). Once you hit those success metrics, we can expand into the core platform.

KPIs and GTM Metrics We’re Committed to Measuring

• Cryptography Change-Lead Time: This is the number of days it takes from when we make a policy change to when it goes live. Our aim here is to keep it under 30 days per service after Phase 1.
• PQ-TLS Adoption: We want to track what percentage of our inbound API traffic is using ML-KEM hybrids. Our goal is to hit over 50% on pilot surfaces within 60 days. Check out more about it on ietf.org.
• Wallet UX Uplift: We’re looking at how well users complete passkey journeys compared to the traditional seed-phrase setup on supported L2s. We’re targeting a bump of 10-20% here.
• On-Chain Verification Cost: We’ll measure the gas fees involved in validating ZK proofs for PQ signatures versus older methods on our target L2s. The goal? Keep it at or below the costs of existing SNARK/STARK proof-verification.
• Audit Readiness: We're keeping an eye on how many control gaps we've closed against the CNSA 2.0 inventory and the NCSC timeline. Our target is to wrap up any P0 gaps within 90 days. For more info, check safelogic.com.

How We Connect to Outcomes (ROI, Procurement, Delivery)

ROI Lens:

• Reduced Future Refactors: We’ve made things smoother by separating the “signature policy” from the business logic (that’s 7702+1271, for those keeping track).
• Lower Vendor Risk: We kicked things off with an HSM simulator integration before rolling out the firmware, which really helps minimize risks.
• Avoid Last-Minute Waivers: To keep everything running smoothly, we anchor our work to NIST/IETF artifacts that auditors already love--like FIPS 203/204/205, RFC 9881, and those TLS hybrid drafts.

Procurement-Ready:

• We’ve got your sourcing team covered with ready-to-use clauses and clear acceptance tests. Think OIDs, PKCS#11 mechanisms, TLS ciphers, and ZK proof verification gas caps--all set for copy-pasting!

Delivery:

• We see ourselves as part of your cryptography and platform teams, working closely with clear sprint schedules. It’s all about making sure we’re in sync!

Where to Go Next with 7Block Labs

• Need some serious implementation power? Check out what we offer:
  • Dive into our blockchain integration for custom blockchain integration and backend adapters.
  • Get complete peace of mind with our security audit services for end-to-end audits.
  • Explore our web3 development services and blockchain development services for full-stack builds.
  • Looking for ZK and cross-chain engineering? We’ve got you covered with our cross-chain solutions development and blockchain bridge development.
  • If you're interested in smart wallets and policy modules, check out our smart contract development and dapp development.
• If you’re venturing into tokenized markets or custody solutions, we also specialize in asset tokenization, asset management platform development, and DeFi development services.

Brief In-Depth Technical Notes (For Your Crypto/PKI Leads)

• ML-DSA for X.509: Check out RFC 9881, which lays out the OIDs and encoding for ML-DSA‑44/65/87. When you're implementing, stick with “pure” (not pre-hash) unless your policy specifically calls for pre-hash flows. Also, don’t forget to plan for revocation path equivalence tests. Read more here.
• TLS Hybrids: The IETF hybrid-design draft is shaking things up by decoupling mechanism negotiation. The ecdhe-mlkem draft has set standards for the X25519MLKEM768 / P‑256MLKEM768 groups, and you can roll these out without waiting for an RFC--Cloudflare’s got some field notes backing this up. Dive into the details.
• HSM Mechanics: Thales Luna version 7.9 has introduced CKM_ML_KEM/CKM_ML_DSA families. Meanwhile, T-Series 7.15.0 is shipping with standardized PQC. Utimaco is offering PQC through vendor-defined PKCS#11. Make sure to use their simulators to validate CSR issuance, backup/restore processes, and high availability replication semantics before turning on your live CAs. Check out the Thales documentation.
• Ethereum Stack:
  • Version 7702 has been live on mainnet since May 7, 2025 (that’s Pectra). The current version for EntryPoint is v0.8 across all your AA tooling. You can enhance this by combining it with ERC‑1271/6492 for signature agility and pre-deploy flows. Oh, and L2s are widely backing P‑256 precompiles for WebAuthn. Find out more here.
• ZK Posture: If you’re after post-quantum-friendly assurances, you might want to lean towards STARKs or prove PQ verification in a zkVM, then verify succinctly on-chain. Production stacks like SP1 are already handling rollups and bridges efficiently. Read the paper for more insights.

A Final Word on Timing

• The road ahead is pretty straightforward: NIST has given the thumbs up for FIPS 203/204/205, ML-DSA in X.509 is now an RFC, TLS hybrids are in the home stretch with real-world implementations, HSM vendors are rolling out firmware, and Ethereum Pectra just hit 7702, offering account-level flexibility. So, as you look ahead to 2026, remember that your goal isn’t just to “research PQC”--it’s really about “operationalizing crypto-agility without holding up your releases.” (csrc.nist.gov)

Highly Specific CTA

Hey there! If you're handling the PKI/HSM budget and working on the Ethereum roadmap, we’d love to hear from you. Just send us the following:

1. Your root/intermediate OIDs and HSM firmware versions.
2. A list of TLS endpoints where you want to test out X25519MLKEM768.
3. Your choice of AA stack (7702/4337 vendor).

Once we get that info, we’ll whip up a 5-day gap analysis along with a sprint plan, some draft RFP clauses, and a 12-week rollout schedule that your CAB can approve right away. After that, we’ll be right there with you to make it happen!