You can build a large part of a cryptographic inventory passively, by reading the handshakes that cross your network: which TLS and SSH versions each server and client use, which key-exchange groups they offer and agree on, which cipher suites, and, where the handshake shows them, which public-key algorithms and key sizes. You cannot see cryptography that never crosses a monitored link. So the network view is the fastest way to cover every device, including those nobody inventoried, and it has to be completed with a certificate inventory and supplier answers. Every post-quantum roadmap, starting with the EU's, puts this inventory first.
What a cryptographic inventory contains
A useful inventory answers, for each system: which protocols and versions it speaks, which key-exchange and signature algorithms with which key sizes, which certificates and who issued them, which library or product provides the cryptography, who owns the system, and how long the data it protects must stay secret. Published in a machine-readable form, it is often called a CBOM, a cryptography bill of materials; the CycloneDX standard defines one. The point is not the document but the decisions it enables: what to migrate first, and what to ask which supplier.
What the network shows, without decrypting anything
- Protocol versions. TLS 1.0 and 1.1, SSH 1 and other outdated versions are visible at the start of every connection.
- Key exchange offered and chosen. In TLS 1.3 the ClientHello lists the client's supported groups and key shares, and the ServerHello names the group the server picked. That shows directly whether a connection used a classical group such as X25519 or P-256, or the hybrid post-quantum X25519MLKEM768. SSH announces its key-exchange methods in clear in the same way.
- Cipher suites. The symmetric cipher and hash each connection settles on, which flags leftovers such as 3DES or RC4.
- Keys and certificates, where they are in clear. In TLS 1.2 the server's certificate chain is sent unencrypted, so its signature algorithm and key size are visible. SSH host keys are exchanged in clear. In TLS 1.3 the certificate is encrypted, so for those servers you need a certificate scan or inventory.
- Weak keys. Public keys collected from handshakes can be checked against each other. RSA keys that share a prime factor are broken outright, and they are the classic sign of a device with a poor random-number generator, typically an appliance or an embedded system.
- Every device on the segment. Printers, cameras, OT gateways, network appliances and old servers are covered as well as managed laptops, which is where agent-based tools are blind.
What stays invisible
- Cryptography inside applications and databases, such as field-level encryption or a library call in your own code.
- Keys and certificates stored on disk, in key stores or in hardware security modules.
- Code signing and software updates, unless you inspect the update channel itself.
- Encrypted backups and archives.
- Traffic on segments no sensor watches, and connections that never cross a monitored link.
- The certificate in most TLS 1.3 connections, as noted above.
How to fill the gaps
Combine the network view with three other sources: a certificate inventory from your certificate authority, your management tools or an active scan; software bills of materials and vendor documentation for the products you run; and supplier questionnaires that ask, with dates, when each product will support hybrid post-quantum key exchange and post-quantum signatures. Then rank the systems with Mosca's inequality, as the post-quantum readiness guide explains, and repeat the network measurement after each change to confirm it took effect.
Where NetSenX fits
This is what NQCI, the NetSenX crypto inventory, does. It is in preview, visible on every plan and active from the Pro plan with the packet-capture sensor switched on for a Linux agent or a sensor on a SPAN or TAP port; the basic macOS mode does not see handshakes. It shows which connections in monitored traffic use quantum-vulnerable key exchange and which already use hybrid post-quantum key exchange, flags weak public keys, and records changes over time. It does not change any cryptography and does not make anyone compliant; it shows where you stand.
Sources
- RFC 8446, The Transport Layer Security (TLS) Protocol Version 1.3 — IETF
- RFC 4253, The Secure Shell (SSH) Transport Layer Protocol — IETF
- CycloneDX Cryptography Bill of Materials (CBOM)
- Heninger et al., Mining Your Ps and Qs: Detection of Widespread Weak Keys in Network Devices, USENIX Security 2012
Written by the NetSenX Team at TriStiX S.L. Questions: info@netsenx.com.