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