Six Hundred Findings, and Nothing to do on Monday
The first cryptographic discovery scan an organization runs almost always comes back looking impressive. Hundreds of findings. Weak keys, aging algorithms, certificates flagged as quantum-vulnerable across every host in the estate. The tool clearly worked.
Then somebody has to decide what to fix, and the report falls apart. Most of those certificates turn out to be the public root CAs that ship in the base operating system image — the same two hundred certificates on every host, repeated, all of them technically using classical cryptography, none of them anything the host’s owner can change. A large share of the rest belong to a vendor. What remains — the certificates the organization actually issued, deployed, and is responsible for — is a small fraction, and it is not marked in any way that distinguishes it from the noise.
So the report gets exported, circulated, and quietly ignored. Not because the findings were wrong. Each one was accurate. They were simply not decisions, and security teams spend their time on decisions.
This is the second way a cryptographic inventory fails you. The first, which I wrote about in the last post, is a report that is true but does not answer the question you thought it did. This one is a report that answers completely and gives you nothing to act on — and it is more dangerous, because volume reads as thoroughness. A tool that returns six hundred findings feels more rigorous than one that returns twelve. Usually it is the opposite.
Another discipline worked this out at scale a decade ago. Google spent years building Tricorder, the static analysis platform that runs against their code, and the lesson they published in Communications of the ACM in 2018 transfers directly: “analysis tools measure their utility by the number of issues they identify, while integration attempts fail due to the low number of bugs actually fixed or prevented.” Their response was to make the analysis teams responsible for fixing, not just finding, and to measure themselves accordingly.
The sharpest idea in that work is a definition. A finding is an effective false positive if the person who saw it took no action — whether or not it was technically correct. Correctness is not the test; consequence is. By that standard, four hundred base-image CA certificates are four hundred false positives, no matter how accurately each one was described. Google held the analyses shown during code review to a ceiling of 10% effective false positives. A crypto discovery report whose volume is mostly unactionable is not within an order of magnitude of that bar.
Which gives you the buying criterion: not how much a tool finds, but how much of what it finds gets fixed.
The Question that Sorts an Inventory
Most tools sort findings by condition: how weak is the key, how close is the expiry, how quantum-vulnerable is the algorithm. That is the wrong first cut, because condition says nothing about whether you can do anything.
The question that actually sorts an estate is: who put this here, and can I act on it?
Ask it, and an inventory separates into four groups that behave completely differently.
| Group | What it is | What you do |
| Yours | Certificates and crypto your organization created, committed, or deployed | Own it. This is the work. |
| Rides with the base image | Trust anchors and system crypto that arrived with the OS or container image | Nothing per item. It refreshes when the image is upgraded |
| A vendor’s | Material managed by a SaaS provider, CDN, or appliance vendor | Escalate to them, track the commitment |
| Unattributed | Nobody can say where it came from | Find out. This group should be small and shrinking |
The second group is where the noise lives, and it is genuinely non-actionable. A host operator cannot change the root CA bundle their base image ships; the remediation for every certificate in that group is the same single action — upgrade the image — and listing it four hundred times does not make it four hundred pieces of work.
The third group matters for a different reason. A vendor-managed certificate is real risk, and it is still not your remediation. What you need there is not a ticket for your engineers but a record of which vendor owns it and what they have committed to, which is a procurement conversation, not an engineering one.
And it is worth saying plainly that this is a reporting problem before it is a technical one. A CISO asked for the post-quantum exposure number should be able to give a figure that survives the follow-up question — how much of that is ours to fix? An inventory that cannot separate the four groups cannot answer it.
Where SafeLogic CPM Fits
SafeLogic CPM classifies every certificate it finds along the ownership axis described above at the moment it is discovered, from signals the scan already captured rather than from anything an operator has to tag by hand. Each one carries a provenance — yours, base-image, third-party, or unattributed — and an action verdict: act now, rides with the base image, vendor’s to fix, or healthy and worth monitoring. Both are filters, so “show me what is actually mine and actually broken” is a view rather than a spreadsheet exercise.
The public roots that appear on every host collapse into a single trust-anchor row per issuing CA, so the PKI view shows one line for a root shared across a thousand machines instead of a thousand lines. Certificates with a base-image or vendor-managed verdict drop out of the findings list and the remediation queue while staying in the inventory, exportable and auditable.
Severity works the same way. Context adjusts a finding only under narrow, published rules; the adjustment is recorded on the finding with the rule that caused it, and the guard against a host whose own code still uses classical algorithms is built in rather than advisory. Nothing is deleted — the queue is just limited to work someone can actually do.
One consequence worth naming: severity in CPM is a function of the rule and the context, not a value frozen at scan time. When policy changes or the ecosystem moves, findings re-grade. An inventory that hard-codes last quarter’s judgment is a snapshot, and organizations are trying to get away from snapshots.
Three Questions for Your Current Inventory
Worth asking whoever owns cryptographic discovery in your organization:
- Of the findings in our last report, how many are ours to remediate, how many ride with an OS base image, and how many belong to a vendor? If nobody can produce that split quickly, the report is a list rather than a plan.
- Has any finding ever been lowered in severity because of context, and can we see why? A tool that only escalates is not prioritizing.
- When a downgraded finding stops being non-actionable — the policy tightens, the ecosystem moves — does it come back on its own, or does someone have to remember?
The post-quantum deadlines now in view will be met by organizations that spent their time on the work that mattered, not the ones that generated the most findings. Separating the two is not a reporting nicety. It is most of the job.
If you would like to walk through what your current inventory can and cannot separate, our team is available for a PQC consultation.
