Your inventory lists everything. What should change first?

Most cryptography programmes begin with a cryptographic inventory, and they’re right to. The 2023 quantum-readiness factsheet from CISA, the NSA and NIST tells organizations to prepare one as an early step. Within weeks, the inventory holds thousands of rows of keys, certificates and algorithms. Then come the questions the list can’t answer. Which of these matter? Who owns them? What do we change first?

Why an inventory alone stalls

An inventory records objects: a certificate on an address, a key in a vault, an algorithm compiled into a library. It doesn’t know that one of those certificates protects your payment service and another protects a test site nobody uses. Ranked by count, or by severity alone, the two look the same.

Cryptography also sits across cloud services, applications, infrastructure and build pipelines, each tracked, if at all, by a different team. The inventory puts the objects in one place. The context that turns them into decisions lives somewhere else: a service catalogue, a spreadsheet, or someone’s memory.

So the programme produces a large record and very few decisions, and the people funding it start asking what they bought.

Four steps from record to decision

The work between a record and a decision follows the same pattern in most organizations:

• Connect each finding to an application. A finding about a certificate becomes a finding about the customer login service.
• Connect each application to an owner. A named team that can make the change and answer for it.
• Rank by what the application does for the business. Payments, identity and long-lived records come before an internal tool, even when the tool has more findings.
• Decide what changes first, and who makes the change, with dependencies known before anyone touches anything.

Rank by business impact, not by count

The most common mistake is ranking by the number of findings. A busy internal application can collect hundreds of minor issues while a single weak key protects the service your customers depend on.

Rank by what each application does, how long its data has to stay private, and how hard it would be to change. Data that must stay confidential for decades carries a risk today, for reasons explained in data stolen today, decrypted later.

Keep the worst problem in view. If an application has one critical weakness and fifty trivial ones, an average will make it look fine, so the ranking should lead with the single worst exposure.

Keep the facts traceable

A ranking is only as good as the facts behind it. Record where each fact came from and when it was observed, so anyone can check it and repeat it. A certificate replaced last month shouldn’t still be driving this month’s priorities.

Keep the gaps visible too. A system nobody scanned isn’t a clean system, and a record that hides its blind spots will rank them as safe. Saying what wasn’t checked is part of the result.

A CBOM, a machine-readable record of the cryptography in use, is one way to keep those facts in a form other tools and auditors can read.

A worked example

Illustrative: an inventory of one business unit finds 4,200 certificates, 900 keys and eleven algorithms. Ranked by count, the internal analytics platform comes first, with 600 findings, most of them certificates that expire soon on test environments.

Connected to applications and owners, the picture changes. Three findings sit on the card authorization service: a key below today’s minimum, a method that needs a quantum-safe plan, and a certificate shared with a partner gateway. The payments team owns all three and has a change window next month. The analytics findings are real but low risk, and their owner can absorb them in normal maintenance.

The decision writes itself: fix the authorization service’s weak key in next month’s window, add its quantum-safe change to the plan, and schedule the analytics clean-up, none of which was visible from the raw count.

Questions to ask of any inventory

• Can every finding be traced to an application and a team that can change it?
• Does the ranking reflect what each application does for the business, or just how many findings it has?
• Does each fact carry its source and the date it was observed?
• Does the inventory say which systems it didn’t reach?

Where Arcrix™ helps

Arcrix™ by QTrino Labs ties every finding to its application and owner, with the source and date of each fact, scores risk today and risk from quantum computers side by side, and ranks what matters, so your teams get a plan instead of a raw list. Where it couldn’t see something, it says so.

When one weak key is shared by three applications, Arcrix™ shows it under each of them, so every owner sees it, and counts it once in the totals, so the picture isn’t inflated.