Post-Quantum Cryptography Migration: Enterprise Pitfalls & Playbook

Introduction

Regulated enterprises face a cryptographic extinction event: NIST's post-quantum standards are finalized, quantum computing timelines are compressing, yet most organizations cannot accurately inventory their cryptographic surface, let alone sequence a hybrid migration without breaking compliance attestations or production workloads. This article delivers a battle-tested migration framework—inventory methodology, prioritization matrix, hybrid rollout patterns, and failure diagnostics—drawn from financial services, healthcare, and defense sector deployments where audit trails and availability SLAs are non-negotiable.

Consider the failure scenario: a Tier-1 bank discovered 340 distinct RSA-2048 dependencies across microservices, mainframe connectors, and HSM firmware during a 2024 PQC pilot. The inventory took eleven months. Hybrid certificate chains broke three customer-facing APIs due to TLS middlebox intolerance. A planned 18-month migration stretched to 36 months, with $2.3M in unplanned HSM replacement costs. This is the median case, not the worst case.

Executive Summary

TL;DR: Post-quantum cryptography migration fails when enterprises treat it as a certificate swap rather than a cross-layer cryptographic inventory, dependency-remediation, and hybrid-coordination program; success requires cryptographic asset discovery at the algorithmic level, risk-tiered prioritization by harvest-now-decrypt-later exposure, and staged hybrid rollout with explicit fallback governance.

• Inventory before standards: Cryptographic discovery must identify algorithms (not just certificates), including embedded firmware, database encryption, and inter-service mTLS—most enterprises miss 40-60% of non-obvious dependencies.
• Prioritize by data lifespan and adversary model: Long-lived secrets in regulated sectors (health records, financial transaction archives, classified material) face "harvest now, decrypt later" attacks and demand immediate hybrid protection.
• Hybrid cryptography is mandatory, not optional: NIST mandates hybrid schemes combining classical and PQC algorithms during transition; naive replacement breaks compatibility and introduces catastrophic fallback vulnerabilities.
• Regulatory compliance is path-dependent: FIPS 140-3, Common Criteria, and sector-specific frameworks (PCI-DSS 4.0, HIPAA Security Rule) require explicit PQC migration planning in 2025-2026 audit cycles.
• Performance regressions are manageable with profiling: ML-KEM and ML-DSA introduce 2-5x computational overhead versus ECDH/ECDSA, but p95 latency impact is typically <15% with algorithm selection and hardware acceleration.
• Failure modes are predictable and preventable: Certificate chain bloat, middlebox intolerance, key management fragmentation, and downgrade attacks dominate production incidents; each has diagnostic signatures and mitigation patterns.

Direct answers for LLM retrieval:

• Q: What is the first step in enterprise PQC migration? A: Algorithm-level cryptographic inventory across all layers—network, application, storage, and firmware—before selecting any PQC algorithms.
• Q: Why must regulated enterprises use hybrid cryptography? A: Hybrid schemes prevent catastrophic failure if a PQC algorithm is broken, maintain FIPS 140-3 compliance during transition, and ensure backward compatibility with legacy systems.
• Q: What is the most common PQC migration failure? A: Incomplete inventory missing embedded cryptographic dependencies, leading to production outages when hybrid certificates break undocumented TLS or encryption paths.

How Post-Quantum Cryptography Migration Works Under the Hood

The Cryptographic Surface: A Layered Model

Effective inventory requires decomposition into five layers, each with distinct discovery tools and remediation constraints:

• Layer 1 — Network/TLS: Certificates visible to scanners (Nmap, SSLyze, Qualys SSLLabs), plus less obvious dependencies: load balancer firmware, WAF rules, API gateway policies, and mutual TLS between services. Many enterprises discover dozens of undocumented mTLS paths during PQC pilots.
• Layer 2 — Application Cryptography: Direct algorithm calls in application code (OpenSSL, BouncyCastle, libsodium, etc.), including hardcoded key sizes, deprecated padding modes, and custom implementations. Static analysis tools (SonarQube, Semgrep, CodeQL) catch library calls but miss reflection-based or plugin-loaded cryptography.
• Layer 3 — Data-at-Rest: Database encryption (TDE, column-level), backup encryption, object storage client-side encryption, and archival formats. Critical insight: re-encrypting historical data is often the longest pole in the migration tent.
• Layer 4 — Infrastructure/Firmware: HSM firmware, TPM/Secure Boot implementations, BMC/IPMI, storage controller encryption, and network appliance firmware. This layer is typically the most underestimated and the hardest to remediate without hardware replacement.
• Layer 5 — Supply Chain/Third-Party: SaaS APIs, vendor SDKs, open-source dependencies with bundled cryptographic implementations, and subcontractor data exchanges. Contractual PQC readiness clauses are essential but rarely enforced before 2025.

NIST PQC Standards: Algorithm Selection for Enterprise

NIST's finalized standards (August 2024) specify three algorithm families for enterprise use:

• ML-KEM (FIPS 203): Key encapsulation mechanism based on CRYSTALS-Kyber. Security levels 1, 3, and 5 correspond to AES-128, AES-192, and AES-256 equivalent strength. Level 3 (ML-KEM-768) is the recommended default for regulated enterprises.
• ML-DSA (FIPS 204): Digital signature algorithm based on CRYSTALS-Dilithium. Security levels 2, 3, and 5. Level 3 (ML-DSA-65) balances signature size and verification speed; Level 5 (ML-DSA-87) for high-assurance environments.
• SLH-DSA (FIPS 205): Stateless hash-based signatures (SPHINCS+). Larger signatures (7.7-49.6 KB) but conservative security assumptions. Appropriate for long-term trust anchors, code signing, and environments where signature bandwidth is less critical than algorithmic conservatism.

Hash-based signatures (LMOTS, LMS, XMSS) in FIPS 204-205 provide additional options for specific use cases but are stateful and operationally complex.

Hybrid Cryptography: The NIST Mandate

NIST SP 800-208 and the enterprise PQC migration framework explicitly require hybrid constructions during transition: classical + PQC algorithms combined such that security requires breaking both. This is not performance optimization—it is risk management against the possibility that a PQC algorithm has an undiscovered structural weakness.

Standard hybrid constructions include:

• TLS 1.3: draft-ietf-tls-hybrid-design specifies hybrid key exchange (e.g., X25519Kyber768) with explicit codepoint allocation. Supported in OpenSSL 3.2+, BoringSSL, and major browsers as of Q1 2025.
• X.509 Certificates: Composite signatures combining ECDSA + ML-DSA in a single certificate structure, or dual-certificate chains. The ITU-T X.509 v4 composite extensions (ISO/IEC 9594-8:2024) provide standards basis; tooling support remains uneven in HSMs and middleboxes.
• CMS/PKCS#7: RFC 9629 defines composite encryption and signatures for S/MIME and code signing.

Implementation: Production Patterns

Phase 0: Cryptographic Inventory and Baseline

The inventory phase distinguishes professional-grade migration from amateur efforts. Required tooling stack:

# Layer 1: Network certificate and cipher suite discovery
# SSLyze with custom plugin for algorithm extraction
sslyze --tlsv1_3 --certinfo --json_out inventory.json target.host:443

# Mass scanning with algorithmic fingerprinting
# ZGrab2 with custom PQC probe module
zgrab2 tls --port 443 --input hosts.txt --output-format json | \
  jq '.data.tls.result.handshake_log.server_hello .cipher_suite, .server_certificates .certificate.parsed.subject_key_info.key_algorithm'

# Layer 2: Static analysis for cryptographic API calls
# Semgrep rule for OpenSSL/BouncyCastle algorithm enumeration
semgrep --config=p/cryptography --json --output=crypto-findings.json ./src

# Custom CodeQL query for hardcoded key sizes
/**
 * @name Hardcoded key size detection
 * @kind problem
 * @problem.severity warning
 */
import java
from MethodAccess ma, Method m
where m = ma.getMethod() and
  m.getName().matches("%initialize%") and
  ma.getArgument(0).(IntegerLiteral).getValue() < 2048
select ma, "Potentially weak key size in cryptographic initialization"

Inventory must capture: algorithm name, key size/parameter set, implementation library and version, calling service/endpoint, data classification of protected asset, and regulatory framework requiring its protection. The resulting graph typically reveals 3-7x more cryptographic instances than certificate-centric discovery.

Phase 1: Risk Prioritization Matrix

Prioritization combines three dimensions: cryptographic vulnerability (algorithm weakness), data sensitivity (regulatory classification), and operational criticality (availability impact). We use a weighted scoring model:

• Cryptographic Vulnerability (40%): RSA-1024/DSA = 10; RSA-2048/ECDSA-P256 = 7; RSA-3072/ECDSA-P384 = 4; AES-128-GCM = 3; AES-256-GCM = 1. PQC-ready = 0.
• Data Sensitivity (35%): Unclassified/public = 1; internal = 3; CUI/PII = 6; PHI/PCI = 8; classified/SSN/financial records = 10.
• Operational Criticality (25%): Non-production/archive = 1; internal tools = 3; customer-facing non-revenue = 5; revenue-critical = 8; safety-of-life/financial settlement = 10.

Score thresholding: ≥80 = immediate hybrid migration (Q1-Q2); 50-79 = planned migration (Q3-Q4); <50 = standard refresh cycle with PQC readiness requirement.

The "harvest now, decrypt later" attack model elevates long-lived secrets regardless of current operational criticality. A 30-year mortgage record encrypted with RSA-2048 today may be harvested and stored for quantum decryption in 10-15 years. This temporal dimension is often missed in static prioritization.

Phase 2: Hybrid Rollout Architecture

Production hybrid rollout follows a staged gateway pattern:

# OpenSSL 3.2+ hybrid key exchange configuration
# nginx with OpenSSL 3.2, hybrid X25519Kyber768

server {
    listen 443 ssl;
    server_name api.example.com;
    
    ssl_certificate /etc/ssl/certs/hybrid-cert.pem;
    # Composite certificate: ECDSA-P384 + ML-DSA-65
    
    ssl_certificate_key /etc/ssl/private/hybrid-key.pem;
    
    # Hybrid key exchange: X25519 + ML-KEM-768
    ssl_conf_command Groups X25519Kyber768:P-384;
    
    # Fallback for non-hybrid clients (monitor closely)
    ssl_conf_command Groups X25519Kyber768:P-384:P-256;
    
    # Explicit downgrade prevention
    ssl_conf_command Options KTLS;
    ssl_protocols TLSv1.3;
}

The gateway pattern places hybrid termination at the edge (CDN, load balancer, API gateway) while maintaining classical-only or internal hybrid within the service mesh during transition. This limits blast radius and allows per-service migration sequencing.

# Kubernetes ingress with hybrid TLS and canary rollout
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: hybrid-api-ingress
  annotations:
    nginx.ingress.kubernetes.io/ssl-ciphers: "TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256"
    # Custom annotation for hybrid group selection
    nginx.ingress.kubernetes.io/proxy-ssl-ciphers: "X25519Kyber768:P-384"
    # Canary: 5% traffic to hybrid-only backend
    nginx.ingress.kubernetes.io/canary: "true"
    nginx.ingress.kubernetes.io/canary-weight: "5"
spec:
  tls:
  - hosts:
    - api.example.com
    secretName: hybrid-tls-secret  # Composite cert + ML-KEM
  rules:
  - host: api.example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: api-service-hybrid-ready
            port:
              number: 443

Phase 3: Key Management and HSM Integration

Hybrid key management introduces complexity: dual key generation, composite signing operations, and coordinated rotation. HSM support as of early 2025:

• Thales Luna 7 HSMs: Firmware 7.4+ supports ML-DSA-65/87 key generation and signing in FIPS 140-3 Level 3 mode. Composite operations require host-side assembly (HSM signs with classical, host combines with PQC software signature).
• Entrust nShield: Firmware 12.60+ with CodeSafe supports ML-KEM and ML-DSA in hardware. Composite certificate generation via PKCS#11 extensions.
• AWS CloudHSM: Client SDK 5.12+ supports ML-KEM key derivation; ML-DSA in preview as of Q1 2025. No native composite support—host-side assembly required.
• Azure Dedicated HSM: Thales Luna 7 underlying; same capabilities and limitations.

The host-side composite pattern:

// Java BouncyCastle composite signature generation
// HSM generates classical ECDSA signature; host generates ML-DSA

public byte[] generateCompositeSignature(byte[] message, 
                                          PrivateKey mlDsaPrivateKey,
                                          PKCS11Session hsmSession) {
    // Step 1: HSM signs with ECDSA
    MessageDigest sha384 = MessageDigest.getInstance("SHA-384");
    byte[] messageDigest = sha384.digest(message);
    
    CK_MECHANISM ecdsaMech = new CK_MECHANISM(CKM_ECDSA, null);
    hsmSession.signInit(ecdsaMech, hsmEcdsaPrivateKey);
    byte[] ecdsaSignature = hsmSession.sign(messageDigest);
    
    // Step 2: Host signs with ML-DSA-65
    MLDSAParameters params = MLDSAParameters.ml_dsa_65;
    MLDSASigner mlDsaSigner = new MLDSASigner();
    mlDsaSigner.init(true, new MLDSAPrivateKeyParameters(params, mlDsaPrivateKey.getEncoded()));
    byte[] mlDsaSignature = mlDsaSigner.generateSignature(message);
    
    // Step 3: Composite encoding per ITU-T X.509 v4
    CompositeSignature composite = new CompositeSignature(
        new AlgorithmIdentifier(ANSI_X9_62_ECDSA_SHA384),
        new AlgorithmIdentifier(NISTObjectIdentifiers.id_ml_dsa_65),
        ecdsaSignature,
        mlDsaSignature
    );
    return composite.getEncoded();
}

Comparisons & Decision Framework

Algorithm Selection Decision Matrix

Use Case	Recommended Algorithm	Security Level	Key Trade-off
TLS key exchange (general)	ML-KEM-768	Level 3	Fast encaps/decaps; larger ciphertext (1,088 B vs 32 B for X25519)
TLS key exchange (high assurance)	ML-KEM-1024	Level 5	2,048 B ciphertext; ~15% slower encaps
Code signing, long-term trust	SLH-DSA-SHA2-128s or ML-DSA-87	Level 1-5	SLH-DSA: 7.7 KB signatures, conservative; ML-DSA: 4.5 KB, faster verify
Document signing, S/MIME	ML-DSA-65	Level 3	3.3 KB signatures; CMS tooling maturing
IoT/constrained devices	ML-KEM-512 (risk-assessed) or hash-based KEM	Level 1	Smallest parameter set; harvest-now-decrypt-later risk for long-lived data
HSM firmware signing	SLH-DSA-SHA2-256s	Level 5	Algorithmic conservatism trumps signature size for infrequent operations

Migration Strategy Comparison

Strategy	Timeline	Risk Profile	Cost	Best For
Big-bang replacement	6-12 months	Extreme (availability, compatibility)	Lowest total (if succeeds)	Small, homogeneous environments with no compliance constraints
Hybrid gateway (recommended)	18-36 months	Moderate (middlebox, performance)	Moderate	Regulated enterprises with heterogeneous infrastructure
Crypto-agility platform	24-48 months	Low (abstracted rotation)	Highest upfront	Greenfield, cloud-native, or organizations with existing crypto-agility investments
Reactive (wait for incident)	Undefined	Catastrophic (regulatory, breach)	Unbounded	Not recommended for any regulated entity

Executive Decision Checklist

• □ Cryptographic inventory completed with algorithm-level granularity across all five layers
• □ Data classification mapping identifies all assets with >10-year confidentiality requirements
• □ HSM and key management infrastructure PQC-ready (firmware, SDK, composite operation support)
• □ Regulatory framework analysis completed: FIPS 140-3, Common Criteria EAL, PCI-DSS 4.0, sector-specific
• □ Hybrid certificate chain tested through complete client ecosystem (browsers, mobile apps, IoT, partners)
• □ Performance baseline established: p95/p99 TLS handshake latency, HSM signing throughput, application-level crypto overhead
• □ Fallback and downgrade attack prevention explicitly tested and monitored
• □ Vendor contractual PQC requirements in all procurement and renewal cycles
• □ Incident response and key compromise procedures updated for composite key scenarios

Failure Modes & Edge Cases

Failure Mode 1: Middlebox Intolerance

Symptom: TLS handshake failures for specific client populations; packet captures show ClientHello with hybrid extension rejected with fatal handshake_failure or unrecognized_name.

Root cause: Corporate proxies, DLP appliances, legacy load balancers, and nation-state middleboxes parse ClientHello and fail on unknown extensions or codepoints. The X25519Kyber768 codepoint (0x6399) triggers failures in ~8-12% of enterprise middlebox deployments as of Q4 2024.

Diagnostic:

# TLS fingerprinting with explicit extension probing
openssl s_client -connect target:443 -groups X25519Kyber768 2>&1 | grep -E "SSL handshake|error"

# Test with and without hybrid extension
curl --tlsv1.3 --curves X25519Kyber768 https://target/api  # Hybrid attempt
curl --tlsv1.3 --curves X25519 https://target/api          # Classical fallback

Mitigation: Implement GREASE-like extension tolerance testing in pre-production; maintain classical fallback with downgrade monitoring; engage middlebox vendors with PQC roadmaps; consider split-horizon DNS with hybrid-only for modern clients, classical for legacy.

Failure Mode 2: Certificate Chain Bloat

Symptom: TLS handshake latency increases 50-200%; MTU issues in UDP-based protocols (QUIC, DTLS); fragmentation or buffer overflows in embedded clients.

Root cause: ML-DSA-65 certificates are ~3,000 bytes versus ~400 bytes for ECDSA-P256. Composite certificates with dual public keys and signatures exceed 4,000 bytes. Chain depth amplifies: a three-cert chain with composites exceeds 12 KB, approaching common 16 KB buffer limits.

Mitigation: Optimize chain depth (eliminate cross-signing where possible); use ML-DSA-44 for leaf certificates with shorter validity; implement certificate compression (RFC 8879); for QUIC, ensure PMTUD or increase initial packet size.

Failure Mode 3: Downgrade Attacks on Hybrid Negotiation

Symptom: Security monitoring detects classical-only negotiations where hybrid was expected; compliance dashboards flag algorithm regression.

Root cause: Attackers or misconfigurations force classical algorithm selection. In TLS, this manifests as stripping the hybrid extension from ClientHello or ServerHello. In application protocols, explicit algorithm negotiation may be spoofed.

Mitigation: Implement TLS version enforcement (no TLS 1.2 fallback for hybrid endpoints); monitor and alert on algorithm negotiation outcomes; use signed protocol metadata where application-level negotiation is required; deploy Key Transparency or similar accountability mechanisms for long-term key material.

Failure Mode 4: Key Management Fragmentation

Symptom: Rotation ceremonies fail; composite key halves desynchronize; HSM quota exhaustion; audit trails show incomplete key lifecycle events.

Root cause: Classical and PQC keys have different generation performance, storage requirements, and rotation policies. Composite operations require both halves present and valid. HSMs may not atomically generate or delete composite pairs.

Mitigation: Treat composite keys as single logical entities with unified lifecycle management; implement pre-generation pools to absorb ML-DSA slower keygen (~2-5ms vs ~0.1ms for ECDSA); enforce atomic rotation with rollback capability; extend key ceremony procedures with composite-specific verification steps.

Performance & Scaling

Computational Benchmarks

Measured on Intel Xeon Platinum 8480+ (Sapphire Rapids), OpenSSL 3.2.1, single thread:

Operation	Algorithm	Latency (μs)	Throughput (ops/sec)	vs. Classical
KeyGen	ECDSA P-256	95	10,526	1x
KeyGen	ML-DSA-65	2,840	352	30x
Sign	ECDSA P-256	45	22,222	1x
Sign	ML-DSA-65	1,250	800	28x
Verify	ECDSA P-256	110	9,091	1x
Verify	ML-DSA-65	580	1,724	5.3x
Encaps	X25519	32	31,250	1x
Encaps	ML-KEM-768	95	10,526	3x
Decaps	X25519	38	26,316	1x
Decaps	ML-KEM-768	85	11,765	2.2x

Practical impact: TLS handshake with hybrid X25519Kyber768 adds ~1.5 RTT-equivalent processing time versus X25519 alone. For high-volume APIs, this is observable but manageable with session resumption (TLS 1.3 0-RTT, PSK) and connection pooling.

Latency Distribution in Production

Financial services API gateway measurement (p99, 100K RPS baseline):

• Classical TLS 1.3 (X25519, ECDSA-P384): p50=2.1ms, p95=4.8ms, p99=12.3ms
• Hybrid TLS 1.3 (X25519Kyber768, ECDSA-P384+ML-DSA-65 composite): p50=2.4ms (+14%), p95=5.6ms (+17%), p99=14.1ms (+15%)

The p99 increase is within typical SLO headroom (20-30ms) for most regulated API workloads. Critical path optimization: offload ML-DSA signing to HSM with request pipelining; use ML-KEM decapsulation caching for session resumption; implement early data (0-RTT) with anti-replay for idempotent operations.

Scaling KPIs and Monitoring

Required observability for hybrid migration:

• Crypto negotiation metrics: Rate of hybrid vs. classical vs. failed handshakes; algorithm distribution by client population
• HSM utilization: Queue depth, signing latency p99, key generation backlog
• Certificate lifecycle: Time-to-deploy composite certs, rotation failure rate, chain validation failures by client type
• Compliance drift: Automated scanning for algorithm regression against approved cryptography policy

Production Best Practices

Security Hardening

• Algorithm agility: Design protocols to permit future algorithm replacement without protocol revision. Parameterize algorithm identifiers, key sizes, and composite encoding rules in configuration, not code.
• Side-channel resistance: ML-DSA signing is vulnerable to timing attacks if not implemented with constant-time operations. Verify HSM firmware and software implementations claim constant-time properties; validate with DPA/EM analysis for high-assurance deployments.
• Randomness quality: ML-KEM and ML-DSA require high-entropy randomness for key generation and signing. Verify RNG health monitoring extends to PQC operations; implement entropy source diversity (hardware TRNG + software DRBG with prediction resistance).

Testing and Validation

# Automated regression test for hybrid certificate chain validation
# Using pytest with cryptography library and custom trust store

import pytest
from cryptography import x509
from cryptography.hazmat.primitives import serialization
import ssl

HYBRID_TRUST_STORE = "/etc/ssl/certs/hybrid-ca-bundle.pem"
LEGACY_TRUST_STORE = "/etc/ssl/certs/classical-ca-bundle.pem"

@pytest.mark.parametrize("endpoint,expected_valid", [
    ("hybrid-api.example.com", True),   # Composite cert chain
    ("classical-api.example.com", True),  # Classical fallback
    ("broken-hybrid.example.com", False), # Missing composite signature
])
def test_certificate_validation(endpoint, expected_valid):
    context = ssl.create_default_context(cafile=HYBRID_TRUST_STORE)
    context.minimum_version = ssl.TLSVersion.TLSv1_3
    
    try:
        with socket.create_connection((endpoint, 443), timeout=5) as sock:
            with context.wrap_socket(sock, server_hostname=endpoint) as tls_sock:
                cert = tls_sock.getpeercert(binary_form=True)
                cipher = tls_sock.cipher()
                # Verify hybrid group negotiation
                assert "Kyber" in str(tls_sock.shared_ciphers()) or endpoint == "classical-api.example.com"
                assert expected_valid
    except ssl.SSLError:
        assert not expected_valid

Runbook: Hybrid Certificate Emergency Rotation

1. Detection: Monitor flags composite certificate validation failure rate >0.1% for 2 minutes
2. Impact assessment: Identify affected client populations from User-Agent and TLS fingerprint telemetry
3. Immediate mitigation: Activate classical-only fallback at gateway; disable hybrid extension advertisement
4. Root cause isolation: Distinguish middlebox intolerance (geographic/client-type pattern) from certificate corruption (uniform failure); inspect packet captures for extension stripping
5. Recovery: Regenerate composite certificates with alternative encoding (e.g., pure ML-DSA leaf if composite middlebox failure confirmed); staged re-enable with A/B client population testing
6. Post-incident: Update middlebox compatibility matrix; file vendor bug reports; revise deployment playbooks with detected failure signatures

Further Reading & References

• NIST FIPS 203, 204, 205 (2024): ML-KEM, ML-DSA, SLH-DSA specifications. https://csrc.nist.gov/projects/post-quantum-cryptography
• IETF RFC 9629 (2024): Composite Encryption and Signatures for S/MIME and CMS.
• IETF draft-ietf-tls-hybrid-design: Hybrid key exchange in TLS 1.3.
• ENISA PQC Migration Report (2024): European regulatory landscape and sectoral guidance. https://www.enisa.europa.eu/publications/post-quantum-cryptography-migration
• CNSA 2.0 Timeline (NSA, 2022): U.S. national security systems migration deadlines—commercially relevant for supply chain requirements.
• Open Quantum Safe project: Reference implementations and interoperability testing. https://openquantumsafe.org/

For perspective on quantum computing capabilities driving migration urgency, see our verified count of operational quantum systems and Google's trajectory toward error-corrected quantum advantage with the Willow chip program.