How to Perform a Cryptographic Inventory: A Discovery Method Field Guide

Almost every post-quantum migration guidance document published since 2022 opens with the same instruction: inventory your cryptography. A cryptographic inventory is a record of which cryptographic algorithms are in use across an organisation, where they run, what data they protect, and how long that data has to stay protected. Building one means finding cryptography that nobody documented, in systems nobody owns, running in libraries nobody chose.

Most guidance stops at “do an inventory.” This piece starts one layer down, at the question an engineer actually faces on day one: which discovery method finds which cryptography, and what does each one miss?

Nine methods are described below, each with what it sees, what it cannot see, and what it costs to run. Then the layering: how to combine them so the gaps do not overlap. Then the constraints that decide the sequence in a real environment, and the record the findings turn into.

The Distinction That Organises Everything

Before any tool discussion, one distinction, because it determines how every finding gets read.

There is a difference between capability and usage. Capability means a cryptographic algorithm is present and could run. Usage means it ran, in production, protecting real data.

A static code scan of an application finds that it links OpenSSL. OpenSSL implements dozens of algorithms, including several that were deprecated a decade ago. The scan reports capability. It does not tell you whether the application ever calls the 3DES path. A network sensor watching that same application’s traffic sees the TLS handshake and records the negotiated cipher suite. That is usage, observed once, on the connections the sensor happened to see.

Neither reading is wrong. They answer different questions. Capability findings tell you what could break if a configuration changes, what your exposure is if an attacker downgrades a connection, and what your remediation scope is if you have to remove a library version. Usage findings tell you what is happening right now and what will break if you change it.

An inventory built only from capability data over-reports: it flags every algorithm every library supports, produces a list nobody can act on, and buries the four things that genuinely matter. An inventory built only from usage data under-reports: it misses the code path that only executes during the quarterly batch run, the fallback cipher that only activates when the primary handshake fails, and the encryption in the disaster recovery system that has not been exercised since the last test.

The methods below split roughly along this line. Design the layering so that both columns get filled.

Nine Discovery Methods

Static Code Analysis

Parses source code without running it, looking for calls into cryptographic libraries, hard-coded keys, algorithm constants, and configuration strings.

Finds: every cryptographic call site in code you own, including the ones on paths that rarely execute. Hard-coded keys and initialisation vectors. Algorithm selection logic. Deprecated function calls that a runtime observation would never catch because that branch has not run since 2019.

Misses: anything invoked through reflection, dynamic dispatch, or configuration-driven library loading. Cryptography in dependencies whose source you do not have. Anything in a compiled third-party component. And it cannot tell you which of the call sites it found actually run.

Costs: access to source repositories, which is usually an organisational negotiation rather than a technical one. Language coverage matters – a scanner strong on Java may be weak on COBOL, and the COBOL is where the interesting findings live. Expect a false-positive rate high enough that someone has to triage the output; that triage is the real cost, not the scan.

Reads as: capability, almost entirely.

Dynamic Analysis and Runtime Monitoring

Instruments a running application to log cryptographic operations as they happen – hooks into the crypto library, an agent watching syscalls, or a runtime with cryptographic auditing enabled.

Finds: what actually ran. Algorithm, key size, mode, and the caller. Cryptography chosen at runtime based on data or configuration, which static analysis cannot resolve. This is the cleanest usage signal available.

Misses: anything that did not execute during the observation window. If you monitor for two weeks and the month-end reconciliation job uses PGP, you learn nothing about PGP. Code paths behind error handling, failover, and rarely-triggered business logic stay invisible.

Costs: the highest of any method. Instrumentation touches production. Performance overhead is real. Getting approval to attach an agent to a payment authorisation service is a conversation with several people who will say no first. Plan the observation window around the business calendar, not the project calendar.

Reads as: usage, definitively.

Passive Network Traffic Analysis

A sensor on a network tap or span port reads copies of traffic and records protocol handshakes: TLS version and negotiated cipher suite, SSH key exchange, IPsec proposals, and unencrypted protocols that should not be there.

Finds: cryptography in transit, as negotiated, across everything that crosses the monitored segment. It finds services nobody documented, because they show up in the traffic. It finds the TLS 1.0 endpoint that three teams swore had been decommissioned.

Misses: anything at rest. Anything inside an encrypted tunnel. Anything on a segment you are not monitoring, which in most enterprises is most segments. It sees the handshake, not the application-layer cryptography running above it.

Costs: low operationally, high logistically. The sensor touches nothing, injects no packets, and cannot disrupt a production system – which is why it is the default first move in sensitive environments. The cost is getting tap or span access on enough segments to matter, and that is a network engineering project with its own timeline.

Reads as: usage, but only for network-visible cryptography.

Configuration and System Scanning

Reads operating system settings, application configuration files, cryptographic policy files, and installed component manifests. On Linux, that is the system-wide crypto policy, OpenSSL configuration, and SSH daemon settings. On Windows, registry policy, Schannel configuration, and the certificate store.

Finds: what a system is permitted to negotiate, which is often broader than what it does negotiate. Installed library versions. Presence of a Trusted Platform Module (TPM) or a configured hardware security module (HSM). Cipher suite allow-lists and their gaps.

Misses: application-level cryptography that ignores system policy, which is common – a Java application with its own security provider configuration does not care what the OS crypto policy says. And it tells you nothing about usage.

Costs: requires read access on every host, which means credentials, which means a scoped service account and an approval chain. Technically cheap once access exists; scriptable across a fleet.

Reads as: capability, and specifically the outer bound of capability.

Dependency and Binary Analysis

Examines compiled artifacts and dependency manifests. On the dependency side, that is reading package manifests and lock files to identify cryptographic libraries and versions. On the binary side, it means scanning executables for algorithm constants, function symbols, and library signatures.

Finds: cryptography in third-party software where no source exists. Statically linked library versions that dependency manifests do not show. Bundled copies of OpenSSL inside vendor appliances.

Misses: obfuscated or packed code. Custom cryptographic implementations that do not match known signatures. And it produces capability findings with an unusually wide gap between capability and usage, because a bundled library’s full algorithm set gets reported whether or not the vendor product exposes it.

Costs: dependency scanning is nearly free if a software composition analysis pipeline already exists. Binary analysis is specialist work with a specialist’s day rate.

Reads as: capability, with the widest capability-to-usage gap of any method.

Cloud and Infrastructure Scanning

Queries cloud provider APIs for encryption configuration: managed key service inventories, storage encryption settings, database encryption state, managed TLS certificate configuration on load balancers, and infrastructure-as-code templates that define any of the above.

Finds: encryption-at-rest state across managed services. Key material held in provider key management services, with algorithm and key size. Load balancer TLS policy, which is where a surprising amount of an organisation’s external cryptography actually lives. Infrastructure-as-code definitions catch configuration before it deploys.

Misses: cryptography inside workloads. A container encrypting a field before writing it to a managed database is invisible to the cloud control plane. Provider-internal cryptography that the API does not expose.

Costs: read-only API access per account or subscription, and in a large organisation there are more accounts than anyone believes. Each provider needs its own tooling. Scanning infrastructure-as-code repositories folds into the static analysis effort.

Reads as: a mix – configuration state is capability, but for managed encryption at rest, capability and usage are close to identical.

Firmware and Hardware Analysis

Examines embedded device firmware for cryptographic implementations: secure boot verification, firmware signing, device identity certificates, and hardcoded keys.

Finds: cryptography in devices with no other interface. Signature algorithms in secure boot chains, which matter for post-quantum planning because a device that verifies firmware with an RSA-2048 signature cannot be field-upgraded to a post-quantum root of trust unless the hardware supports it.

Misses: nearly everything, unless you have firmware images and the expertise to analyse them. Most organisations have neither.

Costs: the highest expertise cost of any method. For most environments, the practical substitute is vendor engagement: ask the manufacturer for a cryptographic attestation or a bill of materials covering the device. This works better than it used to. Manufacturers facing the same regulatory pressure are increasingly prepared to answer.

Reads as: capability, and often the most consequential capability findings in the whole inventory, because embedded cryptography is the hardest to change.

Certificate and Key Discovery

Enumerates X.509 certificates and key material across the estate: certificate authority databases, keystores, filesystem scans for key files, network scans that collect served certificates, and Active Directory certificate templates.

Finds: signature algorithm, key algorithm, key size, validity window, and issuer for every certificate found. This is the single richest source of quantum-vulnerability data in most environments, because certificates are where public-key cryptography is most concentrated and most legible. Also finds expired certificates still deployed, self-signed certificates in production, and certificates issued from authorities nobody knew existed.

Misses: keys not in certificate form – SSH host keys and user keys, symmetric keys, application-level signing keys, API tokens derived cryptographically. Some of these need their own sweep.

Costs: moderate, and it has the best return of any method for the effort. A certificate discovery sweep is often the fastest route to a defensible first cut of the quantum-vulnerable inventory.

Reads as: both. A deployed certificate is capability and usage at once.

Log Analysis

Mines existing logs for cryptographic events: TLS handshake failures, deprecation warnings, protocol negotiation records, and certificate validation errors.

Finds: cryptography that failed, which is often more informative than cryptography that worked. A handshake failure log naming a rejected cipher suite tells you a client somewhere still wants that suite. Deprecation warnings in application logs identify libraries about to become problems.

Misses: everything that worked silently, which is most of it.

Costs: near zero if log aggregation already exists. This is the cheapest method on the list and the most commonly skipped.

Reads as: usage, in negative – it shows you what was attempted.

What Each Method Costs, Side by Side

Method	Signal	Touches production	Effort	Best for
Static code analysis	Capability	No	High triage load	Code you own
Runtime monitoring	Usage	Yes	Highest	Confirming what runs
Passive network	Usage	No	Low tech, high logistics	Unknown services, in-transit crypto
Configuration scanning	Capability	Read-only	Low, once access exists	Policy bounds, installed versions
Dependency and binary	Capability	No	Low to specialist	Third-party software
Cloud scanning	Mixed	No	Low per account, many accounts	Encryption at rest, load balancer TLS
Firmware	Capability	Varies	Specialist, or vendor request	Embedded and OT devices
Certificate discovery	Both	Read-only	Moderate, high return	Quantum-vulnerable public key
Log analysis	Usage, negative	No	Near zero	Failures, deprecation warnings

Layering: Making the Gaps Not Overlap

No method covers everything. That claim gets made in every inventory guide and then rarely turned into practical advice. Here is the practical version: pair methods so that one produces capability findings and the other tests them.

Pair static analysis with runtime monitoring. The scan produces the full set of call sites. The monitor confirms which ones execute. Findings present in both are high-confidence usage. Findings only in the scan go on a list marked “capability, unconfirmed,” which is where the quarterly batch job’s PGP call will sit until someone runs the batch during the monitoring window.

Pair passive network monitoring with configuration scanning. Configuration tells you a server will accept TLS 1.0 through 1.3 with fourteen cipher suites. Network monitoring tells you clients only ever negotiate two of them. The gap between the two is your downgrade exposure, and it is a genuine finding: the configuration permits something no legitimate client needs.

Pair certificate discovery with cloud scanning. Certificate sweeps find what is deployed on hosts. Cloud API queries find what is deployed on managed load balancers and content delivery endpoints. In most cloud-heavy organisations, the second set is larger than anyone expects, and it is the set with public exposure.

Pair dependency analysis with binary analysis on vendor software. Dependency manifests show declared components. Binary scanning shows what actually shipped, including the statically linked OpenSSL that the manifest does not mention.

Deliberate overlap is a feature. When two independent methods report the same finding, confidence rises. When they disagree, that disagreement is itself a finding – usually it means a system was reconfigured and the documentation was not.

A Worked Example

The following is illustrative, constructed to show how findings from different methods combine. It is not drawn from a specific engagement.

A payments gateway, seven services, running in a cloud environment with an on-premises hardware security module for key storage.

Certificate discovery returns 41 certificates on the gateway’s hosts and load balancers. Thirty-eight use RSA-2048 signing keys with SHA-256 signatures. Three use ECDSA P-256. All 41 are quantum-vulnerable. That is the headline number, available in a week.

Cloud scanning finds eleven more certificates on managed load balancers that the host sweep never touched, plus a TLS policy on the public endpoint permitting TLS 1.2 with an RSA key exchange cipher suite – not just RSA certificates, but RSA key transport, which means no forward secrecy on any session that negotiates it.

Passive network monitoring on the public segment records two weeks of handshakes. No client ever negotiates the RSA key exchange suite. The exposure is real but latent: it activates on a downgrade, not in normal operation. That reframes the fix from urgent to scheduled.

Static analysis of the seven services finds 63 cryptographic call sites. Most are library-mediated TLS. Six are direct: two AES-GCM field encryption paths, one HMAC for internal request signing, one legacy 3DES path in a reconciliation module, and two RSA operations against the hardware security module.

Runtime monitoring over the same two weeks confirms 57 of the 63. The 3DES path does not fire. Neither do two of the HMAC sites.

Log analysis then closes it. The reconciliation module logs a 3DES operation on the last business day of the month, against an interchange file format one partner bank still requires. Runtime monitoring missed it because the window ended on the 24th.

Six methods. The last one, which cost nothing, found the item that would have been missed. And the combined picture is different from any single method’s picture: the urgent work is the 41 plus 11 certificates and the hardware security module integration, the scheduled work is the load balancer TLS policy, and the 3DES path is a partner-contract problem rather than an engineering problem.

The Constraints That Decide Sequence

Method selection is a technical question. Method sequence is an access-and-risk question, and it is usually the harder one.

Access. Static analysis needs repository access. Runtime monitoring needs deployment approval. Configuration scanning needs credentials on every host. Each of these is a separate approval path with a separate owner, and the paths run at different speeds. Start the slow ones first. Request repository access and agent deployment approval in week one, then run passive network monitoring and certificate discovery while those requests move through the queue. Sequencing by approval latency rather than by technical priority typically saves a quarter.

Existing systems reduce the ask. A configuration management database (CMDB) may already hold installed software versions. An endpoint management platform already has agents deployed and may support a query for cryptographic library versions without a new tool. A software composition analysis pipeline already parses dependency manifests. Reusing an installed agent is a configuration change; installing a new one is a project.

Production impact. The rule is straightforward: passive and agentless by default, active only with a specific justification and a tested procedure. Passive network monitoring on a tap injects nothing. Read-only configuration scanning through an existing management agent adds negligible load. Certificate collection from a network scan is a handshake and a disconnect.

Runtime instrumentation is the exception, and it earns its risk because it is the only definitive usage signal. Test it in staging first, measure the overhead, agree a rollback trigger with the service owner before deployment, and deploy during a low-traffic window.

Operational technology. Operational technology (OT) covers industrial control systems, SCADA, and plant-floor equipment, and it changes the calculus completely. In OT, availability outranks confidentiality, a scan that causes a controller to fault can stop a production line, and many devices predate the assumption that anything would ever scan them. Standard IT scanners can crash programmable logic controllers with malformed packets.

For OT the sequence is: passive network monitoring on a tap, vendor documentation request, and nothing else without the plant engineer’s explicit agreement and a tested procedure in a lab replica. Some OT segments will end the project with no direct discovery data at all, covered instead by vendor attestation and a documented risk acceptance. That is an acceptable outcome, recorded as such. An undocumented gap is not.

Scope discipline. Full coverage of every cryptographic operation in a large enterprise is a multi-year programme, and treating it as a single project is how inventories stall and get quietly abandoned.

Scope the first phase by threat model. Quantum-vulnerable cryptography means public-key algorithms broken by Shor’s algorithm: RSA, elliptic curve cryptography, and Diffie-Hellman, wherever they appear. Symmetric cryptography and hashing face a smaller quantum problem and are better handled in a second phase – unless a specific algorithm is already deprecated for classical reasons, in which case it belongs in phase one regardless.

That scoping decision needs to be written down, with its rationale, because in eighteen months somebody will ask why the AES inventory is incomplete and the answer needs to be a documented phase boundary rather than an oversight.

What the Findings Become

Discovery output arrives in incompatible formats from every method. The consolidation step turns that into a Cryptographic Bill of Materials (CBOM): a structured record of every cryptographic asset found, its attributes, and its context.

The name follows the Software Bill of Materials (SBOM), and the analogy holds. Where an SBOM lists software components and versions, a CBOM lists cryptographic algorithms, key material, certificates, and protocols, mapped to the systems using them. The CycloneDX SBOM standard added support for cryptographic assets, which means CBOM data can travel in a format that supply chain tooling already understands rather than in a spreadsheet nobody else can parse.

A workable schema needs, for every entry:

• Identity. Algorithm, key size, mode, protocol version.
• Location. The system, and inside it the file, endpoint, or configuration key.
• Evidence. Which method found it, and this field is the one most often left out. Without it, an unconfirmed scan result cannot be told apart from confirmed usage, and a remediation team has no basis for ranking the two. A finding tagged “runtime monitoring, observed 14,000 times” and a finding tagged “static scan, unconfirmed” are different findings and cannot be treated alike.
• Signal type. Capability or usage, per the distinction above.
• Owner. The team accountable for the system. Findings without an owner do not get remediated.
• Data context. What the cryptography protects, and how long that data must stay confidential.
• Status. Confirmed, needs verification, or vendor-attested.

The data context field is the one that turns an inventory into a prioritisation. Harvest now, decrypt later is the threat model where an adversary records encrypted traffic today and decrypts it once a cryptographically relevant quantum computer exists. Under that model, the urgency of any given quantum-vulnerable asset depends on how long its data must remain secret. Session tokens that expire in an hour are near-irrelevant. Medical records with a lifetime confidentiality requirement, protected today by RSA-2048 in transit, are the top of the list. Two systems using identical cryptography can sit at opposite ends of the priority order purely on data lifetime.

Some organisations model the CBOM as a graph rather than a table, on the grounds that cryptographic dependencies form chains – a certificate signed by an intermediate signed by a root, an application calling a library calling a hardware module. A graph makes those chains queryable. A table with foreign keys handles most of it. Do not let the data model debate delay the collection.

Handle the CBOM as sensitive. A complete map of where an organisation’s weakest cryptography lives is a target package. Access control it accordingly, and keep it out of the general document repository.

And treat it as living. An inventory compiled once decays from the day it is finished. The maintenance mechanism is process integration rather than periodic re-scanning: add a cryptographic declaration to the deployment checklist, run the code scanner in continuous integration, leave the passive network sensor in place so new services register themselves, and set a review cadence for the certificate sweep tied to the shortest certificate lifetime in the estate.

Where the Compliance Pressure Sits

The inventory requirement is written into regulation in several places, and the specific citations matter more than a general statement that regulators care.

In the United States, the Quantum Computing Cybersecurity Preparedness Act, signed in December 2022, requires executive agencies to inventory their quantum-vulnerable cryptographic systems. Office of Management and Budget Memorandum M-23-02 sets out how agencies do it and requires a prioritised inventory. Contractors and suppliers to federal agencies inherit the pressure downstream even where the statute does not bind them directly.

PCI DSS 4.0 requires organisations to enable only strong cryptographic protocols and to configure them correctly, and many organisations maintain an inventory of the cipher suites and protocols in use in order to meet that requirement and evidence it at assessment. Organisations in payments have a compliance driver independent of the quantum timeline.

The joint CISA, NSA, and NIST quantum-readiness guidance published in 2023 puts inventory creation first among its recommended immediate actions for critical infrastructure operators.

The pattern across all of them is the same: inventory before strategy, because a migration plan built on assumed cryptography plans for the wrong systems.

Getting Started This Month

For an engineer holding this task with no budget approved and no tooling procured, the first thirty days have a defensible shape.

Week one. Submit the slow access requests: source repositories, host credentials, network tap or span provisioning. Then start log analysis, because it needs nothing but the log platform that already exists. Grep for handshake failures, cipher deprecation warnings, and certificate validation errors.

Week two. Run certificate discovery. Scan the external attack surface for served certificates, pull the internal certificate authority database, and query cloud provider APIs for managed certificates. This produces the first defensible count of quantum-vulnerable assets, and it is the number leadership will ask for.

Week three. Configuration scanning through whatever endpoint management agent is already deployed. Query for cryptographic library versions and system crypto policy. No new tooling.

Week four. Passive network monitoring if the tap access came through, and the scoping document if it did not. The scoping document records what is in phase one, what is deferred, why, and which systems will be covered by vendor attestation rather than direct discovery.

Four weeks of work that touches no production system, needs no procurement, and produces a real inventory of the highest-value category. The expensive methods – runtime instrumentation, binary analysis, firmware work – come after that, aimed at the specific gaps the first four weeks exposed.

Building the Skills

Running a cryptographic inventory well requires knowing what each method sees, how to read capability findings against usage findings, how to negotiate access without stalling the programme, and how to structure a CBOM that survives contact with a remediation team.

Quantum Academy’s certification path for engineers and architects taking on quantum readiness work covers cryptographic discovery methodology, CBOM construction, and post-quantum migration planning. Current programme details and enrollment options are at quantumacademy.com/.

For migration methodology beyond the inventory phase, see the framework material at pqcframework.org. For deeper technical treatment of the cryptographic and quantum computing background, PostQuantum.com has the long-form analysis.