Cryptographic Discovery: Why No Single Tool Can Build Your PQC Inventory

Before an organisation can plan its post-quantum migration, it needs to understand what it is actually migrating.

That sounds straightforward.

In practice, it isn't.

FINMA Guidance 05/2026 recommends that supervised institutions analyse their business processes for encryption, signature and authentication technologies and build an inventory across ICT systems, applications and infrastructure, whether operated in-house, outsourced or consumed as a service.

That scope extends far beyond certificates.

And it creates an important challenge:

No single discovery tool can see every place cryptography exists.

A certificate inventory isn't a cryptographic inventory

Certificates are an important part of the picture, but they're only one layer.

A broader cryptographic inventory can include:

• algorithms
• cryptographic libraries
• protocols
• keys
• certificates
• cryptographic use within applications and code
• authentication mechanisms
• dependencies between cryptographic assets and systems

‍

This distinction becomes particularly important when preparing for post-quantum cryptography.

A certificate inventory can provide visibility into certificates and their lifecycle. But it won't necessarily reveal a cryptographic library embedded inside an application, an algorithm hard-coded into firmware or a dependency on cryptography controlled by a third-party service.

FINMA's own survey reinforces the importance of looking beyond individual cryptographic assets.

76% of institutions surveyed by FINMA see high or very high value in a cryptographic inventory.

Source: FINMA Guidance 05/2026. Survey of 60 supervised institutions conducted between November 2025 and January 2026.

‍

Why one discovery tool isn't enough

Cryptography exists at multiple layers of enterprise infrastructure.

Network scanning can expose cryptographic services and protocols visible across the network.

Static source-code analysis can identify cryptographic APIs and dependencies embedded within applications.

Container-image scanning can uncover cryptographic components packaged with software.

CMDB data can provide the organisational context needed to understand which systems and applications own or depend on those assets.

Certificate lifecycle management platforms provide another part of the picture: visibility into certificates and their lifecycle.

Each source answers different questions.

The challenge is bringing those discoveries together.

‍

What different discovery methods can reveal

A practical discovery model therefore combines multiple approaches rather than expecting one scanner or platform to provide the complete inventory.

The campaign's discovery methodology specifically combines passive and active network scanning, container-image scanning, static source-code analysis and integration with CMDB and certificate lifecycle management.

‍

The blind spots matter

Even a multi-source discovery approach needs to account for areas that are difficult to see.

The campaign methodology identifies several important blind spots:

Cloud environments.
Cryptographic assets and dependencies may sit within services that an organisation does not directly operate.

OT environments.
Operational technology can introduce different architectures, ownership models and replacement cycles.

Embedded systems and firmware.
Cryptographic components may be deeply integrated into devices and difficult to identify through conventional enterprise scanning.

Legacy systems.
Older environments can contain cryptographic dependencies that are poorly documented or difficult to change.

Third-party services.
An organisation may depend on cryptography operated outside its own infrastructure.

Application dependencies.
Cryptographic APIs, libraries and hard-coded secrets may sit inside software rather than appearing as obvious network or certificate assets.

These are specifically identified as areas to consider within the campaign's discovery methodology.

The objective therefore isn't simply to produce a longer asset list.

It is to understand:

- Where does cryptography exist?

- What depends on it?

- Who owns it?

- And how difficult will it be to change?

Turn discovery into a living inventory

Discovery is only the beginning.

A one-off spreadsheet may provide a snapshot, but it won't support a multi-year migration programme if it immediately starts falling out of date.

Applications change.

Infrastructure changes.

Containers are rebuilt.

Libraries are updated.

Certificates are issued and renewed.

New services and dependencies appear.

The inventory therefore needs to remain connected to the environment it describes.

One approach is a machine-readable Cryptography Bill of Materials (CBOM).

Using a format such as CycloneDX can make cryptographic inventory information queryable and allow inventory generation to be integrated into development and operational processes.

The campaign methodology specifically identifies a machine-readable CBOM in CycloneDX format and keeping it current through CI/CD as the next step beyond one-off discovery.

That moves the organisation from asking: “What cryptography do we think we have?”

to: “What cryptography is actually deployed, where is it used and what depends on it?”

‍

Where certificate lifecycle management fits

Certificate lifecycle management remains an important part of this broader architecture.

Once certificates have been identified, their issuance, renewal, replacement and policy enforcement can increasingly be automated.

That operational capability matters for crypto-agility.

But certificate lifecycle management and cryptographic discovery solve different parts of the problem.

A cryptographic inventory needs broader visibility across algorithms, libraries, protocols, keys and cryptographic use within applications and systems.

Certificate lifecycle management provides the operational capability to manage and automate certificates across heterogeneous PKI environments.

The campaign therefore draws a clear distinction between cryptographic discovery and inventory and certificate lifecycle management and operational crypto-agility.

Discovery is the starting point

The purpose of cryptographic discovery isn't inventory for inventory's sake.

It is to establish enough visibility to make the next decisions possible.

- What cryptography is actually deployed?

- Where are the dependencies?

- Which assets will be difficult to change?

- Where are external providers involved?

- Where are the blind spots?

- Which parts of the environment require deeper investigation?

Only once those questions can be answered does an organisation have the evidence needed to move from assumptions about its cryptographic estate to a structured migration programme.

You can't migrate what you can't see.

And you can't build a reliable cryptographic inventory from a single source.

That is why discovery comes first.

‍

‍