SOLUTIONS · USE CASE

Cryptographic Discovery & CBOM

Cryptographic discovery is the process of finding every place cryptography is in use across an enterprise estate, from network endpoints and certificates to keys, databases, containers, file shares and source code, and recording each finding in one inventory. Quantum Sentinel assembles those findings into a Cryptography Bill of Materials that stays current as the estate changes, and exports it as CycloneDX 1.7.

Where cryptography actually lives

An inventory is only as good as the places it looks. Cryptography is not confined to the certificates on your load balancers: it sits in network protocol negotiation, in VPN policy, in key managers, in database configuration, in container volumes, in files nobody has opened for years, and in code your own team wrote. Quantum Sentinel discovers each of these and writes them into the same inventory.

Network endpoints and protocols

Discovery runs nmap and testssl.sh across 55 crypto-relevant ports by default, covering TLS directly and through STARTTLS, plus SSH, RDP, SMB, DNS-over-TLS, DNS-over-HTTPS and DNS-over-QUIC. For each endpoint it records the protocol versions, cipher suites, key exchange and the host certificate’s subject, issuer, serial, SAN, validity window, key algorithm and size.

It also detects the post-quantum cryptography you have already deployed. A native Go handshake identifies hybrid key exchange such as X25519MLKEM768, and a separate probe offers ML-KEM-768 and ML-KEM-1024 directly, so a server that will only negotiate post-quantum groups is recorded rather than reported as a failure. Most scanners cannot complete either handshake.

IPsec and IKE

VPN discovery sends a single IKEv2 IKE_SA_INIT and stops there. It never sends IKE_AUTH and never establishes a security association, but the response still reveals the encryption, integrity, PRF and Diffie-Hellman parameters the responder will accept.

Network appliances

Certificates, TLS profiles and VPN crypto policy are collected read-only through each vendor’s own management API: F5 BIG-IP through iControl REST, Fortinet FortiGate through its REST API, Palo Alto PAN-OS through the XML API, and Cisco ASA through its HTTPS CLI interface. This is where a great deal of enterprise cryptography is configured and where it is least often inventoried.

Certificates, PKI and Active Directory Certificate Services

For Microsoft PKI, Quantum Sentinel inventories issued certificates from the certificate authority itself using a read-only account, and can optionally read the CA’s own certificate over LDAPS. Where security policy will not allow a connection to the CA, the same data can be picked up from a certutil -view CSV export left on a file share, recognised by its content rather than its filename.

Keys, data, containers and code

HSMs and key management

Key metadata is collected from Thales Luna Network HSM over PKCS#11, Thales CipherTrust Manager, HashiCorp Vault and OpenBao, CyberArk PAM, OpenStack Barbican and AWS KMS. What is recorded is the label, key type, size or curve and state. Key material itself is never retrieved: for CyberArk the inventory is presence only, and Vault’s KV engines are deliberately not read.

Cloud key management

Keys and certificates are inventoried across AWS KMS, AWS Certificate Manager and IAM server certificates, Azure Key Vault, Google Cloud KMS, Alibaba Cloud KMS and Oracle Cloud Infrastructure Vault.

Databases

Nine engines are supported: PostgreSQL, MariaDB, MSSQL, Oracle, MongoDB, CockroachDB, ClickHouse, Neo4j and Cassandra. The scanner records the encryption actually negotiated on its own session rather than inferring it from a configuration file, along with transparent data encryption and column encryption where the engine provides it.

Containers and Kubernetes

In Kubernetes, a sidecar is injected into the pod and mirrors the volumes the pod’s own containers mount, read-only. It identifies certificates and private keys by PEM content rather than by filename, and probes the ports the pod itself is listening on. This is the one discovery surface that is not agentless, and it is deliberate: nothing else can see inside a running pod’s mounted secrets without doing so.

File shares

Encrypted files, keystores and key containers at rest on SMB and NFS shares, found by content signature and read 512 bytes at a time. See cryptographic discovery for file shares.

Code repositories

The algorithms your source code calls, across GitHub, GitLab, Bitbucket and Azure DevOps, reported by file, line and enclosing function. See cryptographic discovery for code repositories.

What a CBOM entry contains

A CBOM is not a list of certificates. Each entry is one cryptographic fact about one place in your estate, with enough context attached that somebody can act on it without a second investigation.

Field group	What it holds
Entry type	certificate, public key, cipher suite, protocol, key exchange, hash function, algorithm, SSH configuration, keystore key or encrypted file
Where it lives	Host, port, protocol and service name, plus the asset, IP and hostname the entry is correlated to
The cryptography	Algorithm, key size, curve name, TLS version and cipher suite
Certificate detail	Subject, issuer, serial, SAN, not-before and not-after
Risk position	Quantum risk tier, a 0 to 100 quantum risk score, a harvest-now-decrypt-later flag, NIST and CNSA status, migration priority and recommended replacement
Provenance	The source that found it, first seen and last seen timestamps, the scan job that last touched it, and the fingerprint used to deduplicate it

Exported as CycloneDX, a certificate entry becomes a cryptographic-asset component:

{
  "bomFormat": "CycloneDX",
  "specVersion": "1.7",
  "components": [
    {
      "type": "cryptographic-asset",
      "cryptoProperties": {
        "assetType": "certificate",
        "certificateProperties": {
          "subjectName": "CN=example.com",
          "issuerName": "CN=Example CA",
          "notValidBefore": "2026-01-01T00:00:00Z",
          "notValidAfter": "2027-01-01T00:00:00Z"
        }
      }
    }
  ]
}

One inventory, not six spreadsheets

Running six tools produces six inventories that disagree with each other. The value of a CBOM is that every source writes into the same one.

The same asset is not counted twice. Each entry carries a fingerprint derived from the tenant, host, port, entry type, algorithm, cipher suite and TLS version. A rescan updates the existing entry rather than adding a duplicate, which is what makes first seen and last seen timestamps meaningful.

Findings are tied to assets. Entries are correlated to the asset they belong to by hostname or IP, and the method used for the match is recorded alongside it, so the correlation can be audited rather than trusted blindly.

Risk is scored in business context. Every entry gets a quantum risk tier and a 0 to 100 score, weighted by the criticality, environment and exposure of the asset it sits on, plus NIST and CNSA status. That is what turns an inventory into a migration plan rather than a list.

CycloneDX, because an inventory nobody else can read is not an inventory

The CBOM exports as CycloneDX 1.7 JSON, served as application/vnd.cyclonedx+json, with each finding as a component of type cryptographic-asset. All four cryptographic asset types defined by the standard are emitted: algorithm, certificate, protocol and related crypto material, including the elliptic curve registry and NIST quantum security levels that CycloneDX 1.7 introduced. Plain JSON and CSV exports are available for teams that want to work in their own tooling.

This matters for the same reason SBOM formats matter: a regulator, an auditor or an acquiring company can read it without your platform. Background on how cryptographic inventory became part of the SBOM standard is in CBOM and CycloneDX.

What it does not do

Worth stating plainly, because these are the questions a serious evaluation reaches within the first hour.

Host certificates, not chains. Discovery records the certificate an endpoint presents. It does not build intermediate or chain-of-trust objects for the certificates above it.
CycloneDX JSON, not XML. The CycloneDX export is JSON only.
No generic SBOM or CBOM import. This version does not ingest third-party inventories. The CBOM is built from what Quantum Sentinel discovers.
Kubernetes needs a sidecar. Every other discovery surface is agentless. Seeing inside a running pod is not.
Key material stays where it is. Key managers are read for metadata. In CyberArk the inventory records presence only, with no algorithm or key size.

Frequently asked questions

What is a Cryptography Bill of Materials?

A CBOM is an inventory of the cryptography an organisation actually runs: the algorithms, protocols, certificates, keys and key containers in use across its estate, each recorded with where it was found, what it is, and what it means for quantum risk. Quantum Sentinel keeps it current as the estate changes rather than producing a one-off snapshot.

Where does Quantum Sentinel discover cryptography?

Network endpoints and protocols including TLS, SSH, RDP, SMB and encrypted DNS; IPsec and IKE; F5, Fortinet, Palo Alto and Cisco ASA appliances; Microsoft Active Directory Certificate Services; HSMs and key managers; AWS, Azure, Google Cloud, Alibaba Cloud and OCI key management; nine database engines; Kubernetes pods; SMB and NFS file shares; and source code in GitHub, GitLab, Bitbucket and Azure DevOps.

Does discovery require agents?

No, with one deliberate exception. Network, appliance, PKI, key manager, cloud, database, file share and repository discovery are all agentless and use each system’s own protocol or API. Kubernetes discovery injects a read-only sidecar into the pod, because nothing outside the pod can see the secrets mounted inside it.

Does Quantum Sentinel export CycloneDX?

Yes. The CBOM exports as CycloneDX 1.7 JSON, with each finding as a component of type cryptographic-asset covering all four cryptographic asset types in the standard: algorithm, certificate, protocol and related crypto material. Plain JSON and CSV exports are also available.

Does it collect private keys or sensitive data?

No. Discovery collects cryptographic metadata. Key managers and HSMs are read for key labels, types, sizes and state rather than key material; file share scanning reads the first 512 bytes of a file to identify its format; database scanning records the encryption negotiated on its own session.

How does it avoid counting the same thing twice?

Each entry carries a fingerprint derived from the tenant, host, port, entry type, algorithm, cipher suite and TLS version. A rescan updates the matching entry rather than creating a duplicate, so first seen and last seen timestamps stay meaningful.

Can it detect post-quantum cryptography that is already deployed?

Yes, and this is the half of the picture most inventories miss. Network discovery identifies hybrid key exchange such as X25519MLKEM768 by completing a real handshake, and probes for servers that will only negotiate ML-KEM-768 or ML-KEM-1024. Repository scanning detects ML-KEM, ML-DSA, Falcon, SPHINCS+, FrodoKEM and Classic McEliece in source code.

How does it inventory Active Directory Certificate Services?

It inventories issued certificates from the certificate authority using a read-only account, one entry per certificate, and can optionally read the CA’s own certificate over LDAPS. Where connecting to the CA is not permitted, it recognises a certutil CSV export placed on a file share instead.

Discovery by source: File shares · Code repositories · All use cases

See how this fits into the full Quantum Sentinel platform →

See where your cryptography stands.

The first step is always the same: visibility. Request a demo and see your cryptographic exposure.