A cryptographic inventory is a maintained record of where cryptography is used, for what security purpose, with which algorithms and dependencies, and under whose ownership. It includes more than TLS certificates. Applications rely on encryption, signatures, key establishment, hashing, tokens, code signing, device identity, database protection, backups and supplier services. A useful inventory connects each cryptographic instance to data life, protocol, implementation, key-management path and migration constraint so teams can prioritize change rather than produce a long unowned scanner export.
The need is immediate because NIST finalized its first post-quantum standards in 2024 and recommends starting migration now. NIST NCCoE’s migration project separates cryptographic discovery from interoperability testing, while CISA has published a strategy for moving toward automated discovery and inventory. Inventory also supports ordinary certificate incidents, deprecated algorithms and library vulnerabilities. This FAQ explains scope, evidence, quality and operating ownership.
What should a cryptographic inventory contain?
Record service and owner, environment, business purpose, protected data or action, algorithm and parameter, protocol, library or device, key source, certificate authority, expiry or rotation, endpoint, supplier and evidence source. For public-key cryptography, distinguish key establishment from digital signature because migration algorithms and consequences differ. Record data confidentiality life: information that must remain secret for many years may deserve earlier attention than short-lived public telemetry.
Include cryptography at rest, in transit and in software supply chains. Search application code, configurations, API gateways, load balancers, service meshes, identity providers, databases, storage, backup tools, HSMs, firmware, mobile apps, CI/CD, artifact signing, package managers and third-party SaaS. Include embedded and unsupported systems. A supplier saying “industry-standard encryption” is not inventory data; require algorithm, protocol, roadmap and update mechanism at an appropriate level of detail.
| Inventory field | Example | Why it matters |
|---|---|---|
| Purpose | TLS server authentication | Selects replacement primitive and test |
| Implementation | Library, appliance or managed service | Identifies change authority |
| Key path | HSM, KMS, file or embedded secret | Reveals rotation and access constraints |
| Data life | Seven-year confidentiality | Prioritizes harvest-now-decrypt-later exposure |
| Dependency | Client, partner or device protocol | Defines interoperability sequence |
| Evidence | Config scan, traffic, code or attestation | Supports confidence and refresh |
How is cryptography discovered across a large estate?
Use multiple methods because no single scanner sees every layer. Static analysis finds API calls and constants in code. Configuration and certificate scans find deployed settings. Network observation identifies negotiated protocols and algorithms. Package and binary analysis reveals embedded libraries. Cloud APIs and HSM records identify managed keys. Interviews and architecture review expose business purpose, offline processes and supplier use. Normalize findings into one schema while preserving the evidence and observation time.
Automated discovery produces candidates, not truth. A code call may be unreachable; a network capture may miss seasonal traffic; a certificate scan may not reveal a signing workflow; a package may include an unused algorithm. Reconcile by service owner and sample high-consequence findings. Track coverage boundaries and blind spots such as mobile binaries, appliances and partner connections. Use stable service, repository, asset and certificate identifiers to deduplicate observations without merging distinct uses.
How should findings be assessed and prioritized?
First classify current weakness: prohibited or deprecated algorithms, unsafe parameters, expired certificates, unmanaged keys, shared secrets, missing rotation or unsupported libraries. Then assess quantum migration exposure. Public-key algorithms based on factoring or discrete logarithms are the principal concern; symmetric and hash algorithms have different quantum considerations and may require parameter review rather than the same replacement. Use current standards and organizational policy, not a generic red-yellow label.
Prioritize by consequence, data life, external exposure, scale, dependency and replacement difficulty. A private certificate expiring tomorrow may outrank a long-term PQC migration item operationally, while a public-key mechanism protecting long-lived confidential archives may outrank a low-impact web endpoint strategically. Separate urgency from effort. Group findings into migration units that share protocol and dependency, then identify the lead party and earliest safe test environment.
Who owns the inventory and how is it kept current?
Security should define the schema, policy and assurance, but service owners must confirm purpose and impact. Platform teams can automate cloud, certificate and build evidence. Procurement and supplier management cover external products. Data owners set confidentiality life. Assign one accountable inventory product owner who resolves duplicates, measures coverage and publishes change queues. Do not create a spreadsheet that only one cryptography specialist can interpret.
Update inventory at architecture review, dependency change, certificate issuance, deployment and supplier renewal. Feed observations from CI/CD, asset systems, certificate managers and network sensors, but require owner review for meaningful changes. Track last observed and last confirmed dates separately. Alert on unsupported algorithms, missing owners and upcoming expiry. Retain history so investigators can answer what protected a service at a past date.
| Quality check | Pass condition | Correction |
|---|---|---|
| Coverage | Critical services have multiple evidence sources | Add targeted code, config or traffic discovery |
| Ownership | Every material use has accountable service owner | Map orphan finding to service catalog |
| Purpose | Protection goal and data life are known | Interview owner and data steward |
| Freshness | Observation fits system change rate | Automate refresh trigger |
| Actionability | Finding maps to migration unit and test | Add dependency and replacement path |
| History | Past algorithm and key state can be reconstructed | Version records and preserve evidence |
How does inventory become a migration roadmap?
Group dependencies by protocol and ecosystem: TLS termination and clients, enterprise PKI, code signing, document signatures, VPN, secure email, device updates and supplier APIs. Identify standards and product support for each. Build crypto-agile interfaces where algorithms and providers can change without rewriting business logic. NIST CSWP 39 describes crypto agility as capabilities and practices that enable cryptographic mechanisms to be replaced while preserving operations. It is an engineered property, not a configuration flag.
Pilot in a controlled path with representative payload, latency, certificates, clients and failure behavior. Measure compatibility, performance, message size, key lifecycle, logging and rollback. Hybrid designs may combine classical and post-quantum mechanisms during transition, but they add protocol and operational complexity and must follow defined standards. Update the inventory with deployed mode and evidence. A migration is not complete when a library supports PQC; every communicating party and operating process must use and monitor the intended configuration.
Worked example: discovering a customer API’s cryptographic dependencies
A customer API appears to use one public TLS certificate. Discovery finds five distinct dependencies: the edge terminates TLS, the identity provider signs access assertions, services use workload certificates, the build system signs containers and a partner encrypts nightly exports with a long-lived public key. Code scanning finds libraries, cloud APIs find certificates and keys, network observation confirms negotiated protocols, and owner interviews explain purpose and data life. The records are linked to one service but remain separate migration uses.
Assessment prioritizes the export because its contents must remain confidential for ten years and the partner has a long upgrade cycle. Edge TLS has broad exposure but shorter data life and a managed provider roadmap. Code signing has long trust implications and device verifiers that cannot all update together. The team assigns three migration units, names owners and records test environments. It also fixes an unrelated expiring intermediate certificate found during discovery, demonstrating that inventory creates immediate operational value.
A quarterly reconciliation later shows a new analytics connector negotiating an older protocol and a serverless function embedding a cryptographic library outside the standard build. Both are linked to deployment events and sent to service owners for confirmation. Coverage metrics show that critical services have network and configuration evidence but mobile binaries remain a blind spot, so the next discovery investment targets release artifacts rather than buying another endpoint scanner. Confidence grows from explained coverage, not from claiming perfect detection.
The inventory team publishes a small quality scorecard by service tier. It reports confirmed ownership, evidence diversity, freshness, known blind spots and percentage of findings attached to a migration unit. It does not report a misleading universal completion percentage. High-consequence services require an owner review after material protocol or supplier changes, while lower-tier systems use automated refresh plus sampled validation. Records that cannot yet identify purpose remain visible as unresolved risk instead of being discarded as scanner noise.
When two tools disagree, the record preserves both observations, their time and confidence until an owner resolves the deployed state. This prevents normalization from manufacturing false certainty and gives the next investigation a traceable starting point.
Key takeaways
- Cover protocols, applications, keys, libraries, hardware, suppliers and software signing.
- Combine code, configuration, network, asset and owner evidence.
- Prioritize by consequence, data life, exposure and migration dependency.
- Assign shared governance with accountable service-owner confirmation.
- Turn findings into tested protocol-level migration units and keep history.
Frequently asked questions
Is an SBOM a cryptographic inventory?
No. An SBOM can reveal components that implement cryptography, but usually does not show deployed configuration, purpose, key path, protocol negotiation or external dependencies. It is one discovery input.
Can a TLS scanner provide the inventory?
No. It covers reachable endpoints and negotiated options at one time. It misses at-rest encryption, signing, internal traffic, dormant paths, libraries, keys and supplier products.
How often should the inventory be refreshed?
Use event-driven updates plus periodic reconciliation. Fast-changing services may need continuous observations; stable appliances may use scheduled review. Critical records should be confirmed after material architecture, library or certificate changes.
Conclusion
A cryptographic inventory is valuable when it explains how a business service depends on cryptography and what must change safely. Build it from multiple evidence sources, attach ownership and preserve uncertainty. That foundation supports certificate operations today, crypto agility over time and a defensible transition to post-quantum standards.