Cryptographic Discovery and Inventory: Where to Start

You cannot manage what you cannot see.

A cryptographic inventory is a record of where cryptography is used across your estate: which algorithms are in play, which keys and certificates exist, where they are stored, and which systems and data flows depend on them. Cryptographic discovery is the process of finding all that out.

The principle has always been true in cybersecurity, and it applies with particular force to post-quantum readiness. Before any organisation can plan a transition to quantum-resistant algorithms, it needs the picture that discovery produces.

Standards bodies and national agencies now recommend this as the foundational step. The recommendation is consistent across NIST, ETSI, ENISA and the NSA's CNSA 2.0 guidance, and the NIST PQC roadmap sets firm deprecation deadlines for RSA and ECC from 2030. Without visibility of your cryptographic landscape, any planning is built on assumptions rather than evidence.

Key points

• Discovery is the activity; the inventory is the output. Both need to be continuous rather than one-off.
• No single discovery method finds everything. Most organisations need three or four working together.
• The inventory is itself a sensitive asset and needs classifying accordingly.
• A Cryptographic Bill of Materials is the structured, machine-readable form of the inventory — the format that makes it operationally useful rather than a document.

Why cryptographic visibility is the starting point

Most organisations acknowledge that cryptography underpins their technical security controls. Encryption protects data in transit and at rest. Digital certificates authenticate users, devices and services. Signed code and firmware ensure the integrity of software deployments. These are not peripheral functions.

Yet the precise locations, functions and dependencies of cryptographic controls are often poorly documented or entirely unknown. PKI environments typically evolve organically over years, with different teams deploying certificates for different purposes, using different certificate authorities and following different policies. The result is a fragmented landscape with limited central oversight.

That creates a specific problem. If you do not know where cryptography is used, you cannot assess which systems are exposed to quantum risk. If you do not know which algorithms are in use, you cannot determine where migration is needed. And if you do not understand the dependencies between cryptographic services and business processes, you cannot sequence change without introducing operational risk.

A useful inventory goes beyond certificates to the key management practices underpinning them: where keys are stored, how they are protected, what algorithms they use, and whether they meet current standards. Keys held in hardware security modules carry a different risk profile from those in software keystores, and the inventory should capture the distinction.

The scale of the challenge

Cryptographic inventory is often deferred because organisations underestimate the volume involved.

A single enterprise Windows estate contains certificates from three separate sources: those deployed by internal PKI for authentication and encryption, those embedded within line-of-business applications, and those shipped in the operating system's trusted root store. Counting all three, the total in a large environment routinely runs into tens or hundreds of thousands. Linux servers, mobile devices and network appliances each add their own populations.

The point is not the precise number. It is that the volume has grown beyond what spreadsheets, ad hoc scripts and manual tracking can handle. This is not a failure of diligence — it reflects how deeply cryptography has become embedded in every layer of the stack.

As with patching and anti-virus management, there is a tipping point at which scale and complexity make manual approaches untenable. Cryptographic inventory has reached it.

How cryptographic discovery actually works

Discovery is not a single technique. Each method finds a different subset of the estate, and each has blind spots, which is why comprehensive coverage requires several working together.

Network scanning

Scanning IP ranges and ports to identify certificates presented by live services. Fast to deploy, requires no agents, and finds certificates that are actually in use — including ones nobody knew about.

Misses: anything not listening on a scanned network, certificates on systems that are powered down, client certificates, code signing certificates, and anything in an isolated segment the scanner cannot reach.

Certificate authority interrogation

Querying the databases of your internal CAs, and pulling issuance records from public CAs and Certificate Transparency logs. This produces an authoritative list of what has been issued.

Misses: self-signed certificates, certificates from CAs you have forgotten about, and anything issued outside the central process. It also tells you what was issued rather than where it ended up, so it needs correlating with scan data.

Agent-based discovery

Software on endpoints and servers inspecting local certificate stores, keystores and configuration files. This reaches material that network scanning cannot see — client certificates, unused certificates sitting in stores, and keys at rest.

Misses: anything you cannot install an agent on, which typically means appliances, embedded devices and operational technology. Agent deployment is also the step where discovery programmes most often stall on change control.

Configuration and infrastructure analysis

Reading configuration from load balancers, web servers, cloud key management services, container orchestration and infrastructure-as-code repositories. This finds cryptographic configuration — which cipher suites are enabled, which TLS versions are permitted — rather than just certificates.

Misses: anything configured outside managed tooling, and undocumented manual changes made directly on a host.

Source code and binary analysis

Static analysis of application code and dependencies to identify cryptographic libraries, hardcoded algorithms and embedded keys. This is the only method that finds cryptography compiled into applications.

Misses: runtime configuration. Code analysis tells you what an application is capable of, not what it actually negotiates in production.

Why capability and usage are different questions

This distinction runs through everything above and is the most common source of inflated findings. A system that supports a weak algorithm but never negotiates it carries less risk than one actively using it.

Code and configuration analysis tell you capability. Network scanning and traffic inspection tell you usage. An inventory built on capability alone produces a remediation list far longer than the genuine exposure, which undermines credibility with the teams who have to act on it.

Where to start: a practical approach

The goal is comprehensive visibility, but organisations do not need to attempt full discovery on day one. A phased approach is both practical and effective.

A useful starting point is externally facing systems and services. These are most exposed to network-level interception and therefore most relevant to harvest now, decrypt later risk. Understanding which certificates protect your external interfaces, which algorithms they use and when they expire provides immediate, actionable insight.

An alternative or complementary approach is to describe a "day in the life" of key user personas and identify where cryptography is involved. This maps the cryptographic touchpoints different roles encounter as they interact with systems and data, and is a surprisingly effective way to surface dependencies that are otherwise invisible.

Both approaches share an important characteristic: they create shared understanding across technical and non-technical stakeholders. That is valuable in itself, because it builds the awareness and buy-in needed to support later investment in discovery tooling. When the time comes to make the case, the groundwork is already laid.

Evaluating cryptographic discovery tooling

The tooling market is maturing quickly, driven by post-quantum readiness requirements. It is also crowded, and vendor claims about coverage deserve scrutiny.

What to assess

• Which discovery methods does it use? A tool offering only network scanning will miss client certificates and anything compiled into applications. Ask which of the five methods above it covers and where it expects you to fill gaps.
• Does it distinguish capability from usage? If it reports every supported algorithm as a finding, your remediation list will be unmanageably long and largely theoretical.
• What does it capture per asset? Hostname and expiry date is not an inventory. You need issuing CA, algorithm, key length, protocol version and — ideally — the consuming system.
• Can it reach your hardest environments? Segmented networks, air-gapped systems, operational technology and cloud accounts you do not centrally control. Test against these rather than the easy estate.
• What format does it output? CycloneDX or another open standard means the data is portable. Proprietary output creates a dependency that is expensive to unwind.
• Is discovery continuous or scheduled? An inventory compiled once is out of date within weeks.
• Can it produce something a board will read? See below.

Realistic expectations

No single tool provides complete visibility across every environment, application and device type. Most organisations need a combination of approaches supplemented by manual analysis where automated discovery has limited reach. The goal is a progressively more complete picture, not perfection from day one.

It is also worth noting that the outputs of most discovery tools remain highly technical. They are designed for PKI specialists and security engineers, not for boardroom consumption. Significant refinement is typically needed before findings can be presented in a format that supports decision-making at leadership level. That translation from technical data to business-relevant insight is where independent guidance adds value, and it is not something tooling alone will solve.

Making the business case

Cryptographic discovery competes for budget against threats with more immediate visibility. These are the arguments that tend to carry it.

It is a prerequisite, not an option

Every post-quantum migration plan, every certificate automation programme and every cryptographic compliance response depends on knowing what exists. Deferring discovery does not defer the cost — it moves it into a programme where it will be on the critical path, discovered late, and priced under pressure.

It pays for itself in outage prevention

Certificate-related outages are avoidable and expensive, and they happen because the certificate was not on anybody's list. The cost of an expired certificate is rarely the certificate. One prevented outage typically covers the discovery exercise.

It shortens vulnerability response from days to minutes

When a flaw is disclosed in a cryptographic library, the question is which systems are affected. With an inventory that is a query. Without one it is a manual exercise across teams, and the exposure window stays open throughout.

Regulators increasingly expect it

Demonstrating control over cryptographic assets is becoming a compliance expectation rather than good practice, across NIS2, the EU Cyber Resilience Act and sector-specific frameworks. An inventory is the evidence. Producing one reactively during an audit is considerably more expensive than maintaining one.

The deadlines are fixed

NIST deprecates RSA and ECC from 2030. The NCSC expects UK organisations to have completed discovery and produced a migration plan by 2028. Discovery across a large estate is a months-long exercise, and it is the first dependency in a multi-year programme. The arithmetic does not leave much slack.

Framing it for the board

The question a board can act on is not "how many certificates do we have". It is: which business services would fail if a certificate expired unnoticed, and can we currently answer that? Most organisations cannot, and that framing tends to land better than a technical asset count.

Protecting the inventory itself

There is a security consideration sometimes overlooked in the enthusiasm for building visibility: the inventory is a highly sensitive asset.

It provides a detailed map of your cryptographic dependencies and weak points — which algorithms are in use, where certificates are deployed, which systems depend on which services, and where gaps exist. In the wrong hands that is an invaluable resource for an attacker planning to exploit cryptographic weaknesses.

Any tooling, repository or reporting platform used to store or present inventory data must be risk-assessed and protected as a high-value asset. Access tightly controlled, data classified appropriately, and the inventory subject to the same governance standards as other sensitive security intelligence.

This is not a reason to avoid building one. It is a reason to manage it with the rigour you would apply to any other sensitive security capability.

From inventory to action

A cryptographic inventory is not an end in itself. Its value lies in what it enables: informed decisions about where migration should be prioritised, which systems are most exposed, where algorithm upgrades are needed most urgently, and how to sequence change to minimise disruption.

It also provides the baseline against which progress is measured. As the organisation transitions to quantum-resistant algorithms, the inventory is how you track coverage, identify gaps and demonstrate to leadership and regulators that the transition is being managed systematically.

Formalising it as a Cryptographic Bill of Materials is the next step. A CBOM structures the same data into a standardised, machine-readable format that supports automation, integrates with security tooling and evolves alongside the environment. The inventory is what you know; the CBOM is the form that keeps it useful.

From there, crypto-agility becomes achievable — the ability to change algorithm, key length or certificate profile without redesigning systems. That is what turns the next cryptographic transition into a configuration exercise rather than another programme.

How Unsung can help

We help organisations build practical cryptographic inventories that support post-quantum readiness. We guide clients through identifying cryptographic dependencies, selecting appropriate tooling, interpreting discovery findings and translating technical data into business-relevant risk assessments.

Our approach is proportionate and phased. We help you start where it matters most, build stakeholder engagement through early wins, and develop a roadmap for progressively deepening visibility. We also advise on the governance of the inventory itself, ensuring this sensitive capability is protected from the outset.

A PKI health check is often the fastest route to a baseline, and our PKI consultancy team can take the findings forward into a migration plan. Talk to our team about where to start.

Frequently asked questions

What is a cryptographic inventory?

A record of where cryptography is used across an organisation's estate: the algorithms in use, the keys and certificates that exist, where they are stored, and which systems and data flows depend on them. It is the evidence base for cryptographic governance and the prerequisite for post-quantum migration planning.

What is the difference between cryptographic discovery and a cryptographic inventory?

Discovery is the activity of finding cryptographic assets across the environment. The inventory is the resulting record. Discovery needs to be continuous rather than a one-off exercise, because the inventory goes stale as systems change.

What is the difference between a cryptographic inventory and a CBOM?

They describe the same underlying information at different levels of formality. The inventory is the operational picture of what cryptography exists and how it is used. A Cryptographic Bill of Materials structures that data into a standardised, machine-readable format — usually CycloneDX — so it can be generated automatically, queried during incident response and exchanged across supply chains.

How do you discover cryptographic assets?

Five methods, and most organisations need several. Network scanning finds certificates on live services. Certificate authority interrogation finds what has been issued. Agent-based discovery reaches local certificate stores and keys at rest. Configuration analysis finds cipher suites and protocol settings. Source code and binary analysis finds cryptography compiled into applications. Each has blind spots the others cover.

What should a cryptographic discovery tool do?

Cover multiple discovery methods rather than one, distinguish what a system supports from what it actually uses, capture algorithm and key length rather than just hostname and expiry, reach segmented and operational technology environments, output to an open format such as CycloneDX, and run continuously rather than on request.

How long does building a cryptographic inventory take?

An initial view of externally facing systems can be produced in weeks. Comprehensive coverage across a large hybrid estate is typically a months-long exercise, and the agent deployment and change control elements usually determine the timeline rather than the scanning itself. Maintaining it is continuous.

Why is a cryptographic inventory needed for post-quantum migration?

You cannot migrate cryptography you have not identified. The inventory tells you which systems use RSA and ECC, which will need replacing, which can be updated in place and which cannot be updated at all. Without it, migration scoping is guesswork and the programme cannot be priced or sequenced.

Is the cryptographic inventory itself a security risk?

It is a sensitive asset. It maps cryptographic dependencies and weak points across the organisation, which would be valuable to an attacker. Classify it, restrict access, and apply the same governance you would to any other sensitive security intelligence.

Want to explore this topic further?

This blog is part of a series drawn from our strategic whitepaper, Post-Quantum Cryptography: A Strategic Whitepaper for the C-Suite. It provides vendor-neutral, business-focused guidance on navigating the quantum era — covering the threats already in play, lessons from previous hype cycles, and practical steps your organisation can take today. Download your copy here: https://2f4v3l.share-eu1.hsforms.com/20qJjHSynQkuJKhI_xq9Msg