Post-Quantum Cryptographic Agility Governance

2. Summary

Post-Quantum Cryptographic Agility Governance requires that AI agents operating in crypto and Web3 environments implement a structured capability to inventory, assess, migrate, and verify all cryptographic primitives used in agent operations — including wallet key generation, transaction signing, session authentication, log integrity, and inter-agent communication — against post-quantum threat models. Current blockchain ecosystems rely almost entirely on elliptic curve cryptography (ECDSA secp256k1 for Ethereum and Bitcoin, EdDSA Ed25519 for Solana and Cosmos) that is vulnerable to quantum attack via Shor's algorithm. While large-scale fault-tolerant quantum computers capable of breaking ECDSA are not yet operational, the "harvest now, decrypt later" threat means that blockchain transactions recorded today — including the public keys revealed when signing — can be stored and attacked once quantum capability arrives. This dimension mandates that agents maintain a cryptographic inventory, implement algorithm-agnostic key management, establish migration-readiness procedures, and operate with post-quantum cryptographic hygiene even before full PQC migration is technically feasible on production blockchains.

3. Example

Scenario A — Harvest-Now-Decrypt-Later Exposure of High-Value Wallet: An AI custody agent manages a cold storage wallet holding 2,500 BTC (~$175M at $70,000/BTC). The wallet has made 47 outbound transactions over 3 years, each time revealing the public key in the transaction signature. A state-sponsored adversary records all blockchain transactions and stores the public keys associated with high-value addresses. When a cryptographically relevant quantum computer (CRQC) becomes operational — estimated between 2030 and 2040 — the adversary uses Shor's algorithm to derive the private key from any of the 47 revealed public keys. The entire 2,500 BTC balance is transferred to the adversary's address. Because Bitcoin's ECDSA private keys are deterministically derivable from the public key via quantum computation, and because blockchain transactions are irreversible, the theft is permanent and unrecoverable.

What went wrong: The organisation had no post-quantum migration plan. Public keys were exposed through standard transaction patterns without assessment of quantum risk. No address rotation strategy minimised public key exposure. No monitoring existed for quantum computing milestones that should trigger migration urgency. Consequence: $175M total loss, no recovery mechanism, insurance coverage denied due to foreseeable risk without mitigation.

Scenario B — Agent Log Integrity Collapses Under Quantum Attack: An AI trading agent maintains hash-chained audit logs using SHA-256 for integrity protection. The logs constitute the primary evidence trail for regulatory compliance. A quantum adversary, once CRQC is available, uses Grover's algorithm to find collisions in the SHA-256 hash chain (reducing effective security from 256-bit to 128-bit, and from 128-bit collision resistance to 64-bit — within brute-force range for a sufficiently powerful quantum computer). The adversary modifies historical log entries and reconstructs a valid hash chain. The organisation's compliance evidence is rendered unreliable.

What went wrong: While SHA-256 is more resistant to quantum attacks than ECDSA (Grover's algorithm provides a quadratic speedup, not an exponential one), the organisation made no assessment of its log integrity mechanisms against quantum threat models. More critically, the organisation had no plan to migrate to quantum-resistant hash functions (e.g., SHA-3, XMSS) if SHA-256's effective security proved insufficient. Consequence: Regulatory evidence challenged, compliance certifications at risk, inability to prove historical trading patterns to auditors.

Scenario C — PQC Migration Breaks Agent-Protocol Interoperability: An Ethereum Layer 2 protocol announces support for NIST PQC standard signatures (ML-DSA, formerly CRYSTALS-Dilithium) alongside existing ECDSA. The organisation migrates its AI agent's wallet to ML-DSA keys. However, 60% of the DeFi protocols the agent interacts with only validate ECDSA signatures. The agent cannot execute trades on these protocols with its new PQC keys. The organisation must maintain dual signing capability — ECDSA for backward compatibility, ML-DSA for PQC readiness — creating operational complexity and a larger key-management attack surface.

What went wrong: The organisation migrated to PQC keys without assessing the interoperability landscape. No hybrid signing scheme (ECDSA + ML-DSA) was implemented. No phased migration plan accounted for the ecosystem's adoption curve. Consequence: 60% of trading venues inaccessible for 3 months during remediation, $1.2M in opportunity cost, dual key-management overhead increased incident probability.

4. Requirement Statement

Scope: This dimension applies to all AI agents that use cryptographic primitives for any purpose: wallet key management, transaction signing, session authentication, data encryption, log integrity, inter-agent communication, or identity verification. This includes agents on all blockchain networks (Bitcoin, Ethereum, Solana, Cosmos, Polkadot, and all Layer 2 / sidechain networks), agents using off-chain cryptographic operations (TLS, SSH, encrypted storage), and agents whose audit logs use cryptographic integrity mechanisms. The scope extends to any system component that the agent depends upon for cryptographic security — including HSMs, key management services, and certificate authorities. Agents that use no cryptographic operations (a theoretical edge case in blockchain environments) are excluded.

4.1. A conforming system MUST maintain a cryptographic inventory that catalogues every cryptographic algorithm, key type, key length, and protocol used by the agent or its infrastructure, including: wallet key algorithms, transaction signing schemes, hash functions for log integrity, encryption algorithms for data at rest and in transit, and authentication mechanisms for inter-agent and agent-infrastructure communication.

4.2. A conforming system MUST assess each entry in the cryptographic inventory against known post-quantum threat models, classifying each as: quantum-safe (no known quantum attack), quantum-vulnerable (vulnerable to Shor's or Grover's algorithm), or quantum-uncertain (security reduction under quantum attack but not broken), with documented justification for each classification.

4.3. A conforming system MUST define a migration-readiness plan for each quantum-vulnerable cryptographic primitive, specifying: the target post-quantum algorithm (from NIST PQC standards: ML-KEM, ML-DSA, SLH-DSA, or equivalent), the migration trigger conditions, the migration procedure, the rollback procedure, and the estimated migration timeline.

4.4. A conforming system MUST implement algorithm-agnostic key management that can generate, store, and use keys for both current (ECDSA, EdDSA) and post-quantum (ML-DSA, SLH-DSA) algorithms without requiring architectural changes to the key management infrastructure.

4.5. A conforming system MUST minimise public key exposure for quantum-vulnerable key types by implementing address rotation strategies: where technically feasible, each address SHOULD be used for receiving only, with funds moved to a fresh address before the receiving address's public key is revealed through an outbound transaction.

4.6. A conforming system MUST monitor quantum computing development milestones and update the migration-readiness plan within 90 days of any milestone that materially changes the threat timeline (e.g., demonstration of Shor's algorithm on a system with >1,000 logical qubits, NIST PQC standard finalisation, major blockchain protocol announcing PQC support).

4.7. A conforming system SHOULD implement hybrid cryptographic schemes that use both a classical algorithm and a post-quantum algorithm for critical operations (e.g., dual-signing transactions with ECDSA + ML-DSA), providing security against both classical and quantum adversaries.

4.8. A conforming system SHOULD use quantum-resistant hash functions (SHA-3 or SHAKE) for new deployments of log integrity mechanisms, even though SHA-256 remains secure against known quantum attacks, as a defence-in-depth measure.

4.9. A conforming system SHOULD participate in blockchain ecosystem PQC readiness initiatives (e.g., Ethereum PQC working groups, Bitcoin quantum-resistance proposals) to ensure migration plans align with ecosystem timelines.

4.10. A conforming system MAY implement lattice-based or hash-based signature verification capabilities in advance of ecosystem-wide adoption, to be prepared for rapid migration when trigger conditions are met.

5. Rationale

The cryptographic foundations of virtually all blockchain networks — ECDSA on secp256k1 (Bitcoin, Ethereum), EdDSA on Ed25519 (Solana, Cosmos), and RSA (used in some infrastructure components) — are vulnerable to quantum attack via Shor's algorithm. A cryptographically relevant quantum computer (CRQC) running Shor's algorithm can derive a private key from a public key in polynomial time, breaking the fundamental security assumption of every current blockchain.

The timeline for CRQC availability is uncertain but the range of serious estimates (2030-2040) falls within the operational lifetime of most institutional crypto deployments being built today. More critically, the "harvest now, decrypt later" (HNDL) threat means that the window for action is not "when CRQC arrives" but "before quantum-vulnerable public keys are exposed." Every Bitcoin transaction that reveals a public key, every Ethereum transaction signature, and every TLS handshake that uses ECDH key exchange is a data point that a patient adversary can store and attack retroactively.

For AI agents managing substantial crypto assets, the quantum threat creates a unique governance challenge. The agent must operate with current cryptographic primitives (because the blockchain ecosystem has not yet migrated to PQC) while preparing for a migration that will require coordinated changes across wallets, signing infrastructure, protocol interactions, and audit mechanisms. This is not a traditional "upgrade when available" scenario — it requires proactive inventory management, migration planning, and risk mitigation even in the pre-CRQC period.

The cryptographic agility requirement is the core architectural response. Systems built with hard-coded cryptographic algorithms will require complete re-engineering when PQC migration becomes necessary. Systems built with algorithm-agnostic key management can migrate by changing configuration rather than architecture. The cost differential is enormous: a hard-coded system may require 12-18 months of re-engineering at a cost of $2M-$5M; an agile system may require 2-4 weeks of configuration changes at a cost of $50,000-$100,000.

NIST finalised its first post-quantum cryptographic standards in August 2024: ML-KEM (Module-Lattice-Based Key-Encapsulation Mechanism, formerly CRYSTALS-Kyber) for key encapsulation, ML-DSA (Module-Lattice-Based Digital Signature Algorithm, formerly CRYSTALS-Dilithium) for digital signatures, and SLH-DSA (Stateless Hash-Based Digital Signature Algorithm, formerly SPHINCS+) for hash-based signatures. These standards provide the migration targets. The blockchain ecosystem is beginning to integrate them — Ethereum's PQC working group is evaluating signature scheme changes, and several L2 protocols are experimenting with PQC-compatible account abstraction.

6. Implementation Guidance

Post-quantum cryptographic agility is an architectural property that must be designed in, not bolted on. The implementation guidance addresses the pre-migration period (now), the migration transition, and the post-migration steady state.

Recommended patterns:

• Cryptographic abstraction layer. Implement all cryptographic operations through an abstraction layer that exposes function-level interfaces (sign, verify, encrypt, decrypt, hash) without binding to specific algorithms. The abstraction layer maps each operation to the configured algorithm via a policy file. Changing the algorithm requires changing the policy — not the application code. Example: the sign(message, key) function currently resolves to ECDSA secp256k1 for Ethereum operations; post-migration, it resolves to ML-DSA-65 or a hybrid ECDSA+ML-DSA scheme. The calling code does not change.
• UTXO-style address hygiene for account-based chains. Even on account-based chains (Ethereum), minimise public key exposure by using a fresh address for each significant receiving operation. When the address is used for an outbound transaction (revealing the public key), migrate remaining funds to a new address. This is operationally costly on Ethereum (gas for transfers) but limits the quantum attack surface. For a wallet holding $10M, spending $500/month in gas for address rotation is justified. Prioritise rotation for wallets with balances exceeding a configurable threshold (e.g., $100,000).
• Hybrid signing for high-value operations. For transactions exceeding a configurable value threshold (e.g., $100,000), implement a secondary off-chain ML-DSA signature that is stored alongside the on-chain ECDSA signature. While the blockchain cannot verify the ML-DSA signature natively (until PQC is adopted), the off-chain signature provides quantum-resistant proof of intent that survives CRQC arrival. This proof can support dispute resolution, insurance claims, and regulatory evidence even after ECDSA is broken.
• Quantum milestone monitoring service. Maintain a monitoring service that tracks quantum computing publications, NIST updates, and blockchain ecosystem PQC announcements. Define trigger thresholds: Level 1 (awareness) — published demonstration of Shor's algorithm on >100 logical qubits; Level 2 (preparation) — published demonstration on >1,000 logical qubits or major blockchain protocol announces PQC timeline; Level 3 (urgency) — published demonstration on >4,000 logical qubits or ECDSA secp256k1 is broken in a laboratory setting. Each level triggers predefined migration-readiness actions.
• HSM PQC readiness verification. Verify that hardware security modules used for agent key management support (or have a firmware upgrade path to support) NIST PQC algorithms. If the current HSM does not support PQC and the vendor has no published roadmap, plan for HSM replacement. HSM procurement and deployment cycles are 6-12 months — this must be factored into migration timelines.

Anti-patterns to avoid:

• Assuming "quantum is decades away" without documented assessment. The timeline is uncertain, but dismissing the threat without a formal, documented assessment is itself a governance failure. The assessment must be evidence-based, citing current quantum computing capabilities, projected timelines, and the specific vulnerability of each cryptographic primitive in use.
• Waiting for blockchain-level PQC adoption before taking any action. Blockchain-level PQC adoption (e.g., Ethereum changing its signature scheme) will take years of research, testing, and coordinated deployment. Organisations cannot wait for this. Pre-migration hygiene (address rotation, cryptographic inventory, algorithm-agnostic architecture) should be implemented now.
• Hard-coding cryptographic algorithms in agent logic. An agent that calls secp256k1_sign() directly, rather than through an abstraction layer, will require code changes across every signing operation when migration occurs. The number of code changes multiplied by the testing burden makes migration impractically expensive.
• Ignoring key sizes for PQC algorithms. PQC algorithms have significantly larger key and signature sizes than their classical counterparts. ML-DSA-65 public keys are 1,952 bytes (vs. 33 bytes for compressed ECDSA secp256k1). ML-DSA-65 signatures are 3,309 bytes (vs. 64 bytes for ECDSA). These size differences affect storage, bandwidth, gas costs, and transaction throughput. Migration plans must account for the operational impact of increased sizes.
• Treating PQC migration as a one-time event. Cryptographic agility is a continuous capability, not a one-time migration. New quantum attacks, new classical attacks, and new algorithm standards will emerge. The architecture must support ongoing algorithm rotation, not just a single ECDSA-to-ML-DSA migration.

Industry Considerations

Bitcoin Ecosystem. Bitcoin's UTXO model provides natural public key exposure minimisation — public keys are only revealed when UTXOs are spent. However, Bitcoin addresses that have been spent from (revealing the public key) and still hold balance are quantum-vulnerable. AI agents managing Bitcoin wallets should prioritise spending UTXOs from addresses with unrevealed public keys and consolidating change to fresh addresses.

Ethereum Ecosystem. Ethereum's account model means that once an account signs a transaction, its public key is permanently revealed. ERC-4337 account abstraction provides a path to PQC-compatible accounts by allowing custom signature verification logic — enabling ML-DSA or hybrid schemes at the account level without a protocol-level change. AI agents should explore ERC-4337-based PQC readiness.

Institutional Custody. Custody providers face fiduciary obligations to protect client assets against foreseeable threats. As quantum computing advances become more credible, failure to implement PQC readiness measures may constitute breach of fiduciary duty. Insurance underwriters are beginning to ask about PQC preparedness in custody insurance applications.

Maturity Model

Basic Implementation — A cryptographic inventory exists documenting all algorithms, key types, and protocols in use. Each entry is classified against post-quantum threat models. A narrative migration-readiness plan exists identifying target algorithms and approximate timelines. Address rotation is performed manually for high-value wallets. Quantum milestone monitoring is informal.

Intermediate Implementation — Algorithm-agnostic key management is implemented via a cryptographic abstraction layer. Automated address rotation is operational for wallets above the configured value threshold. Hybrid signing (ECDSA + ML-DSA off-chain) is implemented for high-value transactions. HSM PQC readiness has been assessed and upgrade plans are documented. Quantum milestone monitoring is systematic with defined trigger levels. The migration-readiness plan includes detailed procedures, rollback plans, and interoperability assessments.

Advanced Implementation — All intermediate capabilities plus: hybrid on-chain signing is operational where the blockchain supports it (e.g., via ERC-4337). PQC key generation and management have been tested end-to-end in a staging environment. Independent adversarial testing has verified that the migration procedure works without asset loss or operational disruption. The organisation participates in blockchain ecosystem PQC working groups. Cryptographic agility supports ongoing algorithm rotation, not just a single migration. Post-quantum hash functions (SHA-3) are used for new log integrity deployments.

7. Evidence Requirements

Required artefacts:

• Cryptographic inventory. Complete catalogue of all cryptographic algorithms, key types, key lengths, and protocols in use, with post-quantum threat classification for each entry. Format: structured data (JSON/YAML/spreadsheet). Updated at least annually or within 90 days of any infrastructure change.
• Post-quantum risk assessment. Documented assessment of quantum threat timeline, organisation-specific risk exposure (value of quantum-vulnerable assets, public key exposure count), and risk mitigation measures. Updated annually.
• Migration-readiness plan. Detailed plan specifying target algorithms, trigger conditions, migration procedures, rollback procedures, interoperability assessment, and estimated timeline. Updated within 90 days of any quantum milestone or NIST standard update.
• Address rotation records. Records of address rotation activities including: original address, new address, amount transferred, rotation reason, and public key exposure status. Minimum 12 months retention.
• Quantum milestone monitoring records. Records of monitored milestones, their classification against trigger levels, and any actions taken in response. Minimum 12 months retention.

Retention requirements:

• Cryptographic inventory and risk assessments: minimum 7 years for regulated financial services; minimum 5 years for other regulated sectors; minimum 3 years otherwise.

Access requirements:

• Producible to regulators or auditors within 48 hours of request. The cryptographic inventory must be current as of the request date.

8. Test Specification

Test 8.1: Cryptographic Inventory Completeness

• Stimulus: Conduct an independent audit of all cryptographic operations in the agent's codebase and infrastructure. Compare against the declared cryptographic inventory.
• Expected behaviour: Every cryptographic algorithm, key type, and protocol identified by the audit is present in the inventory.
• Pass criteria: No undocumented cryptographic primitive is found. The inventory is complete and current.
• Fail criteria: Any cryptographic primitive in active use is missing from the inventory.

Test 8.2: Post-Quantum Classification Accuracy

• Stimulus: Review the post-quantum threat classification for each inventory entry against current NIST guidance and published quantum computing research.
• Expected behaviour: Each classification is accurate and supported by documented justification.
• Pass criteria: No misclassification — quantum-vulnerable primitives are correctly identified; quantum-safe primitives are correctly justified.
• Fail criteria: Any primitive is misclassified (e.g., ECDSA secp256k1 classified as quantum-safe).

Test 8.3: Algorithm-Agnostic Key Management

• Stimulus: Reconfigure the cryptographic abstraction layer to use a different signing algorithm (e.g., switch from ECDSA secp256k1 to ML-DSA-65) in a test environment. Execute standard agent operations.
• Expected behaviour: Agent operations execute successfully with the new algorithm. No application code changes are required — only configuration changes.
• Pass criteria: Algorithm switch is accomplished via configuration change only. All operations succeed with the new algorithm.
• Fail criteria: Algorithm switch requires code changes, or operations fail after the switch.

Test 8.4: Address Rotation Effectiveness

• Stimulus: Verify that wallets above the configured value threshold have been rotated according to the defined schedule. Check that public keys are not exposed for current high-value addresses.
• Expected behaviour: All high-value wallets comply with the rotation schedule. No high-value address has an exposed public key (i.e., has not been used for outbound transactions since last rotation).
• Pass criteria: Rotation compliance is 100% for wallets above threshold. No high-value address has unnecessary public key exposure.
• Fail criteria: Any high-value wallet is non-compliant with the rotation schedule.

Test 8.5: Hybrid Signing Verification

• Stimulus: For a transaction exceeding the hybrid-signing threshold, verify that both an ECDSA signature (on-chain) and an ML-DSA signature (off-chain) are produced and stored.
• Expected behaviour: Both signatures are present, valid, and stored with the transaction record.
• Pass criteria: Both signatures verify successfully against the transaction data.
• Fail criteria: Either signature is missing, invalid, or does not match the transaction data.

Test 8.6: Migration Procedure Dry Run

• Stimulus: Execute the migration-readiness plan in a staging environment that mirrors production. Migrate wallet keys, signing infrastructure, and log integrity mechanisms from classical to PQC algorithms.
• Expected behaviour: Migration completes without asset loss, operational disruption, or interoperability failure. Rollback to classical algorithms succeeds.
• Pass criteria: Migration and rollback both succeed. No asset loss. No data corruption. Operational continuity maintained.
• Fail criteria: Migration or rollback fails, causes asset loss, data corruption, or operational disruption.

Test 8.7: Quantum Milestone Response

• Stimulus: Simulate a Level 2 quantum milestone trigger (e.g., announcement of Shor's algorithm demonstrated on >1,000 logical qubits). Verify that the defined response actions are initiated.
• Expected behaviour: The migration-readiness plan is updated within the specified timeline (90 days). Defined Level 2 actions are initiated (e.g., accelerating hybrid signing deployment, HSM upgrade procurement).
• Pass criteria: Response actions are initiated within the specified timeline. Plan update is completed and documented.
• Fail criteria: No response to the milestone, or response exceeds the specified timeline.

Test 8.8: PQC Key Size Impact Assessment

• Stimulus: Execute a representative transaction workload using PQC algorithms in a test environment. Measure: storage overhead, bandwidth overhead, gas cost increase, and transaction throughput impact.
• Expected behaviour: Impact metrics are within documented acceptable ranges. If impact exceeds acceptable ranges, mitigation strategies are documented.
• Pass criteria: Impact is measured and documented. If impact exceeds acceptable ranges, mitigation strategies are defined.
• Fail criteria: No impact assessment exists, or impact exceeds acceptable ranges without mitigation.

Conformance Scoring

• Score 0: No cryptographic inventory or post-quantum assessment exists. The organisation has not considered quantum threats to its cryptographic operations.
• Score 1: A cryptographic inventory exists with post-quantum classifications. A narrative migration plan exists. No algorithm-agnostic architecture. No address rotation. No hybrid signing.
• Score 2: Algorithm-agnostic key management is implemented. Automated address rotation is operational. Hybrid signing is deployed for high-value transactions. HSM PQC readiness is assessed. Quantum milestone monitoring is systematic. Migration procedures have been tested in a staging environment.
• Score 3: Verified by independent assessment including inventory audit, migration dry run, and PQC key-size impact testing. Hybrid on-chain signing is operational where ecosystem supports it. The organisation actively participates in ecosystem PQC working groups. Cryptographic agility supports continuous algorithm rotation.

9. Regulatory Mapping

Regulation	Provision	Relationship Type
EU AI Act	Article 9 (Risk Management System)	Supports compliance
DORA	Article 9 (ICT Risk Management Framework)	Direct requirement
NIST SP 800-208	Recommendation for Stateful Hash-Based Signature Schemes	Direct guidance
NIST FIPS 203, 204, 205	Post-Quantum Cryptographic Standards (ML-KEM, ML-DSA, SLH-DSA)	Direct guidance
CNSA 2.0	NSA Commercial National Security Algorithm Suite 2.0	Analogous requirement
MiCA	Article 68 (Prudential Requirements)	Supports compliance
FCA SYSC	6.1.1R (Systems and Controls)	Supports compliance

DORA — Article 9 (ICT Risk Management Framework)

DORA requires financial entities to "identify, classify and adequately document all ICT-related business functions, roles, responsibilities, assets and dependencies" and to "identify all sources of ICT risk." Post-quantum cryptographic vulnerability is an ICT risk source. The cryptographic inventory required by AG-208 directly satisfies DORA's asset documentation requirement for cryptographic infrastructure. The migration-readiness plan satisfies DORA's requirement for risk mitigation measures. DORA's 2025 implementation timeline means that financial entities must already be documenting their cryptographic posture — including quantum vulnerability assessment.

NIST FIPS 203, 204, 205 (Post-Quantum Cryptographic Standards)

NIST finalised the first three PQC standards in August 2024: FIPS 203 (ML-KEM for key encapsulation), FIPS 204 (ML-DSA for digital signatures), and FIPS 205 (SLH-DSA for hash-based signatures). These standards provide the migration targets for AG-208's migration-readiness plan. Federal agencies and their contractors are required to begin transitioning to these standards. Private sector organisations, while not directly mandated, face increasing regulatory and market pressure to adopt NIST PQC standards — particularly in financial services where DORA, MiCA, and prudential requirements demand demonstrable cryptographic resilience.

CNSA 2.0 (NSA Commercial National Security Algorithm Suite 2.0)

The NSA's CNSA 2.0 guidance mandates that National Security Systems transition to quantum-resistant algorithms by 2033 for software signing and by 2035 for all other uses. While targeted at US government systems, CNSA 2.0 sets the timeline benchmark for the broader industry. Organisations that serve government clients or operate in national security-adjacent domains should align their AG-208 migration timelines with CNSA 2.0 deadlines.

MiCA — Article 68 (Prudential Requirements)

MiCA's prudential requirements for CASPs include maintaining adequate ICT systems and controls. As quantum threats to cryptographic asset security become more widely recognised by regulators, CASPs that cannot demonstrate PQC readiness may face prudential findings. AG-208 provides the structured framework for demonstrating cryptographic resilience to MiCA regulators.

10. Failure Severity

Field	Value
Severity Rating	Critical
Blast Radius	Organisation-wide — potentially all cryptographically secured assets and evidence

Consequence chain: Failure to implement post-quantum cryptographic agility creates two categories of consequence. First, existential financial risk: when CRQC arrives, every wallet secured by quantum-vulnerable keys is exposed to private key extraction. The total value at risk equals the sum of all assets held in quantum-vulnerable wallets — for institutional custody operations, this can be hundreds of millions to billions of dollars. Second, evidentiary collapse: audit logs, compliance records, and attribution chains secured by quantum-vulnerable hash functions or signatures become unreliable once quantum attacks on those primitives become feasible. The organisation may lose the ability to demonstrate historical compliance, defend against regulatory actions, or prove the integrity of its trading records. The unique characteristic of this threat is its time horizon — the mitigation must begin years before the threat materialises, because the "harvest now, decrypt later" attack means that data exposed today is vulnerable to future quantum attack. Organisations that begin PQC readiness after CRQC arrives will have zero migration time for already-exposed keys.

Cross-references: AG-016 (Cryptographic Action Attribution) relies on cryptographic primitives that AG-208 protects against quantum threats — if attribution signatures are quantum-vulnerable, action attribution becomes unreliable when CRQC arrives. AG-001 (Operational Boundary Enforcement) ensures that PQC migration actions operate within mandated boundaries. AG-011 (Action Reversibility and Settlement Integrity) addresses the irreversibility of blockchain transactions that makes pre-CRQC key protection critical. AG-070 (Emergency Kill-Switch and Global Disable) provides emergency halt capability if a quantum key-extraction attack is detected in the wild. AG-207 (Long-Running Wallet Session and Resume Reauthorisation Governance) addresses session key cryptographic strength, which AG-208 extends to PQC readiness. AG-204 (Post-Settlement Reconciliation and Recovery Governance) relies on log integrity that AG-208 protects against quantum-era attacks. AG-209 (Travel Rule Payload Integrity and Transfer Matching Governance) depends on cryptographic integrity that AG-208 ensures remains quantum-resilient. Sibling dimensions AG-193 through AG-218 collectively govern the Crypto / Web3 landscape.