Inventorying what you encrypt

Ask a large organisation where it uses cryptography and the answer comes back as a certificate inventory. That inventory is usually accurate, well maintained and a small fraction of the estate. It exists because certificates expire, and an expired certificate takes a service down at an hour nobody chose. Everything else in the cryptographic estate either fails silently or does not fail at all, so nothing ever forced anyone to write it down.

This is the first task in a post-quantum migration and the one most likely to be skipped in favour of something demonstrable. Every subsequent decision is a prioritisation, and a prioritisation needs a denominator.

What the certificate list leaves out

• Data at rest: database and disk encryption, application-level field encryption, and the key management behind each.
• Backups and archives, including media written years ago under algorithms nobody has revisited, still inside their retention period.
• File transfer with partners: host keys and client keys, some issued to organisations since acquired or renamed.
• Signed artefacts: code signing, firmware signing, document signing, and anything whose signature has to verify in a dispute a decade from now.
• Tokens and sessions: signing keys for access tokens, service-to-service authentication, and the internal certificate authority a contractor stood up during an implementation.
• Devices in the field, where the algorithm sits in firmware on hardware with a fifteen-year replacement cycle.
• Third parties whose cryptography is inherited rather than chosen: managed services, the regulator's portal, the payment network, and anything terminating TLS on the organisation's behalf. None of it shows up in a scan.
• Keys inside application code and configuration files, which appear on no list and are found by reading the repository.

Every estate of any age has a key that was checked into a repository during an early sprint, moved into configuration later, and is still in use. It has no owner, no rotation record and no expiry, which is why it survived.

Interviews do not find these

We use the same method here as for decommissioning a legacy system: instrument first, ask afterwards. People answer questions about cryptography from memory of the design, and the design is not what is running.

Capture traffic at the network boundary and inside it, and record the negotiated algorithms rather than the configured ones. Scan the codebase for calls into crypto libraries, including the ones a framework makes on the application's behalf. Read the HSM inventory and the key ceremony records, if the ceremony records exist. Pull the vendor list from procurement, because much of the estate belongs to somebody else and appears only on a contract. Then interview, with the scan results already in hand, so the conversation is about exceptions instead of recall.

Run the capture across a full business cycle. Quarter-end jobs use connections that never appear in an ordinary week.

What each entry has to say

An inventory that lists algorithms is a document. An inventory that supports a plan carries seven things per entry: the system and the person who owns it by name, what is being protected and its data class, the algorithm and key length in use, where the key lives and who can reach it, the rotation and expiry position, how long the protected data must remain confidential, and what a change would depend on.

That last column is what turns a list into a schedule. Most entries depend on something outside the organisation's control: a vendor firmware release, a partner's migration, a hardware refresh in a future budget year, a certification body. Sorting by dependency lead time rather than by risk score produces a plan that can start, because the long-lead items are the ones to raise in procurement conversations happening this quarter.

Expect the first pass to be wrong

On one estate our first pass missed partner file transfer keys entirely, because nobody in the workshop thought of SFTP as cryptography. A network capture surfaced them, along with two service accounts no team would claim. We have also found an internal certificate authority on a virtual machine excluded from patching for four years, because nobody knew what it did.

None of that is a reason to plan more carefully before starting. Publish the incomplete inventory and let the gaps be found by the people who notice their own system missing from it. An inventory kept as a living record with a named owner is worth several of the kind produced once, signed off, and left in a document library while the estate changes underneath it.