Cryptographic Inventory

How to Build a Cryptographic Inventory for PQC Migration Planning

Step-by-step guide to building a cryptographic inventory for PQC migration. Covers external discovery, internal scanning, vendor mapping, risk classification, and CBOM generation.

How to Build a Cryptographic Inventory for PQC Migration Planning

A cryptographic inventory is the foundation of every PQC migration. Without it, you cannot prioritize systems, estimate effort, engage vendors, or report to leadership. This is a step-by-step guide to building one — from external discovery to CBOM generation. For related context, see cryptographic inventory and CBOM work.

Step 1: External Discovery (Day 1)

Start with what is publicly visible. Run an external cryptographic posture assessment on every domain your organization owns.

For each domain, CipherReady automatically collects:

TLS certificate: subject, issuer, public key algorithm, key size, signature algorithm, validity period, SAN entries
DNS records: A, AAAA, MX, CNAME, TXT
HTTP security headers: HSTS, CSP, X-Frame-Options, X-Content-Type-Options, Referrer-Policy, Permissions-Policy
TLS version and cipher suite negotiated

Export this data into a structured inventory. This is your public-facing cryptographic baseline. It typically takes under an hour for a full domain portfolio. For related context, see crypto agility planning.

Step 2: Risk Classification (Day 2-3)

For every certificate discovered, assign a quantum risk tier:

Critical: RSA-2048 or ECC P-256, protecting regulated data (PII, PHI, PCI), with 10+ year confidentiality requirement
High: RSA-2048 or ECC P-256, public-facing, protecting customer data
Medium: RSA-4096 or ECC P-384, internal-facing, or protecting non-regulated data
Low: AES-256 protected, short-lived data, or public content

Add data sensitivity context: What data does this certificate protect? What is its confidentiality lifetime? Who owns the migration decision (internal team or vendor)?

Step 3: Cloud KMS Inventory (Day 3-4)

Log into each cloud provider console and export all KMS keys:

AWS KMS: aws kms list-keys and aws kms list-aliases
Azure Key Vault: Portal → Key Vault → Keys
GCP Cloud KMS: gcloud kms keys list

Document the algorithm, key purpose (encryption vs signing), and rotation policy for each key. Note which keys protect regulated data.

Step 4: Internal Discovery Planning (Week 2)

External discovery covers public-facing posture. Internal discovery covers everything behind the perimeter. Prioritize internal discovery for:

Systems handling regulated or long-lived data
Services with known RSA or ECC dependencies
Applications with embedded cryptographic libraries

For internal discovery, you may deploy agent-based tools (Keyfactor AgileSec, IBM Quantum Safe Explorer) or passive network monitoring (CipherInsights). CipherReady focuses on the external layer, which is the fastest starting point.

Step 5: Vendor Dependencies (Week 2-3)

Every SaaS platform, cloud provider, and API vendor that handles your data has cryptographic dependencies you do not directly control. For each critical vendor:

Document which data they handle
Assess whether they expose a TLS endpoint you can evaluate externally
Send a structured PQC readiness questionnaire
Classify vendor risk: Critical (no roadmap), High (roadmap without timeline), Medium (specific timeline), Low (PQC migration active) For related context, see cryptographic inventory planning.

Step 6: Consolidate and Generate CBOM (Week 3-4)

Merge data from all discovery sources into a unified Cryptographic Bill of Materials. A CBOM in CycloneDX 1.6 format captures:

Every algorithm, key size, and certificate
Protocol configurations
Asset-to-data sensitivity mappings
Vendor dependencies
Discovery method for each asset

Tools like IBM CBOMkit and AppViewX AVX PQC can generate CycloneDX CBOM from structured inventory data. Your external inventory from CipherReady feeds directly into the certificate and protocol sections.

Step 7: Migration Roadmap (Week 4)

With a complete CBOM in hand, build a prioritized migration roadmap:

Critical assets first: regulated data, long confidentiality lifetimes, public-facing
Group by dependency: shared libraries, shared certificates, vendor coupling
Identify quick wins: expired certificates to decommission, RSA-2048 to RSA-4096 interim upgrades, TLS 1.0/1.1 endpoints to retire
Estimate effort per migration group: reissuance, reconfiguration, code changes, vendor coordination
Set milestone timeline with quarterly review checkpoints

FAQ

Q: How long does a complete inventory take? A: External discovery: 1 day. Risk classification: 2-3 days. Cloud KMS audit: 1 day. Vendor assessment: 2-3 weeks (waiting for responses). CBOM generation: 1 week. Total: 4-6 weeks for a comprehensive first pass.

Q: What if I have hundreds of domains? A: CipherReady processes domains rapidly. Start with the domains handling the most sensitive data. Group subdomains under parent domains for efficiency.

Q: Is external discovery enough, or do I need internal scanning too? A: External discovery is the fastest and safest starting point and covers what auditors, regulators, and attackers can see. For regulated industries with sensitive internal systems, complement with internal discovery for high-priority assets.

Start Free Readiness Scan →