Crypto-Agility: Enterprise Post-Quantum Strategy

Crypto-Agility: The Capability That Will Define Post-Quantum Survivors

The transition to post-quantum cryptography is not a one-time event: it is a continuous process of cryptographic risk management. Regulatory bodies in the European banking sector (EBA) and the NIS2 Directive already require critical infrastructure organizations to demonstrate the ability to respond to emerging cryptographic vulnerabilities. That capability has a name: crypto-agility.

Unlike analyses focused on HNDL (Harvest Now Decrypt Later) attacks and the immediate quantum threat, this article concentrates on the operational process: how organizations can structure their systems to migrate cryptographic algorithms without rewriting entire infrastructure stacks. The relationship between crypto-agility and the resilience of AI agents operating in critical environments also deserves attention — both domains share the same fundamental challenge of maintaining system integrity under pressure to change.

---

What Exactly Does Crypto-Agility Mean?

Crypto-agility is the architectural capability of a system to replace, update, or combine cryptographic algorithms with minimal impact on the rest of the application. It is not merely about supporting new algorithms; it means the algorithm in use is a configuration variable, not a hardcoded constant.

A highly crypto-agile system has the following characteristics:

• Cryptographic primitives are abstracted behind standardized interfaces (e.g., PKCS#11, JCA/JCE)
• Algorithm identifiers are negotiated at runtime (e.g., cipher suites in TLS)
• Certificates and key material can be rotated without downtime
• The cryptographic inventory is documented and continuously automated

By contrast, a brittle system has direct calls to openssl RSA_encrypt() scattered across the codebase, hardcoded parameters in configuration files, and no centralized record of which algorithms protect which data. This anti-pattern is extremely common: an IBM Security study in 2025 found that 74% of critical infrastructure organizations have at least one production service with hardcoded cryptographic algorithms.

---

Step 1: Building the CBOM — Cryptography Bill of Materials

Before migrating anything, you need to know what needs to be migrated. The CBOM is the cryptographic equivalent of an SBOM (Software Bill of Materials): it documents which algorithms, key sizes, protocols, and certificates are in use, where, and for what purpose.

The 5-Step Inventory Process

1. Automated discovery: Scan source code, compiled binaries, network configurations, and certificate databases using tools like IBM's cq-scanner, Cryptosense Analyzer, or custom SAST rules to detect cryptographic API calls and X.509 certificates in use.
2. Asset classification: Assign each cryptographic usage to a risk category: data in transit, data at rest, identity authentication, code integrity, or long-term protection (>10 years). Data with confidentiality requirements exceeding 5 years has the highest remediation priority.
3. Quantum vulnerability assessment: Determine whether the algorithm is vulnerable to Shor's algorithm (RSA, ECC, DH) or Grover's algorithm (AES-128 with effective security reduction). Symmetric algorithms ≥256 bits and hash functions ≥384 bits are reasonably resilient against quantum computing available in 2026.
4. Impact-based prioritization: Systems with HNDL risk and critical infrastructure authentication systems are Priority 1. Internal systems handling short-lived data are Priority 3.
5. Structured documentation in SPDX or CycloneDX-Crypto: CycloneDX version 1.6 includes the cryptoProperties component for formal CBOM representation. Tools like our hash generator allow you to validate the integrity of generated CBOM manifests before storing them in the configuration repository.

---

Step 2: Hybrid Classical + PQC Deployment Patterns

The recommendation from NIST, Germany's BSI, and France's ANSSI for the transition phase is hybrid deployment: simultaneously using a classical algorithm (X25519, P-256) and a post-quantum algorithm (ML-KEM-768). The combined security model means an adversary must break both algorithms to compromise a session — providing protection against quantum computers and against potential weaknesses in the new PQC standard.

TLS 1.3 with Hybrid ML-KEM-768 in OpenSSL 3.3+

The hybrid group X25519MLKEM768 combines Diffie-Hellman key exchange over Curve25519 with the ML-KEM-768 key encapsulation mechanism (FIPS 203). This group is standardized in the IETF draft draft-kwiatkowski-tls-ecdhe-mlkem and is natively supported in OpenSSL 3.3+ with the oqsprovider provider:

# OpenSSL 3.3+ configuration with hybrid ML-KEM-768 support

[openssl_init]
providers = provider_sect

[provider_sect]
default = default_sect
oqs = oqs_sect

[default_sect]
activate = 1

[oqs_sect]
# Open Quantum Safe provider
module = /usr/lib/ossl-modules/oqsprovider.so
activate = 1

[ssl_defaults]
# Key exchange groups: hybrid PQC first, classical as fallback
Groups = X25519MLKEM768:SecP256r1MLKEM768:x25519:P-256
# TLS 1.3 only — cipher suites are AEAD by design
CipherSuites = TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256
MinProtocol = TLSv1.3
MaxProtocol = TLSv1.3

To verify that the server negotiates the hybrid group correctly during integration testing:

openssl s_client -connect critical-server.company.com:443 \
  -groups X25519MLKEM768 \
  -provider oqsprovider \
  -provider default \
  2>&1 | grep "Server Temp Key"
# Expected output: Server Temp Key: X25519MLKEM768, 1216 bits

The 1216-bit size reflects the concatenation of the X25519 public key (32 bytes) with the ML-KEM-768 encapsulation (1088 bytes). The handshake overhead increases by approximately 1.1 KB compared to classic TLS. For most enterprise applications this is entirely acceptable; for high-frequency systems (HFT, massive IoT), network capacity evaluation is required.

---

Step 3: HSM Upgrade Considerations

Hardware Security Modules are the most critical — and most frequently overlooked — component in PQC migrations. They protect the root keys of corporate PKIs and the cryptographic modules that sign financial transactions, device firmware, and code signing certificates.

Comparative Table: HSM Capabilities for Post-Quantum Cryptography

Vendor / Model	ML-KEM Support	ML-DSA Support	Upgradeable Without Replacement	ML-KEM-768 Throughput
Thales Luna Network HSM 7	✅ FW 7.7.1+	✅ FW 7.7.1+	✅ Yes	~2,800 ops/s
Entrust nShield 5s	✅ OS 13.3+	✅ OS 13.3+	✅ Yes	~3,100 ops/s
AWS CloudHSM v3	✅ Native	⚠️ Preview	N/A (managed)	~4,500 ops/s
Utimaco Se-Series	✅ FW 4.50+	✅ FW 4.50+	✅ Yes	~2,200 ops/s
Legacy HSM (pre-2019)	❌ Not supported	❌ Not supported	❌ Requires replacement	—

The recommended strategy is: update firmware before replacing hardware. Most post-2020 devices support PQC through software updates, dramatically reducing migration costs. For legacy HSMs without support, plan replacement within the Remediation phase of the roadmap.

For key format compatibility testing during migration, our encryption tool allows you to validate encryption and decryption operations across different key formats before updating production systems.

---

Lessons from Banking and Government Sectors

Banking Sector: What Deutsche Bank and BNP Paribas Learned

The crypto-agility pilots launched in 2024 documented consistent patterns:

• The biggest obstacle is organizational, not technical: Coordination between development, security, infrastructure, and external vendor teams consumes 60% of total project effort.
• Corporate PKIs are the most critical bottleneck: Root CAs with 20-25 year lifetimes require special planning. Migrating a corporate PKI without service disruption takes 12 to 24 months even with a dedicated team.
• SaaS vendors are the weakest link: Third-party applications integrated via API represent 40% of cryptographic dependencies not directly controlled by the organization. Including crypto-agility requirements in vendor contracts is imperative.
• Cryptographic technical debt is invisible until audited: 68% of cryptographic dependencies identified in CBOM audits were not previously documented anywhere in the organization.

Government Sector: Mandates and Deadlines

The NSA's CNSA 2.0 framework establishes that all U.S. classified government systems must use exclusively PQC algorithms by 2030. The Dutch government (AIVD) requires full hybrid migration by 2027 for national critical infrastructure. The European Union, through ENISA, recommends completing CBOM inventories before the end of 2026.

These regulations intersect with emerging legal frameworks documented in the analysis of privacy policies adapted to artificial intelligence, where corporate liability for long-term data protection is being redefined.

---

Complete Migration Roadmap: Discovery → Assessment → Remediation → Validation → Monitoring

Phase	Key Activities	Recommended Tools	Exit Criterion	Estimated Duration
Discovery	CBOM scanning, dependency mapping, technical team interviews	cq-scanner, Cryptosense Analyzer, SAST rules	100% of assets catalogued with risk classification	2-4 months
Assessment	Quantum risk scoring, system-level impact analysis, prioritization	NIST IR 8547 matrix, risk workshops	Prioritized backlog with remediation dates per system	1-2 months
Remediation	Code refactoring, hybrid TLS/mTLS configuration, HSM upgrades, PKI rotation	OpenSSL 3.3+, oqs-provider, Bouncy Castle PQC	Critical systems with active hybrid algorithms and PQC certificates issued	6-18 months
Validation	Interoperability testing, PQC pen testing, FIPS 203/204/205 compliance audit	Wireshark, NIST PQC testbeds, external auditors	Regulatory compliance certification for all in-scope systems	2-3 months
Monitoring	Continuous automated CBOM, deprecated algorithm alerts, regulator reporting	SIEM with cryptographic rules, PQC posture dashboards	Detection and response SLA for new cryptographic vulnerability <30 days	Permanent

The Remediation phase is the longest. For critical infrastructure with legacy industrial control systems (SCADA, DCS) spanning decades, the most effective strategy is starting with a "security bubble": deploying hybrid TLS gateways at the perimeter while planning internal migration, protecting the most exposed traffic without immediately touching legacy systems. This approach connects to the security patterns analyzed in the context of advanced robotics and physical cybersecurity.

---

Crypto-Agility as a Security Maturity Indicator

Organizations that complete their CBOM inventory and establish hybrid deployment patterns before 2027 will have a significant advantage when regulators demand demonstration of PQC compliance. The ability to rotate algorithms without downtime also reduces the operational impact of any future cryptographic vulnerability, quantum or otherwise.

A cryptographically agile system responds to a critical algorithm CVE in days, not months. This resilience is increasingly valued in third-party risk assessments by insurers, auditors, and strategic partners.

To begin the inventory, our JWT decoder tool can immediately identify signing algorithms embedded in authentication tokens — assets that frequently go undetected in initial scans. The organizational security training guide complements the technical work by ensuring all involved teams understand the context and urgency of the transition.

The question is not whether your organization will need to migrate to post-quantum cryptography. The question is whether it will have the architecture to do so when the regulator, the auditor — or the adversary — comes knocking.