You can't migrate what you can't see. That's the central issue financial institutions face as quantum computing shifts from a theoretical threat to an operational deadline. The U.S. Department of the Treasury's Quantum-Readiness Task Force won't provide a compliance checklist or a regulatory due date. Instead, you're racing against adversaries who can harvest encrypted traffic now and decrypt it once quantum computers mature.
Your first step isn't choosing new algorithms. It's identifying every place your organization uses cryptography.
Why This Matters Now
The move to post-quantum cryptography (PQC) is unlike past security upgrades because it affects every layer of your technology stack at once. Unlike patching a vulnerability or rotating credentials, you're replacing fundamental elements that protect payment systems, API authentication, digital signatures, and data at rest across decades of infrastructure.
Financial sector readiness varies. Large banks have dedicated teams and budgets for quantum risk, while smaller banks, asset managers, and fintechs rely more on outside vendors with fewer internal resources. If you're starting cryptographic inventory now, you're not behind. You're joining many institutions that underestimated the scope.
The dependency problem complicates the timeline. Most cryptography you rely on is embedded in purchased technology, meaning your migration schedule depends on payment processors, cloud providers, custodians, software vendors, and counterparties moving at different speeds. You need visibility to coordinate effectively.
What You Need Before Starting
Access and authority:
- Read access to infrastructure configuration management databases
- API documentation for all third-party integrations
- Software bill of materials (SBOM) from vendors where available
- Cloud provider inventory tools (AWS Config, Azure Resource Graph, GCP Asset Inventory)
Technical resources:
- Network traffic analysis capability (packet capture or flow logs)
- Certificate inventory tools (expand to cover all cryptographic assets)
- Access to legacy system documentation, even if incomplete
Organizational alignment:
- Sponsorship from a senior technical leader who can authorize cross-team access
- Dedicated time from application owners, platform engineers, and security architects
- Budget for commercial discovery tools if your estate exceeds manual inventory capacity
You don't need a complete asset inventory to start. You need permission to look and a structured method for recording what you find.
Step-by-Step Implementation
Phase 1: Define Scope and Categorize Assets
Start with systems that process regulated data or connect to critical payment infrastructure. You're building a risk-based inventory, not an academic catalog.
Create four initial categories:
- Systems you control: Applications your team develops, infrastructure you operate
- Vendor-managed platforms: SaaS products, cloud services, payment processors
- Legacy systems: Mainframes, acquired technology, systems without active development
- Network infrastructure: VPNs, TLS terminators, hardware security modules
For each category, identify the owner responsible for cryptographic decisions. In vendor-managed platforms, that owner may be external.
Phase 2: Automated Discovery
Deploy discovery tools that can identify cryptographic implementations without requiring manual inspection:
For TLS/SSL certificates:
# Scan internal network ranges for certificate usage
nmap --script ssl-cert -p 443,8443 [network-range] -oX tls-inventory.xml
For cloud infrastructure: Configure AWS Config rules to detect cryptographic services:
- KMS key usage across accounts
- RDS encryption settings
- S3 bucket encryption configurations
- Certificate Manager inventory
For application-level cryptography: Use static analysis tools (Semgrep, CodeQL) with rulesets that flag cryptographic library calls. Focus on:
- Key generation functions
- Signature verification
- Encryption/decryption operations
- Hash function usage
Document the algorithm, key length, and purpose for each finding. You're not fixing anything yet. You're mapping the terrain.
Phase 3: Vendor Questionnaire
For every third-party service that handles sensitive data, send a structured questionnaire:
- What cryptographic algorithms does your service use for data in transit, at rest, and for digital signatures?
- Do you maintain a cryptographic bill of materials?
- What is your timeline for post-quantum cryptography support?
- Will migration require API changes, configuration updates, or version upgrades on our side?
Track responses in a central register. Non-responsive vendors become risk items for escalation.
Phase 4: Manual Inspection of Critical Systems
Automated tools miss embedded cryptography in compiled binaries, proprietary protocols, and custom integrations. For payment systems, settlement infrastructure, and identity providers, conduct manual code review:
Look for:
- Hard-coded algorithm selections (RSA-2048, ECDSA P-256)
- Certificate pinning that will break when you rotate to PQC certificates
- Custom authentication schemes that assume specific key sizes
- Interoperability dependencies (you sign with RSA; counterparty verifies with a library you don't control)
Document these as "migration blockers" requiring vendor coordination or code changes.
Phase 5: Build the Cryptographic Inventory Register
Consolidate findings into a structured register with these fields:
- Asset identifier: System name, service endpoint, or application
- Cryptographic function: Authentication, encryption, signing, key exchange
- Algorithm and parameters: RSA-2048, AES-256-GCM, SHA-256
- Control level: Internal, vendor-managed, legacy/unknown
- Migration owner: Team or vendor responsible for replacement
- Dependencies: Systems or counterparties that must coordinate changes
- Risk priority: Based on data sensitivity and exposure to harvest-now-decrypt-later attacks
This register becomes your migration roadmap.
Validation: How to Verify It Works
Your inventory is complete enough when you can answer these questions:
Coverage test: Can you identify the cryptographic algorithm protecting your three highest-value data flows? If not, your discovery phase missed critical assets.
Vendor dependency map: For each vendor-managed service, do you know their PQC timeline and what changes you'll need to make on your side?
Legacy system accounting: Have you identified systems where the cryptographic implementation is unknown or undocumented? These require special handling.
Cross-team validation: Share the inventory with application teams and ask them to flag missing systems. If they identify gaps, your discovery tools or scope definition needs refinement.
Run a tabletop exercise: pick a hypothetical quantum-safe algorithm and trace the changes required across your inventory. If you can't map the impact, your inventory lacks sufficient detail.
Maintenance and Ongoing Tasks
Cryptographic inventory isn't a one-time project. New services launch, vendors update products, and acquisitions bring new technology into your estate.
Monthly:
- Re-run automated discovery scans to detect new certificates or cloud cryptographic services
- Review vendor security bulletins for cryptographic changes
Quarterly:
- Update vendor questionnaire responses as PQC timelines shift
- Audit new application deployments for cryptographic inventory compliance
Annually:
- Validate that your inventory register still reflects organizational priorities
- Re-prioritize migration sequencing based on threat intelligence and vendor readiness
The institutions that complete migration first won't be the ones with the most resources. They'll be the ones who knew exactly what they needed to change before the work began. Your inventory is that foundation.
