Ask most IT leaders where their cryptography lives, and the honest answer is "we're not sure." Encryption, digital signatures and certificates are in nearly every app, device and cloud service. Few organizations have a reliable record of which algorithms they use, where they live and who is responsible for them.
That gap has existed for years without much consequence; however, two forces are now making it expensive. The first is the move to post-quantum cryptography, where every migration plan starts with knowing what you have. The second is the rapid spread of AI agents, which are adding new systems that depend on cryptography faster than most estates can track them.
This article sets out a practical approach to building a cryptographic inventory, showing what you can achieve with your existing data. It highlights the tougher gaps, explains how to close them and discusses how to keep the inventory useful once it's created.
What a cryptographic inventory is and isn't
A cryptographic inventory is a structured record of the cryptography in use across an organization. For each item, you should capture the algorithm and key length, along with the systems that use it, the systems that depend on it and the owner.
People often confuse a cryptographic inventory with a certificate inventory. Certificates matter, but they are only one part of the picture. A full inventory also covers the following:
- Encryption keys, whether held in hardware security modules, cloud key management services or files on disk.
- Cryptographic libraries and the versions embedded in software.
- Protocols and cipher suites negotiated between systems.
- SSH keys, code signing keys and API secrets.
- The trust stores that decide which certificates a system will accept.
You might also see the term cryptographic bill of materials (CBOM). A CBOM is a standard format that machines can read. It records information such as a software bill of materials, which lists software components. The inventory contains the information; the CBOM is one way of storing and sharing it.
Why it matters now
Post-quantum deadlines have been set. NIST's draft guidance, NIST IR 8547, recommends dropping quantum-vulnerable algorithms such as RSA-2048 and ECC P-256 after 2030. It also plans to ban RSA and ECC entirely after 2035. In the U.K., the NCSC's migration timelines require organizations to finish discovery and an initial plan by 2028. They should complete high-priority migration by 2031 and wrap up all migration by 2035. Both start in the same place: you cannot migrate what you cannot find.
Some data is already at risk. Attackers can grab encrypted traffic now and keep it until a powerful quantum computer can decode it. This is known "harvest now, decrypt later." Data that must stay confidential for 10 years or more is at risk now, not in 2035.
AI agents are adding cryptography at speed. Every AI agent that calls an API, connects to a tool server or authenticates to another service relies on certificates, keys and trust stores. Industry work on workload identity now sees agents as workloads. They have their own credentials. Many developers create them using notebooks, ad hoc container images and tools outside regular IT asset management. Without an inventory, agent sprawl quickly becomes cryptographic sprawl that nobody can see.
The visible half: start with data you already hold
The good news is that much of the picture can be assembled quickly. Most organizations already hold the data, but they haven't brought it together. A few weeks of focused effort can produce a working first view.
Here's what to look at:
- Internal certificate authorities (CA). Every private CA, such as Microsoft Active Directory Certificate Services, keeps a record of what it has issued. Export it. This gives algorithms, key lengths, expiry dates and, often, the requester.
- Certificate Transparency logs. Public logs record the TLS certificates issued for your domains. Checking the logs shows what was done in your name. This includes certificates you weren’t told about.
- Network scanning. Scanning internal and external endpoints shows the protocols, cipher suites and certificates being used. Many vulnerability scanners already collect this data.
- Cloud key management and hardware security modules. Cloud key management services and hardware security modules can show the keys they store. They also list the algorithms and how those keys are used. This is usually a configuration report, not a project.
- Software bills of materials. If you produce SBOMs, they already list the cryptographic libraries in your software and their versions.
- Existing tools. Certificate lifecycle management, configuration management and asset management tools often hold important cryptographic information.
This work shows you the visible part of the estate: the cryptography that someone manages, networks or issues from a central point. It is enough to start sizing the problem, identifying obvious weaknesses and putting names against systems. But it’s not the whole picture, and it is important not to treat it as such.
The hard half: where the gaps are
The remaining cryptography is harder to find. It isn't centrally issued, isn't visible on the network and isn't under your direct control. These are the areas that most often surprise teams late in a migration:
- Cryptography hardcoded in applications. Algorithms and key lengths written directly into application code do not show up in a CA database or a network scan. Changing them means changing the code.
- Operational technology and embedded devices. Industrial control systems, medical devices, network appliances and IoT devices often rely on fixed cryptography. They have long replacement cycles. Many cannot be scanned safely, and some cannot be updated at all.
- Third parties and SaaS. Suppliers, cloud services and partner integrations use cryptography you depend on but cannot inspect. You are reliant on what they tell you.
- Data at rest and backups. Encrypted databases, archives and backups might use algorithms chosen years ago. Long-retention data is often where harvest-now, decrypt-later risk is highest.
- SSH keys, code signing keys and secrets. These are frequently created by individuals, rarely expire and are seldom recorded centrally.
- Trust stores. OSes, language runtimes, container images and appliances each have their own trusted root certificates. Few organizations know the number of trust stores they have or how to update them.
There is also a subtler gap. Knowing which algorithms a system supports is not the same as knowing which it actually uses. A server might offer modern cipher suites while still negotiating older ones with legacy clients. Both views are needed.
Closing the gaps
The hard half of building a cryptographic inventory rarely yields to a single tool. It needs a mix of technical discovery, supplier engagement and clear ownership. Four approaches make a big difference:
- Prioritize by risk, not by coverage. Chasing 100% coverage before acting is a common reason why inventory programs stall. Instead, rank systems by how long their data must stay confidential, how critical they are to the business and how hard they would be to change. A payments platform that holds customer data that must stay confidential for a decade matters more than an internal test server. Focus discovery effort where the risk sits.
- Look inside the code. Static analysis and software composition tools can find cryptographic calls and libraries in source code and build artifacts. Adding these checks to development pipelines catches hardcoded algorithms before they reach production. It also covers the AI agents and tool servers that development teams are building now.
- Ask suppliers directly. For third parties, SaaS and devices that you cannot scan, use questionnaires and contract clauses. Ask which algorithms they use, whether they have a post-quantum roadmap and when it will be delivered. Their answers belong in the inventory too, with a review date.
- Make system owners accountable. A central security team cannot know every system. Each system owner should record and confirm the cryptography in their area. Where full discovery is not possible, accept a documented estimate and a named owner over a blank entry.
For systems that genuinely cannot be inventoried or changed, record them as known exceptions. An honest list of what you cannot see is far more useful than a false sense of completeness.
Keeping it current
The inventory becomes out of date the day after completion. New applications launch, certificates get reissued, suppliers switch platforms and teams deploy new AI agents. A one-off audit gives you a snapshot. Migration needs a live record.
Here's what to do to keep your cryptographic inventory up-to-date:
- Make discovery continuous. Schedule scans and CA exports to run automatically, and compare each run with the last. Changes should be flagged, not found by accident.
- Build it into change. Add cryptographic checks to CI/CD pipelines and change control. This way, new systems are recorded as they’re built, not found later.
- Set procurement standards. New products and services must specify the algorithms they use. They should also explain how they support post-quantum algorithms. Ask whether cryptography can be changed through configuration rather than a software rewrite.
- Name an owner for the inventory. Someone must be accountable for its accuracy, with a regular review cycle and reporting to senior leadership.
- Use a standard format. Recording the inventory in a structured format such as a CBOM makes it easier to share, automate and compare over time.
Done well, the inventory stops being a project deliverable and becomes part of normal operations. That’s the key to crypto agility: changing algorithms quickly when new weaknesses or standards emerge.
Start with what you can see
A cryptographic inventory is the first step in any post-quantum plan, and the step most organizations have not yet taken. It does not need to be perfect to be useful.
Start with the visible half, using data you already hold. Prioritize the less visible half by risk. Record what you cannot see as honestly as what you can. Then build the processes that keep it current.
Darren Davies is CEO of Unsung, a U.K.-based consultancy specializing in public key infrastructure (PKI). He has more than 20 years of experience in IT, including PKI and identity and access management. His career spans technical, solution and enterprise architecture roles before moving into the C-suite.
Darren has worked across defense, manufacturing, financial services, retail and consulting, always focusing on aligning business vision with technical strategy. At Unsung, he has doubled the managed service portfolio, introduced the PKI Health Check service, and led the company to ISO 27001 certification.
Outside work, Darren records and performs music at weddings and corporate events. He is also renovating a property, despite vowing never to take on such a project again.
