Cryptographic Inventory Guide

You cannot migrate what you cannot find. Building a cryptographic inventory is the essential first step in any post-quantum migration. Without knowing where cryptography lives in your organization, across code, configuration, certificates, hardware, and third-party services, you are planning blind.

NIST’s post-quantum migration guidance (SP 800-131A Rev. 2 and the draft NCCoE PQC Migration Project) explicitly calls out cryptographic discovery as the starting point. CISA’s “Quantum-Readiness” guidance for critical infrastructure says the same thing: inventory first, then prioritize, then migrate.

This guide provides a practical framework for discovering, cataloging, and prioritizing all cryptographic assets in your organization.

Teams can capture the resulting decisions in the open PQC migration plan template and use the PQC vendor questionnaire to request capability-level evidence from suppliers.

What to Include in a Cryptographic Inventory

A complete inventory captures more than just “we use AES-256.” Each entry should record:

Algorithm details:

Algorithm name and variant (e.g., RSA-2048, ECDSA P-256, AES-256-GCM)
Key length or security parameter
Purpose: encryption, signing, hashing, key exchange, random number generation
Whether it is quantum-vulnerable (RSA, ECDSA, ECDH, DSA, DH) or quantum-safe (AES, SHA-256, ML-KEM, ML-DSA)

Location and context:

System or application name
Code repository and file path (if applicable)
Configuration file or deployment artifact
Cloud service or managed service identifier
Hardware device (HSM, TPM, embedded device)

Operational metadata:

Data sensitivity classification
Certificate expiration dates
Key rotation schedule
Compliance requirements and applicable authority (FIPS 140-3, PCI DSS, contractual controls)
Vendor or third-party dependency

FIPS/CMVP evidence, where required:

CMVP certificate number, FIPS standard version, status (Active, Historical or Revoked), and sunset date
Exact cryptographic module and version, operational environment, approved mode and validation boundary
Whether the module is suitable for new systems, existing systems or a documented legacy exception
Algorithms and operations actually inside the approved scope, including whether required PQC services are approved

Since September 22, 2026, only FIPS 140-3 validations remain Active. Historical FIPS 140-2 modules can be considered for existing systems after the appropriate risk decision, but not treated as current validation for a new system. The FIPS 140-2 to FIPS 140-3 transition guide explains the procurement boundary and why algorithm support alone is not module validation.

Risk assessment:

Is this protecting data at rest or data in transit?
What is the required confidentiality lifetime of the data?
Is this system exposed to the internet?
What is the business impact if this cryptography is broken?

Phase 1: Automated Code Scanning

Start with your source code. Automated scanning catches the majority of cryptographic usage quickly.

Static Analysis Tools

OWASP Dependency-Check and Dependency-Track: These tools identify libraries with known cryptographic implementations. Any dependency on OpenSSL, Bouncy Castle, libsodium, or similar libraries flags that application as using cryptography.

IBM CBOM (Cryptography Bill of Materials): IBM released open-source tooling in 2024 for generating a CBOM from source code. It scans for cryptographic API calls and produces a structured inventory in CycloneDX format.

# Using IBM's cbomkit-theia scanner
cbomkit-theia scan --input ./my-project --output cbom.json --format cyclonedx

Cryptosense Analyzer: A commercial tool that instruments Java applications at runtime to capture every cryptographic operation, including algorithm, key size, provider, and call site. Useful for complex enterprise applications where static analysis misses dynamically constructed crypto calls.

CodeQL (GitHub): Write custom queries to find cryptographic API usage:

import java

from MethodAccess ma
where ma.getMethod().getDeclaringType().hasQualifiedName("javax.crypto", "Cipher")
  and ma.getMethod().hasName("getInstance")
select ma, ma.getArgument(0)

Grep-Based Discovery

For a quick initial scan, search for common cryptographic patterns:

# Find RSA usage in Java projects
grep -rn "RSA\|getInstance.*RSA\|RSAPublicKey\|RSAPrivateKey" --include="*.java" .

# Find elliptic curve usage
grep -rn "EC\|ECDSA\|ECDH\|P-256\|P-384\|secp256r1" --include="*.java" .

# Find key sizes that suggest specific algorithms
grep -rn "2048\|4096\|256\|384" --include="*.java" . | grep -i "key\|cipher\|sign"

# Python projects
grep -rn "from cryptography\|from Crypto\|import hashlib\|import hmac" --include="*.py" .

# Node.js projects
grep -rn "crypto\.\|require.*crypto\|createCipher\|createSign\|createHash" --include="*.js" --include="*.ts" .

# Configuration files
grep -rn "ssl_cipher\|cipher_suite\|tls_version\|key_algorithm" --include="*.conf" --include="*.yml" --include="*.yaml" --include="*.toml" .

Language-Specific Patterns to Search For

Java: Cipher.getInstance, KeyPairGenerator.getInstance, Signature.getInstance, KeyAgreement.getInstance, MessageDigest.getInstance, Mac.getInstance, SecretKeyFactory.getInstance

Python: cryptography.hazmat.primitives, Crypto.Cipher, Crypto.PublicKey, hashlib, hmac, ssl.create_default_context

Go: crypto/rsa, crypto/ecdsa, crypto/ed25519, crypto/tls, crypto/aes, golang.org/x/crypto

C/C++: EVP_PKEY_CTX_new, RSA_generate_key, EC_KEY_new, AES_encrypt, SSL_CTX_new

.NET/C#: RSACryptoServiceProvider, ECDsa.Create, Aes.Create, X509Certificate2, SslStream

Phase 2: Network and TLS Scanning

Your code is only part of the picture. Network connections use cryptography that may not be visible in source code.

TLS Configuration Scanning

testssl.sh: Scan all your endpoints to document which TLS versions and cipher suites are in use:

# Scan a single host
testssl.sh --json-pretty example.com:443

# Batch scan from a list of hosts
while read host; do
    testssl.sh --json-pretty "$host" >> tls-inventory.json
done < hosts.txt

Nmap with ssl-enum-ciphers:

nmap --script ssl-enum-ciphers -p 443 -iL hosts.txt -oX nmap-tls-scan.xml

sslyze: Python-based TLS scanner that can test large numbers of hosts in parallel:

sslyze --regular --targets_in hosts.txt --json_out tls-results.json

What to Capture from TLS Scans

For each endpoint, record:

TLS protocol version (1.2, 1.3)
Key exchange algorithm (RSA, ECDHE, X25519, X25519MLKEM768)
Authentication algorithm (RSA, ECDSA)
Cipher (AES-128-GCM, AES-256-GCM, ChaCha20-Poly1305)
Certificate chain details (key types, sizes, expiration)

Flag any endpoint using RSA or ECDHE key exchange without a post-quantum hybrid. These are the connections vulnerable to harvest-now-decrypt-later attacks.

Phase 3: Certificate Inventory

Certificates are a critical, often overlooked, part of the cryptographic inventory.

Discovery Methods

Certificate Transparency logs: Search crt.sh or Censys for all certificates issued to your domains:

# Query Certificate Transparency for your domain
curl -s "https://crt.sh/?q=%.example.com&output=json" | jq '.[].common_name' | sort -u

Internal CA inventory: If you run a private CA (Active Directory Certificate Services, HashiCorp Vault PKI, EJBCA), export the full list of issued certificates.

Cloud provider certificate managers: AWS Certificate Manager, Azure Key Vault, Google Cloud Certificate Manager all provide APIs to list managed certificates.

Endpoint scanning: Use tools like cert-manager’s cmctl or custom scripts to discover certificates deployed on servers, load balancers, and ingress controllers.

What to Record for Each Certificate

Subject and issuer
Public key algorithm (RSA, ECDSA) and key size
Signature algorithm (sha256WithRSAEncryption, ecdsa-with-SHA384)
Validity period (not before, not after)
Where it is deployed
Auto-renewal status
Whether the issuing CA supports PQC certificates

Phase 4: Infrastructure and Managed Services

Many organizations rely on managed services where cryptography is configured but not coded.

Cloud Services Checklist

AWS:

KMS key inventory: aws kms list-keys and aws kms describe-key for each
S3 bucket encryption settings
RDS/Aurora encryption configuration
CloudFront distribution TLS settings
ELB/ALB cipher policies
ACM certificate inventory

Azure:

Key Vault keys and certificates
Storage account encryption
App Service TLS configuration
Application Gateway SSL policies
Azure Front Door cipher suites

Google Cloud:

Cloud KMS key rings and crypto keys
Cloud KMS protection levels (SOFTWARE, Cloud HSM, Cloud HSM Single-tenant, or EKM)
Import-only keys, active import jobs, import methods, expiry dates, and source-key custody
Cloud Storage encryption settings
Load balancer SSL policies
Certificate Manager inventory

Protection level matters during PQC planning. Google Cloud’s quantum-safe key import Preview supports software-backed target keys only, so an inventory that lists a key without its protection level can produce an invalid migration plan.

On-Premises Infrastructure

HSM inventory (vendor, model, firmware version, supported algorithms)
VPN concentrators (IKEv2 configuration, key exchange algorithms)
Database encryption (TDE keys, column-level encryption)
File-level encryption (BitLocker, LUKS, VeraCrypt)
Email encryption (S/MIME certificates, PGP keys)
Code signing certificates and keys

Phase 5: Third-Party and Vendor Assessment

Your supply chain uses cryptography too. Document:

SaaS providers and their encryption practices
API integrations and their TLS configurations
Payment processors and their PCI cryptographic compliance
Identity providers (SAML signing keys, OAuth/OIDC token signing)
Inter-company VPN tunnels

Send a standardized questionnaire to critical vendors asking:

What cryptographic algorithms do you use for data in transit and at rest?
What is your timeline for PQC migration?
Do you support hybrid key exchange today?
Can you provide a CBOM (Cryptography Bill of Materials)?

Prioritization Framework

Once you have a complete inventory, prioritize migration using these criteria:

Priority 1: Harvest-Now-Decrypt-Later Targets

Long-lived secrets (encryption keys, classified data)
Data in transit over public networks using RSA or ECDH key exchange
Data that must remain confidential for 10+ years
Government, healthcare, and financial data subject to regulatory requirements

Priority 2: Public-Facing Authentication

TLS certificates on internet-facing services
Code signing certificates
API authentication using RSA or ECDSA signatures
Email signing certificates

Priority 3: Internal Infrastructure

Internal TLS/mTLS
VPN tunnels
Database encryption
Internal certificate authorities

Priority 4: Low-Risk or Short-Lived

Session tokens (already short-lived)
Symmetric encryption (AES, ChaCha20 are quantum-safe at sufficient key sizes)
Hash functions used for integrity (SHA-256 and above are quantum-safe)
Ephemeral authentication tokens

Building the Inventory Document

Structure your inventory as a living document or database. A spreadsheet works for small organizations. Larger enterprises should use a dedicated tool or CMDB integration.

Recommended columns:

Field	Example
Asset ID	CRYPTO-001
System	Payment Gateway
Algorithm	RSA-2048
Purpose	TLS key exchange
Quantum-vulnerable	Yes
Data sensitivity	High (PCI)
Confidentiality lifetime	7 years
Priority tier	P1
Owner	Platform team
Migration status	Not started
Target algorithm	ML-KEM-768
Target date	Q1 2027

Maintaining the Inventory

A cryptographic inventory is not a one-time exercise. Build ongoing processes:

CI/CD integration: Add cryptographic scanning to your build pipeline. Flag new RSA or ECDSA usage in code review.
Certificate monitoring: Alert on certificates approaching expiration and track algorithm types.
Quarterly reviews: Review the inventory with security and engineering leads.
Vendor reassessment: Re-evaluate third-party cryptographic posture annually.
CBOM generation: Automate CBOM generation and publish it as part of your SBOM (Software Bill of Materials) process.

Tools Summary

Tool	Type	Cost	Best For
IBM cbomkit-theia	Code scanner	Free/OSS	Generating CycloneDX CBOMs
Cryptosense Analyzer	Runtime analysis	Commercial	Enterprise Java applications
CodeQL	Static analysis	Free (GitHub)	Custom crypto pattern detection
testssl.sh	TLS scanner	Free/OSS	Endpoint cipher suite discovery
sslyze	TLS scanner	Free/OSS	Bulk TLS scanning
Venafi	Certificate management	Commercial	Enterprise certificate lifecycle
cert-manager	Kubernetes certs	Free/OSS	K8s certificate inventory
AWS Config / Security Hub	Cloud inventory	Pay-per-use	AWS crypto configuration audit

Frequently Asked Questions

How long does a cryptographic inventory typically take?

For a mid-size organization (50 to 200 services), expect 4 to 8 weeks for an initial inventory using automated tools plus manual review. The automated scanning phase takes days; the manual discovery of hardware, third-party services, and undocumented systems takes weeks.

Do I need to inventory symmetric algorithms like AES?

Yes, but they are lower priority for PQC migration. AES-128 and AES-256 are not broken by quantum computers (Grover’s algorithm only halves the effective key length), so AES-256 remains safe. Include them in the inventory for completeness and to identify any weak symmetric algorithms (DES, 3DES, RC4) that should be retired regardless.

What if we cannot scan a legacy system?

Document it as “unknown crypto, pending assessment” with the highest available information: vendor name, approximate deployment date, network exposure. Legacy systems often use the oldest and most vulnerable algorithms, so treat unknown systems as high priority until proven otherwise.

Is a spreadsheet sufficient or do I need dedicated tooling?

A spreadsheet works for organizations with fewer than 100 cryptographic assets. Beyond that, you need something searchable and automatable. Options include CMDB integration (ServiceNow, Jira), a dedicated tool like Cryptosense or InfoSec Global AgileSec, or a custom internal database.

How does a CBOM relate to an SBOM?

A Cryptography Bill of Materials (CBOM) is a specialized extension of the Software Bill of Materials (SBOM). While an SBOM lists software components and dependencies, a CBOM specifically documents the cryptographic algorithms, protocols, and keys used by those components. The CycloneDX standard (version 1.6+) includes a crypto extension for this purpose.

Should we inventory cryptography in development and test environments?

Yes, but at lower priority. Dev and test environments often mirror production configurations and can reveal what algorithms production is using. They are also useful for testing PQC migration without production risk.

What about embedded devices and IoT?

Embedded devices are often the hardest to inventory and the hardest to migrate. Document the firmware version, the cryptographic library embedded in it, and whether the device supports firmware updates. Devices that cannot be updated represent a replacement cost in your migration budget.

Sources

NIST IR 8547: Transition to Post-Quantum Cryptography Standards — Federal timeline and migration guidance explicitly calling out cryptographic discovery as the starting point
NIST NCCoE: Migration to Post-Quantum Cryptography Project — NIST guidance on PQC migration planning including inventory requirements
CISA: Quantum-Readiness guidance for critical infrastructure — Inventory-first approach for critical infrastructure organizations
CycloneDX: Cryptography Bill of Materials (CBOM) — Standard format for documenting cryptographic assets (v1.6+)
IBM cbomkit-theia: Cryptographic Bill of Materials scanner — Open-source tool for generating CycloneDX CBOMs from source code
NIST FIPS 203: ML-KEM Standard — Target algorithm for key exchange migration