Atsushi Yamada, CEO of ISARA Corporation, advises enterprises on crypto posture management strategies to prepare for the post-quantum era.
Inventory is a snapshot. The thing it is trying to measure is a moving picture.
The industry’s first step—building a list of every cryptographic object you have—is measuring the wrong thing.
Every cryptographic posture vendor in the market today is selling the same first step. Build an inventory. Catalog the algorithms, the certificates, the keys and the libraries. Get a complete picture of your cryptographic estate. It sounds responsible. It is the wrong starting point.
Inventory measures presence. Risk lives in use. Those are not the same problem.
What’s Actually In A Typical Cryptographic Inventory
Walk through the inventory of any large enterprise and you find the same pattern. Most of what is in there is dormant. Old applications nobody uninstalled. Archived certificates that were never retired from the trust store. Private keys still sitting on disk for services that were decommissioned two years ago. OpenSSL shared libraries linked into binaries that call only primitives of RSA, ECDH, AES and SHA-2 out of the tens of cryptographic algorithms the library implements. The inventory is a list of cryptographic objects that exist somewhere on disk or in memory. It is not a list of cryptographic objects that are actively protecting anything.
This matters because the count is misleading. A security team looking at a dashboard with 12,000 certificates and 47 implementations of the same cryptographic algorithm feels overwhelmed. The number suggests the problem is enormous. The problem is enormous, but not because of the 12,000. Most of those 12,000 are not the problem. The problem is the much smaller subset that is actively negotiating sessions, signing tokens, establishing session keys and encrypting data in flight, right now, today, with weak parameters or deprecated protocols.
Four Sources Of Cryptographic Dead Weight
The dormant material in a typical environment falls into four buckets:
• Deprecated-But-Not-Removed Applications: The application was retired. The binaries are still on disk. The cryptographic primitives compiled into them still register in any inventory scan. Nothing is invoking them. They contribute nothing to risk except inventory bloat.
• Archived Certificates: The new certificate replaced the old one. The old one was never removed from the certificate store or the configuration files. It shows up in inventory. It is not in use. In rare circumstances, it can be reactivated, which is its own problem.
• Orphaned Private Keys: The key was generated for a service that no longer exists. Or it was rotated and replaced by a new one and the predecessor was never deleted. The key file is still readable. Inventory finds it. Nothing uses it.
• OpenSSL DLLs With Unused Primitives: A shared library exposes a wide surface of cryptographic functions. The application that links against it calls a small subset. Inventory scanners flag every primitive the library makes available. Most of them never execute.
Each of these is a real cryptographic object. None of them, in their current state, is protecting anything. A platform that lists them alongside the live cryptography that is protecting customer data treats both with equal weight. That is the false sense of completeness inventory creates.
The Dynamic Problem Inventory Cannot Solve
There is a second issue, and it is the one that breaks inventory as a concept entirely. What is in use changes. Every day.
A new microservice deploys with a default TLS configuration. A library update changes which primitive is called by default. A new certificate replaces the old one, and the new one starts negotiating with parameters the old one didn’t. A formerly retired application gets reactivated for a migration project. A vendor ships a patch that enables a different cipher suite. The cryptography that is actually protecting the network at 9 a.m. is not the cryptography that was protecting it at 5 p.m. the day before.
Inventory is a snapshot. The thing it is trying to measure is a moving picture. By the time the spreadsheet is finalized, by the time the consulting engagement delivers its report and by the time the dashboard displays its count, the underlying environment has moved on. The static deliverable describes a state that no longer exists.
From Inventory To Continuous Posture Of What’s In Use
The shift that matters is not from manual inventory to automated inventory. It is from inventory to usage, from counting to watching and from presence to behavior.
The right question is not how many cryptographic objects exist on your system. The right question is which cryptography is actively protecting which traffic, which sessions and which data at this moment, and if any of it is broken. That is a fundamentally different observation problem. It requires watching the network continuously. It requires measuring what is being negotiated, not what is sitting on disk. It requires a platform that updates as the environment updates.
Inventory tells a security team what they have. Usage tells them what is happening. Only one of those answers the question that determines whether a door to breach is open.
What This Means For Buyers
If a vendor’s first deliverable is an inventory, ask what changes when a new service deploys. Ask how the inventory reflects the cryptographic configuration of a TLS handshake that happened 10 minutes ago. Ask which of the items in the inventory are actively in use right now and which are dead weight. The answers separate the platforms that are watching from the platforms that are counting.
The cryptographic posture category will be defined by the platforms that figured out usage. Inventory was a starting hypothesis. It is not the destination.
The Closing Line
You don’t have a cryptographic inventory problem. You have a cryptographic visibility problem. The two look similar from a distance. They produce very different platforms—and very different security outcomes—when you get close.
Forbes Technology Council is an invitation-only community for world-class CIOs, CTOs and technology executives. Do I qualify?
