The Crypto-Agility Problem: You Cannot Migrate What You Cannot Find
Crypto-agility is the ability to swap cryptographic algorithms across your infrastructure without service disruption. It sounds straightforward. In practice, it requires something most enterprises lack entirely: a complete map of where cryptography is deployed.
You cannot be agile about cryptography you cannot see. And most organizations cannot see their cryptography.
The average enterprise has cryptographic assets deployed across 15+ distinct categories — TLS certificates, SSH keys, JWT signing, database encryption, VPN tunnels, code signing, S/MIME, disk encryption, API tokens, HSMs, and more. Each managed by different teams, configured through different tools, governed by different policies (or no policy at all).
When a vulnerability hits (Heartbleed, SHA-1 deprecation, DROWN, ROBOT) or a standard changes (PQC migration, TLS 1.3 mandate), the enterprise response follows a predictable pattern: panic, scramble, discover systems nobody knew about, miss deadlines, and eventually achieve partial compliance.
Crypto-agility breaks this cycle. But only if it starts with inventory.
PQC Migration Trajectory (CNSA 2.0 Timeline)
Projected algorithm distribution across enterprise infrastructure
⚠️ Organizations that haven't started inventory by 2026 will miss CNSA 2.0 network equipment deadline (2030) — migration typically takes 3-5 years.
What Crypto-Agility Actually Means
Crypto-agility is not a product. It’s an architectural property. An organization is crypto-agile when:
- All cryptographic assets are inventoried — You know what algorithms, key sizes, and protocols are in use across every system.
- Algorithms are abstracted from implementations — Changing from RSA to ML-DSA doesn’t require rewriting application logic.
- Configuration is externalized — Cipher suites, key sizes, and algorithm selections are configuration parameters, not compiled constants.
- Migration can be tested — You can validate new algorithms in staging before production rollout.
- Rollback is possible — If a new algorithm causes issues, you can revert without extended downtime.
- Timeline is predictable — You can estimate how long a full algorithm rotation takes because you know the scope.
Organizations meeting all six criteria can respond to a cryptographic emergency (algorithm break, standard change, vulnerability disclosure) in weeks rather than years.
Organizations meeting zero criteria — which describes most enterprises — take 3-7 years to complete a migration. The SHA-1 deprecation proved this empirically.
Why Crypto-Agility Is Now a Compliance Requirement
Crypto-agility was a best practice. It is now a regulatory expectation.
NIST SP 800-131A Revision 2 (Draft)
NIST’s Transitioning the Use of Cryptographic Algorithms and Key Lengths framework explicitly requires organizations to:
- Maintain an inventory of cryptographic implementations
- Plan for algorithm transitions
- Implement mechanisms to update cryptographic algorithms without operational disruption
NSA CNSA 2.0 Suite (September 2022)
The Commercial National Security Algorithm Suite 2.0 mandates quantum-resistant algorithms for National Security Systems on a phased timeline. Organizations supplying to defense and intelligence agencies must demonstrate:
- Current cryptographic inventory
- Migration plan to CNSA 2.0 algorithms
- Ability to complete migration within defined timelines
PCI DSS v4.0 (March 2024)
Requirement 12.3.3 mandates that organizations maintain an inventory of cryptographic cipher suites and protocols in use, including purpose and where used. Requirement 4.2.1 requires strong cryptography for transmission of cardholder data.
Executive Order 14028 (May 2021) and OMB M-23-02
Federal agencies and their suppliers must:
- Inventory all systems using cryptography
- Identify systems vulnerable to quantum attacks
- Prioritize migration based on risk
SOC 2 Type II
Trust Services Criteria CC6.1 requires organizations to identify and manage encryption keys and certificates. Auditors increasingly expect documented cryptographic inventories as evidence of this control.
EU Cyber Resilience Act (CRA)
Requires manufacturers of digital products to maintain security throughout the product lifecycle, including the ability to update cryptographic components.
| Framework | Crypto Inventory Required? | Algorithm Agility Required? | Enforcement Date |
|---|---|---|---|
| NIST SP 800-131A Rev 2 | Yes | Yes | Draft (expected 2025) |
| NSA CNSA 2.0 | Yes | Yes (by defined timelines) | 2025-2035 phased |
| PCI DSS v4.0 | Yes (12.3.3) | Implied (4.2.1) | March 2025 |
| OMB M-23-02 | Yes | Yes | Active |
| SOC 2 Type II | Implied (CC6.1) | Not explicit | Active |
| EU CRA | Yes | Yes | 2027 |
| HIPAA (45 CFR 164.312) | Implied | Not explicit | Active |
The compliance landscape has shifted. “We’ll figure it out when we need to” is no longer an acceptable answer to auditors asking about your cryptographic posture.
The Inventory Gap: Where Cryptography Hides
The average enterprise has cryptographic deployments across at least 15 categories. Most security teams have visibility into 3-4 of them.
| Category | Examples | Typical Owner | Usually Inventoried? |
|---|---|---|---|
| TLS certificates (public) | Web servers, APIs, CDN endpoints | InfoSec / Platform | Partially |
| TLS certificates (internal) | mTLS between services, internal portals | App teams / AD CS admin | Rarely |
| SSH keys | Server authentication, user access, CI/CD | SysAdmin / DevOps | Rarely |
| Code signing certificates | Software packages, drivers, scripts | Release Engineering | Sometimes |
| Email encryption (S/MIME) | Executive communications, legal correspondence | IT / Email admin | Rarely |
| VPN configurations | IPsec tunnels, WireGuard, OpenVPN | Network team | Partially |
| Database encryption (TDE) | SQL Server, Oracle, PostgreSQL transparent encryption | DBA team | Rarely |
| Disk/volume encryption | BitLocker, LUKS, FileVault, EBS encryption | Endpoint / Cloud team | Partially |
| JWT/OAuth signing keys | API authentication, SSO tokens | Identity team | Rarely |
| API keys and tokens | Service-to-service authentication, third-party integrations | Application teams | Rarely |
| HSM-stored keys | Root CA keys, payment processing, KMS | Security / Compliance | Usually |
| Firmware/bootloader signing | UEFI Secure Boot, device firmware | Hardware / OT team | Rarely |
| Container image signing | Cosign, Notary, Docker Content Trust | DevOps / Platform | Rarely |
| Kubernetes secrets | TLS secrets, service account tokens | Platform Engineering | Partially |
| Backup encryption | Tape encryption, cloud backup encryption keys | Backup / DR team | Rarely |
| IoT device certificates | Device identity, MQTT TLS, OTA update signing | IoT / OT team | Rarely |
The pattern: Teams manage their own cryptography in isolation. No central registry exists. No standard format for documentation. When someone asks “where do we use RSA-2048?” — nobody can answer completely.
SHA-1 Deprecation: The Case Study in Crypto-Agility Failure
SHA-1 deprecation provides the most complete real-world example of what happens when an algorithm must be retired across an enterprise without crypto-agility.
Timeline
| Date | Event |
|---|---|
| February 2005 | Wang et al. publish theoretical SHA-1 collision attack |
| November 2013 | Microsoft announces SHA-1 deprecation for code signing (deadline: January 2016) |
| September 2014 | Chrome begins displaying warnings for SHA-1 certificates |
| January 2016 | CAs prohibited from issuing SHA-1 TLS certificates |
| February 2017 | Google publishes SHAttered — practical SHA-1 collision |
| February 2017 | Many enterprises still running SHA-1 certificates |
| 2019 | NIST reports organizations still discovering SHA-1 in production systems |
From first warning to practical attack: 12 years. From industry deadline to full removal: 3+ years for most enterprises. Some organizations never fully completed the migration.
What Was Missed
Even organizations that actively migrated TLS certificates discovered SHA-1 in unexpected places years later:
- Internal CA certificates still using SHA-1 for signing (nobody checks internal CA hash algorithms)
- Code signing certificates embedded in deployed software packages
- S/MIME certificates in email archives
- HMAC-SHA-1 in authentication protocols (not directly vulnerable but flagged by auditors)
- SHA-1 fingerprints used as certificate identifiers in configuration files
- Legacy devices (printers, network appliances, SCADA controllers) with non-updatable firmware
- Third-party integrations requiring SHA-1 for backward compatibility
The Lesson
SHA-1 deprecation took 5+ years for well-resourced enterprises. PQC migration is broader in scope (more algorithm categories), deeper in impact (key exchange, not just signatures), and harder to execute (new mathematical foundations, larger key sizes, protocol changes).
If SHA-1 took 5+ years with significant industry pressure, PQC migration without crypto-agility will take 7-10+ years. That timeline doesn’t fit within the HNDL threat window.
Discovery Approaches Compared
Four primary methods exist for cryptographic discovery. Each has distinct strengths and blind spots.
| Approach | How It Works | Coverage | Deployment Effort | Maintenance | Cost | Best For |
|---|---|---|---|---|---|---|
| Agent-based scanning | Software agent on each host inspects local certificates, keys, configurations, and running processes | Complete host-level visibility | High (deploy to every host) | High (agent updates, compatibility) | $$$ | Full inventory of managed systems |
| Agentless network scanning | Remote probes connect to network services and extract cryptographic metadata from protocol handshakes | Active network services only | Low (single scanning server) | Low (scheduled scans) | $ | Quick TLS/SSH baseline |
| Traffic analysis | Passive capture of network traffic at switches/TAPs to extract TLS handshakes, cipher suites, certificates | Actually-used cryptography (vs. configured) | Medium (TAP deployment, storage) | Medium (data pipeline) | $$ | Identifying active deprecated algorithms |
| Code/config analysis | Static analysis of source code, IaC templates, container definitions, and configuration files | Development-time decisions | Medium (CI/CD integration) | Medium (rule updates) | $ | Catching problems before deployment |
Recommended Layered Approach
No single method provides complete coverage. The recommended approach layers methods:
Layer 1 — Agentless network scanning (Week 1-2) Deploy immediately. Covers all network-accessible services. Produces an initial inventory within days.
# Parallel scan of internal network for TLS endpoints
masscan 10.0.0.0/8 -p 443,8443,636,993,995,5061,9443 --rate 10000 \
-oL tls-endpoints.txt
# Deep inspection of discovered endpoints
cat tls-endpoints.txt | grep "open" | awk '{print $4":"$3}' | \
while read endpoint; do
echo | timeout 5 openssl s_client -connect "$endpoint" 2>/dev/null | \
openssl x509 -noout -subject -issuer -dates -sigopt -text 2>/dev/null
done > cert-inventory-raw.txtLayer 2 — Code and configuration analysis (Week 2-4) Integrate into CI/CD pipelines. Catches cryptographic decisions in source code before they reach production.
Layer 3 — Agent-based scanning (Month 2-3) Deploy to production hosts for complete local visibility. Finds keystores, private keys, configuration files, and runtime cryptographic usage.
Layer 4 — Traffic analysis (Month 3-4) Deploy at network aggregation points to validate what’s actually in use versus what’s configured but dormant.
CBOM Standard: CycloneDX Crypto Extensions
The Cryptographic Bill of Materials (CBOM) provides the data model for cryptographic inventory. The industry has standardized on CycloneDX (an OWASP standard) with cryptographic extensions.
CycloneDX v1.6 Crypto Properties
CycloneDX v1.6 introduced first-class support for cryptographic assets:
{
"bomFormat": "CycloneDX",
"specVersion": "1.6",
"components": [
{
"type": "cryptographic-asset",
"name": "api-gateway-tls-cert",
"cryptoProperties": {
"assetType": "certificate",
"algorithmProperties": {
"algorithm": "RSA",
"keySize": 2048,
"mode": "ECB",
"padding": "PKCS1v15",
"cryptoFunctions": ["sign", "verify"],
"classicalSecurityLevel": 112,
"nistQuantumSecurityLevel": 0
},
"certificateProperties": {
"subjectName": "CN=api.example.com",
"issuerName": "CN=DigiCert Global G2",
"notValidBefore": "2026-01-15T00:00:00Z",
"notValidAfter": "2026-04-15T23:59:59Z",
"signatureAlgorithm": "sha256WithRSAEncryption"
},
"protocolProperties": {
"type": "TLS",
"version": "1.3",
"cipherSuites": [
{
"name": "TLS_AES_256_GCM_SHA384",
"algorithms": ["AES-256-GCM", "SHA-384"],
"identifiers": ["0x13,0x02"]
}
]
}
}
}
]
}Why CBOM Matters for Crypto-Agility
A machine-readable CBOM enables:
- Automated vulnerability assessment — When a new algorithm weakness is published, query the CBOM to find all affected assets instantly.
- Migration progress tracking — Calculate percentage of assets migrated from RSA to ML-DSA across the entire organization.
- Dependency mapping — Understand which certificate chains, HSMs, and trust stores are connected to which services.
- Compliance reporting — Generate audit evidence automatically from the CBOM data.
- Risk scoring — Apply quantitative risk models across the entire cryptographic estate.
Without a CBOM, each of these activities requires manual effort measured in weeks or months. With a CBOM, they become API queries returning results in seconds.
Implementation Roadmap for Crypto-Agility
Achieving crypto-agility is a multi-year program. But the roadmap has clear phases with measurable outcomes.
Phase 1: Discovery and Inventory (Months 1-6)
Objective: Know what exists.
| Activity | Timeline | Owner | Output |
|---|---|---|---|
| Deploy network scanners across all environments | Month 1 | Security Engineering | Network crypto baseline |
| Integrate crypto linting into CI/CD pipelines | Month 1-2 | DevSecOps | Code-level findings |
| Deploy host-based discovery on production systems | Month 2-3 | Platform Engineering | Host-level inventory |
| Consolidate findings into CycloneDX CBOM | Month 3-4 | Security Architecture | v1.0 CBOM |
| Assign owners to all discovered assets | Month 4-5 | Security + All teams | Ownership matrix |
| Validate inventory accuracy (sample audit) | Month 5-6 | Internal Audit | Accuracy report |
Key metric: Percentage of infrastructure covered by discovery tooling.
Phase 2: Architecture Assessment (Months 4-9)
Objective: Identify what must change for algorithm flexibility.
- Audit application architectures for hardcoded algorithm selections
- Identify systems using cryptographic abstraction layers vs. direct implementations
- Map vendor dependencies (which vendor products lock you to specific algorithms?)
- Assess protocol flexibility (can your TLS libraries support hybrid key exchange?)
- Document constraint list: systems that cannot be made agile without replacement
Key metric: Percentage of systems classified by agility readiness (agile-ready, needs refactoring, needs replacement).
Phase 3: Architecture Remediation (Months 7-18)
Objective: Modify systems to support algorithm swaps.
For each system category, the remediation looks different:
| System Type | Agility Remediation | Effort |
|---|---|---|
| Web servers (nginx, Apache) | Already agile — cipher suites are configuration | Low |
| Application TLS (Java, .NET, Python) | Upgrade TLS libraries, externalize cipher config | Medium |
| Custom cryptographic code | Refactor to use cryptographic abstraction APIs | High |
| Legacy appliances | May require hardware replacement | Very High |
| Vendor products | File feature requests, plan for version upgrades | Vendor-dependent |
| Database encryption | Typically wrapped keys — agility at KMS layer | Medium |
| PKI infrastructure | CA re-issuance, new certificate profiles | High |
Phase 4: Operational Crypto-Agility (Months 12-24)
Objective: Prove you can rotate algorithms without service disruption.
- Run algorithm migration drills (tabletop and live)
- Establish SLA for algorithm rotation (target: 90 days from decision to completion)
- Implement continuous CBOM updates (not point-in-time snapshots)
- Build automated compliance reporting from CBOM data
- Integrate cryptographic health into security dashboards
Key metric: Time to complete a full algorithm rotation across all systems.
Relationship Between CLM and Crypto-Agility
Certificate Lifecycle Management (CLM) and crypto-agility are deeply connected but not identical.
CLM provides:
- Visibility into certificate-based cryptography (TLS, code signing, S/MIME)
- Automated renewal and deployment
- Policy enforcement for key sizes and algorithms
- Centralized inventory of certificate assets
Crypto-agility requires CLM plus:
- Visibility into non-certificate cryptography (symmetric keys, JWT signing, VPN configs)
- Architecture that allows algorithm changes without re-deployment
- Testing infrastructure for new algorithms
- Vendor coordination for third-party dependencies
| Capability | CLM Covers? | Crypto-Agility Requires? |
|---|---|---|
| TLS certificate inventory | ✓ | ✓ |
| Certificate renewal automation | ✓ | ✓ |
| SSH key inventory | Some platforms | ✓ |
| Code signing visibility | Some platforms | ✓ |
| Symmetric key management | ✗ | ✓ |
| Algorithm abstraction | ✗ | ✓ |
| Protocol flexibility | ✗ | ✓ |
| Migration drill capability | ✗ | ✓ |
| CBOM generation | Partial | ✓ |
| Vendor dependency mapping | ✗ | ✓ |
Practical implication: If you already have a CLM platform, you have a foundation. Your CLM inventory is 30-40% of your CBOM. But crypto-agility requires extending far beyond certificate management into every system that touches cryptography.
If you don’t have CLM yet, implementing CBOM and crypto-agility together is more efficient than doing them sequentially — you build the broader inventory once and extract the CLM subset from it.
Compliance Mapping: Which Frameworks Require Crypto Inventory
| Compliance Framework | Inventory Requirement | Agility Requirement | Deadline/Status |
|---|---|---|---|
| NIST SP 800-131A | Cryptographic transition planning | Algorithm update capability | Active guidance |
| NIST CSF 2.0 (PR.DS-01) | Protect data confidentiality, integrity | Implies current algorithm awareness | February 2024 |
| NSA CNSA 2.0 | Full cryptographic inventory | Migration to PQC algorithms | 2025-2035 |
| PCI DSS v4.0 (12.3.3) | Inventory of cryptographic suites/protocols | Strong cryptography requirement | March 2025 |
| SOC 2 (CC6.1) | Encryption key management | Implied by access control criteria | Continuous |
| HIPAA (§164.312(a)(2)(iv)) | Encryption mechanism documentation | Must use “reasonable and appropriate” encryption | Active |
| CMMC Level 2+ (SC.L2-3.13.11) | Cryptographic mechanisms for CUI | Implies FIPS-validated, algorithm awareness | Active |
| ISO 27001:2022 (A.8.24) | Cryptography policy and management | Algorithm lifecycle management | Active |
| DORA (EU) | ICT asset register including security | Cryptographic resilience testing | January 2025 |
| NIS2 (EU) | Risk management measures including encryption | State-of-the-art cryptography | October 2024 |
| FedRAMP | Cryptographic module inventory (FIPS 140-3) | Algorithm transition readiness | Active |
| SWIFT CSP | Encryption of sensitive data | Current, strong cryptography | Annual |
The convergence is clear: Every major compliance framework now requires or implies cryptographic inventory. The days of treating algorithm choices as implementation details buried in server configs are over.
Practical First Steps: Week 1 Actions
Crypto-agility is a multi-year program. But Week 1 actions are straightforward:
Day 1-2: External Certificate Inventory
Use Certificate Transparency logs to discover every public certificate issued for your domains:
# Query crt.sh for all certificates issued to your domain
curl -s "https://crt.sh/?q=%25.example.com&output=json" | \
jq -r '.[] | [.common_name, .issuer_name, .not_before, .not_after, .serial_number] | @tsv' | \
sort -t$'\t' -k4 > external-cert-inventory.tsv
# Count unique active certificates
awk -F'\t' -v today="$(date +%Y-%m-%d)" '$4 > today' external-cert-inventory.tsv | wc -lDay 2-3: Internal Network Scan
Scan internal subnets for TLS and SSH endpoints:
# Discover TLS endpoints
nmap -sV -p 443,8443,636,993,995,5061 --open 10.0.0.0/8 \
-oG tls-hosts.gnmap
# Discover SSH endpoints
nmap -sV -p 22,2222 --open 10.0.0.0/8 \
-oG ssh-hosts.gnmap
# Extract unique algorithm information from discovered TLS hosts
grep "open" tls-hosts.gnmap | awk '{print $2}' | \
while read ip; do
echo | timeout 3 openssl s_client -connect "$ip:443" 2>/dev/null | \
openssl x509 -noout -text 2>/dev/null | \
grep -E "(Signature Algorithm|Public-Key)" | head -2
done | sort | uniq -c | sort -rnDay 3-4: Quick Wins Identification
Review scan results for immediately actionable findings:
- SHA-1 certificates still in use (should have been removed years ago)
- RSA-1024 keys (below minimum strength)
- Expired certificates (operational issue, not crypto-agility, but reveals tracking gaps)
- TLS 1.0/1.1 endpoints (deprecated protocols)
- Self-signed certificates on non-development systems
Day 5: Stakeholder Brief
Compile findings into a one-page summary:
- Total cryptographic assets discovered (vs. previously known)
- Gap percentage (discovered minus documented)
- Immediate risks found (deprecated algorithms)
- Recommended next steps (Phase 1 program approval)
This one-week effort produces the evidence needed to justify a full crypto-agility program to leadership. The gap between “known” and “discovered” assets is typically 3-5x — which makes the case compellingly.
The Bottom Line
Crypto-agility is not an algorithm selection exercise. It’s a visibility problem first, an architecture problem second, and an algorithm problem third.
The sequence matters:
- Inventory — Find everything. Document it in CBOM format. Assign owners.
- Assess — Classify by quantum vulnerability, compliance requirement, and migration complexity.
- Architect — Modify systems to support algorithm rotation without service disruption.
- Migrate — Execute algorithm transitions in priority order.
- Maintain — Keep the CBOM current. Run migration drills. Stay ready.
Skip step 1, and every subsequent step fails. You cannot assess what you haven’t found. You cannot architect changes for systems you don’t know about. You cannot migrate algorithms in systems you haven’t mapped.
The organizations that started their cryptographic inventory in 2024-2025 will complete PQC migration on schedule. The organizations that are still debating algorithm selection without knowing their own cryptographic footprint will be scrambling in 2029, just as they scrambled during SHA-1 deprecation.
Start with inventory. Everything else follows.
About QCecuring
QCecuring builds the cryptographic visibility layer that enables crypto-agility. Our platform automates cryptographic discovery across enterprise environments — network scanning, code analysis, configuration inspection, and certificate monitoring — and produces standards-compliant CBOM output in CycloneDX format.
We help organizations answer the fundamental question: “Where is cryptography deployed in our infrastructure, and what algorithms does it use?” — then build the operational capability to change those algorithms when the time comes.
Start your cryptographic discovery →
Tags: Crypto-Agility, Cryptographic Inventory, CBOM, CycloneDX, Post-Quantum Cryptography, PQC, SHA-1 Deprecation, NIST SP 800-131A, NSA CNSA 2.0, PCI DSS, Certificate Lifecycle Management, CLM, RSA, ECC, Algorithm Migration, Enterprise Security, Compliance