A cryptographic inventory that records algorithm names and stops there has recorded almost nothing useful. Knowing that a system “uses RSA” or “uses AES” or “uses SHA-2” is the cryptographic equivalent of knowing a building “has doors.” It is true, it is unobjectionable, and it supports no decision. The questions that actually matter, is this key long enough, is this mode safe, is this hash strong enough for a signature, is this protocol version still acceptable, are all questions about parameters, and parameters are exactly what a name-only inventory throws away. RSA-2048 and RSA-512 are both “RSA.” One is a defensible choice for most purposes today and the other has been broken for decades. An inventory that cannot tell them apart cannot tell you anything.
The real unit of a cryptographic inventory is not the algorithm name but the fully parameterized primitive: the algorithm together with every parameter that determines its strength and behavior. And beyond the parameters of a single primitive lies a second, subtler distinction that most inventories miss entirely: the difference between what a system is configured to allow and what it actually negotiates in practice. These are not the same, the gap between them is often large, and that gap is precisely where risk accumulates and where auditors find the problems that a configuration review alone would never surface.
This post covers both: why parameters are the point and names are not, how to inventory protocol cryptography across TLS, SSH, IPsec, and the rest, and why distinguishing configured from negotiated cryptography is the insight that separates a real crypto inventory from a list of algorithm names.
Compliance Gap: Required vs. Actual Certificate Coverage
What frameworks require vs. what organizations typically demonstrate
The average enterprise demonstrates 35% certificate coverage against framework requirements that expect 85-95%. This gap is where audit findings live.
Parameters Are the Inventory, Names Are Not
Every cryptographic algorithm is a family, and the members of the family differ enormously in strength. The name identifies the family; the parameters identify the member, and the member is what you are actually running. An inventory that captures only the family name has recorded the category while discarding the information that determines whether the choice is safe, compliant, or quantum-vulnerable.
The parameters that matter vary by primitive, and a mature inventory captures the right ones for each:
| Primitive | Parameters That Determine Strength |
|---|---|
| RSA | Key length and padding mode |
| Elliptic-curve | The specific named curve |
| Diffie-Hellman | Group or key length, and whether the group is well-known or custom |
| AES | Key length and mode of operation |
| Hash functions | Output length and the specific function within the family |
| Signature schemes | The underlying key, the hash, and the padding or encoding |
| Key derivation | The function and its work-factor parameters |
Each of these parameters changes the answer to a real question. A padding mode determines whether an RSA deployment is vulnerable to a padding-oracle attack. A mode of operation determines whether an AES deployment provides authenticated encryption or merely confidentiality. A hash output length determines whether a signature is strong enough to resist collision attacks. A Diffie-Hellman group’s size and provenance determine whether the key exchange is sound or dangerously weak. None of these is visible in the name. All of them are the inventory. A platform that captures the fully parameterized primitive can answer “which of our RSA deployments use a key shorter than our policy minimum”; a platform that captures only “RSA” can answer nothing of the kind.
This is also what makes quantum-risk assessment possible. The quantum threat is parameter-specific: it is not “RSA is at risk” but “RSA at every key length is at risk because the algorithm is broken by a sufficiently large quantum computer,” while a symmetric cipher’s quantum exposure depends on its key length. You cannot evaluate quantum risk from names. You evaluate it from parameterized primitives, which is one more reason the parameters are the thing worth capturing.
Inventorying Protocol Cryptography
Most cryptography in an enterprise is not invoked directly by application code; it is embedded in protocols. A protocol configuration is a bundle of cryptographic choices, which versions are allowed, which cipher suites, which key-exchange groups, which signature algorithms, and inventorying protocol crypto means capturing those bundles across every protocol in use, not just the obvious one.
The protocols that carry cryptographic configuration span the whole estate:
| Protocol | Cryptographic Configuration It Carries |
|---|---|
| TLS | Versions, cipher suites, key-exchange groups, signature algorithms |
| SSH | Key-exchange methods, host-key types, ciphers, MAC algorithms |
| IPsec and IKE | Encryption, integrity, and key-exchange proposals |
| LDAPS | The TLS configuration protecting directory traffic |
| OAuth and OIDC | The algorithms signing and protecting tokens |
TLS is where most attention goes and rightly so, because it protects the bulk of external traffic, but an inventory that stops at TLS leaves large and sensitive categories unexamined. SSH protects administrative access to the infrastructure itself, and a weak SSH configuration is a direct path to the systems it administers. IPsec and IKE protect site-to-site and remote-access tunnels, and their proposals are often configured once and never revisited. LDAPS protects the directory that authentication depends on. OAuth and OIDC token signing is cryptography that gates access to applications, and a weak signing algorithm there undermines the authorization it is meant to enforce. A complete protocol inventory captures the cryptographic configuration of all of them, because an attacker attacks the weakest protocol, not the one you were watching.
Configured Versus Negotiated: The Distinction That Matters Most
Here is the insight that separates a genuine crypto inventory from a configuration audit. A server’s configuration states what it is willing to do: the full set of protocol versions and cipher suites it will accept. That is the configured cryptography. What two endpoints actually settle on when they connect, the single version and cipher suite they negotiate, is the negotiated cryptography. These are different, and the difference is where both risk and audit findings concentrate.
A server can be configured to allow a weak protocol version or a weak cipher suite as a fallback while, in practice, almost every client negotiates something strong. A configuration review sees the weak option in the allowed list and flags it. A traffic-only view sees only strong negotiations and concludes everything is fine. Both are half right and half blind. The weak option is a real exposure, because any client, including an attacker who can influence negotiation, can insist on it, and the fact that most clients do not is no protection against the one that will. At the same time, the weak option being present but rarely used is a different and lower-urgency situation than a weak option that is actively negotiated on most connections, and treating them identically wastes effort.
The only way to see the whole picture is to capture both sides and compare them:
- The configured set tells you what is permitted, including the weak fallbacks that a client or attacker could force.
- The negotiated set tells you what is actually in use, which reveals both the real operating baseline and any weak choices that are not merely allowed but happening.
The gap between the two is the finding. A weak suite that is configured but never negotiated is a latent exposure to close before someone forces it. A weak suite that is both configured and negotiated is an active problem. A strong configuration that nonetheless negotiates something unexpectedly weak against certain clients points at a specific compatibility compromise worth examining. None of these distinctions is available from either side alone, which is why a serious inventory captures configuration and observed negotiation together rather than choosing one.
Combining Active Probing and Configuration Parsing
Because configured and negotiated cryptography are different things, they are discovered by different means, and a complete inventory combines them rather than relying on either.
Active probing establishes what is negotiated and what can be negotiated. By connecting to a service and completing handshakes under varying conditions, a platform observes what the service actually settles on and can also probe whether weak options remain reachable by offering them deliberately. This is how the negotiated reality is established, and it is grounded in the service’s live behavior rather than in what a file claims.
Configuration parsing establishes what is configured. Reading the actual configuration of servers, load balancers, and protocol endpoints reveals the full permitted set, including options that are allowed but rarely or never negotiated in observed traffic, which probing alone might not surface because no observed client requested them. Parsing is how the complete allowed set is established, including the latent weak fallbacks that are the whole reason the configured-versus-negotiated distinction matters.
Neither technique is sufficient alone. Probing without configuration parsing sees what happened but not the full range of what is permitted, missing latent fallbacks that no observed client triggered. Parsing without probing sees the permitted range but not what is actually negotiated, and cannot confirm that the configuration behaves as written. Together they produce the two sets whose comparison is the inventory’s most valuable output: the configured surface and the negotiated reality, and the gap between them that is where the work is.
Why This Depth Pays Off
The payoff of a parameterized, configured-versus-negotiated inventory is that it supports decisions a name-only inventory cannot. Compliance mapping becomes possible because standards are written in terms of parameters and permitted protocol versions, and a mapping requires knowing both what is allowed and what is used. Quantum-risk prioritization becomes possible because the risk is parameter-specific. Audit readiness improves because the findings an auditor would otherwise surface, the weak fallback nobody remembered configuring, the deprecated protocol version still permitted, are already in the inventory and already explained in terms of whether they are latent or active. The depth is not thoroughness for its own sake. It is the difference between an inventory that tells you “you use these algorithms” and one that tells you “here is where a client can still force a weak connection, and here is where one already does.”
FAQ
Q: Why isn’t recording the algorithm name enough? Because the name identifies a family, not the member you are running, and the members differ enormously in strength. RSA-2048 and RSA-512 are both “RSA,” but one is defensible and the other has been broken for decades. Every question worth asking, is the key long enough, is the mode safe, is the hash strong enough, is a question about parameters, and a name-only inventory has already discarded them.
Q: What is the difference between configured and negotiated cryptography? Configured cryptography is what a server is willing to accept: its full allowed set of versions and cipher suites. Negotiated cryptography is what two endpoints actually settle on when they connect. They differ because servers often allow weak fallbacks that strong clients rarely trigger, and the gap between the allowed set and the used set is where latent exposure and audit findings concentrate.
Q: Why does the configured-versus-negotiated gap matter if clients negotiate strong suites anyway? Because a weak option that is merely allowed is still reachable by any client that insists on it, including an attacker who can influence negotiation. The fact that most clients choose something strong is no protection against the one that will not. At the same time, a weak suite that is allowed but never negotiated is lower urgency than one actively in use, and seeing both lets you tell those situations apart.
Q: Why inventory protocols beyond TLS? Because sensitive cryptography lives in SSH, IPsec and IKE, LDAPS, and OAuth and OIDC token signing, not only TLS. SSH protects administrative access to infrastructure, IPsec protects tunnels configured once and rarely revisited, LDAPS protects the directory authentication relies on, and token signing gates application authorization. An attacker targets the weakest protocol, so an inventory that stops at TLS leaves the real openings unexamined.
Q: Why combine active probing with configuration parsing? Because they reveal different things. Probing establishes what is actually negotiated and whether weak options remain reachable; parsing establishes the full permitted set, including fallbacks no observed client triggered. Probing alone misses latent fallbacks; parsing alone cannot confirm the configuration behaves as written. Together they produce the configured surface and the negotiated reality, and the gap between them is the inventory’s most valuable output.
About QCecuring
QCecuring inventories cryptography as fully parameterized primitives, key lengths, curves, groups, modes, padding, and hash lengths, not just algorithm names, and captures protocol cryptography across TLS, SSH, IPsec and IKE, LDAPS, and token signing. By combining active probing with configuration parsing, it distinguishes what a system is configured to allow from what it actually negotiates, surfacing the latent fallbacks and active weaknesses that live in the gap between the two.
See where a client can still force a weak connection in your estate
Tags: CBOM, SSL/TLS, Algorithm Inventory, Protocol Cryptography, Cipher Suites, Cryptographic Parameters, TLS Configuration, SSH, IPsec, Compliance Mapping, Quantum Risk, Enterprise Security