Cryptographic Inventory Worksheet.
A working register for cryptography across applications, infrastructure, firmware, certificates, and third-party services.
The foundation of every other PQC decision. Without a current inventory, no meaningful priority ranking is possible — and any vendor proposal that promises to "solve" the problem before you've inventoried it should be treated skeptically. Thirteen columns. Three-axis priority scoring. Dropdown validation on the volatile fields.
Discovery is the first real control.
The PQC migration is a sequencing problem. Sequencing requires a list of things to sequence. Before any algorithm decision, hybrid pilot, vendor pressure, or board ask, you need a working register of where cryptography actually lives in your estate — including the dependencies buried in libraries, firmware, managed services, and third-party platforms that nobody on the architecture team has touched in three years.
The brief framing: most working registers for mid-market organizations contain about forty rows, sorted into three priority tiers. P1 — long-lived data on internet-facing high-trust systems (CA, VPN, code-signing, identity) — usually five to fifteen rows. P2 — everything internet-facing that does not meet P1. P3 — internal-only and short-lived. Treat the register as a living document under change control, not a one-time snapshot. Cryptography is independently updated by different teams and vendors; a snapshot becomes stale within a release cycle.
What goes in each row.
Each row in the register is a cryptographic dependency — a TLS endpoint, a signing pipeline, a VPN concentrator, a firmware update channel, a code-signing CA. The thirteen columns capture identity, function, current algorithm, three risk axes, vendor readiness, derived priority, evidence, and audit trail.
| Column | Values / format | Rationale |
|---|---|---|
| System / Service Name | Free text | Identification — what you'd call it in a change ticket. |
| System Owner | Free text | Accountability — the team or named individual. |
| Crypto Function | Key establishment · Signature · Hash · Symmetric · Mixed | Determines which FIPS standard applies. |
| Algorithm(s) in Use | RSA-2048 · ECDH P-256 · X25519 · AES-256 · etc. | Baseline. The thing you're going to replace. |
| Data Longevity | <1 yr · 1–5 yr · 5–10 yr · >10 yr | Drives HNDL risk score. Long-lived data is exposed today. |
| External Exposure | Internet-facing · Partner · Internal-only | Drives downgrade and interception risk. |
| Trust Role | CA · Root trust · Signing pipeline · Standard | High-trust systems move first. |
| PQC Vendor Status | Available now · Roadmap · Unknown · Not applicable | From vendor query. Reviewed quarterly. |
| Migration Priority | P1 · P2 · P3 | Derived from longevity + exposure + trust role. |
| CNSA 2.0 Deadline | Jan 2026 available · Jan 2027 preferred · 2030 required · 2031 required | Per CNSA 2.0 milestones. Useful for procurement justification. |
| Hybrid Supported | Yes · No · Unknown | Required for the transition phase. |
| Dependencies | Free text | What breaks if this moves first. Architecture risk. |
| Notes / Discovery Method | Free text | Audit trail — how this row was discovered, who confirmed it, when. |
Four passes, four sources.
No single discovery method captures everything. Run all four passes; cross-reference the results; treat any single-source row as provisional until at least one other method confirms it.
Discovery methods
- Network probe.
openssl s_client -connect host:portand equivalent tools surface cipher suites on exposed endpoints. Internal certificate inventories surface the PKI surface. Egress allow-list audits surface outbound TLS dependencies. - Code and config scan. Grep for algorithm names (
RSA,ECDH,ECDSA,X25519,secp256r1,rsa-sha256) across repositories, Helm charts, Terraform, Ansible playbooks, and CI/CD pipelines. Hard-coded algorithms are the largest single source of crypto-agility friction. - Vendor query. A standard letter or RFP question: which FIPS standard does this product implement, what is the version and date, what is the hybrid story, what is the rollback path. See the Vendor RFP Rubric for the scored question set.
- Cloud-provider audit. Each cloud exposes TLS, KMS, and HSM configuration differently. AWS KMS, Azure Key Vault, and GCP Cloud KMS each have PQC support that varies by service and region. Confirm the workload, not the platform.
Review cadence
- Quarterly: the PQC Vendor Status column. Vendor roadmaps move on quarterly product-management cycles.
- Annually: full register pass. Re-confirm system ownership, data longevity classification, and trust role assignments.
- Triggered: any time a vendor announces general availability of PQC for a previously unready product, CISA updates its category list, or a major library version changes.
The three-axis derivation.
Migration Priority is not a free-text field. It is derived from three other columns. The XLSX includes the formula and validates the result; the table below shows the logic in plain form.
| Data Longevity | External Exposure | Trust Role | Priority |
|---|---|---|---|
| Long-lived (>5 yr) | Internet-facing | High trust (CA / VPN / signing) | P1 |
| Long-lived (>5 yr) | Internal only | High trust | P1 – P2 |
| Short-lived (<5 yr) | Internet-facing | Standard | P2 |
| Short-lived (<5 yr) | Internal only | Low trust | P3 |
Why this order
- Longevity first. HNDL risk is a function of confidentiality lifetime. Data that must remain confidential past the CNSA 2.0 inflection (2027–2031) is at risk today regardless of where it lives.
- Exposure second. An internet-facing endpoint is observable to an HNDL adversary; an internal-only endpoint generally is not (modulo insider risk and lateral movement scenarios).
- Trust role third. A compromised CA cascades into every certificate it ever signed. A compromised standard service does not.
For the editorial framing on why inventory comes first, see the IT Technicians briefing and the Executives briefing. For the structural exposure-class analysis, see the Active Research note. The next tool in the sequence is the Vendor RFP Rubric — use it the next time you go out to procurement on a row from the inventory.