The Inventory Comes Back. Then Nothing Happens.
A post-quantum program usually starts well. Someone gets budget for an assessment, a scanner runs, and an inventory comes back — algorithms, libraries, certificates, TLS endpoints, a number on a slide. For a surprising share of organizations, that is also where the program stops for two or three quarters.
It is tempting to read the stall as a discovery problem: the inventory was incomplete, so run a better scan. That is almost never the issue. Cryptographic discovery has become a reasonably well-solved problem. Good tools exist, including ours, and the first posts in this series focused on making sure what they report is accurate and actionable.
The hard parts come after. Out of everything the inventory found, what do we fix first? And how do we fix it without breaking production, in an organization where every change has an owner, a window, and an approval? Those two questions — prioritization and remediation — are where post-quantum programs actually succeed or fail. They are also the two questions a discovery tool, on its own, cannot answer.
PQC Prioritization: Severity Is Not Priority
Every scanner assigns a severity. RSA-2048 in a TLS certificate is quantum-vulnerable; TLS 1.0 is weak; an expired certificate is expired. Those judgments are correct, and they are the same on every host. That is exactly why they cannot tell you what to do first.
Priority depends on things the scan never sees. Is this system internet-facing? Does it carry regulated or long-lived data — the kind a harvest-now-decrypt-later adversary actually wants? Is it a crown jewel application, or a development box nobody has touched since 2022? Who owns it? Two findings with identical severity can differ in real priority by an order of magnitude, and nothing in either finding says so.
Without that context, teams do one of two things. They sort by severity and start at the top, which reliably produces a month of effort on systems that did not matter. Or they recognize that severity sorting is wrong, decide they need a proper risk model first, and go build one — a working group, a workshop, a spreadsheet of weights. Months pass. The inventory ages. This paralysis ends most programs, and it drains the scarcest resource any security team has: the attention of people with full-time jobs.
The better answer is that the context mostly already exists. Criticality, data classification, ownership, and internet exposure live in the CMDB, maintained by people whose job it is. What is actually being used and reached shows up in the SIEM. Priority is the scan’s finding combined with that context — not a new model someone has to invent, but a join against systems the organization already runs.
How to Remediate Cryptographic Risk Without Disrupting Production
Suppose prioritization goes well and the team has a short list. The challenge begins.
Cryptographic changes are the category where failure is total. Swap a library, and a service that depended on a deprecated API stops starting. Tighten a TLS floor, and a partner integration nobody documented stops connecting at two in the morning. The people who own those systems know this, which is why they are rightly cautious about anyone — especially a security tool — touching them.
So effective remediation has to respect how the organization already changes things. That means a change request in the system the organization already uses, with an owner and a rollback plan, approved by a person on their schedule. It means a real way back when something breaks. And it means proof afterward that the change actually took effect, rather than a status that says it did.
You can also find leverage, and a small team should look for it deliberately. Some fixes clear whole classes of findings at once: one library version bump that covers every service built on it, one base image upgrade that retires hundreds of inherited certificates, one TLS configuration applied across a fleet. Sequencing by exposure, measured in hours of effort rather than severity, produces a very different first month.
How SafeLogic CPM Connects Discovery, Prioritization, and Remediation
SafeLogic CPM was built on the premise that discovery is table stakes and the value is in what happens next.
For prioritization, CPM reads the context an organization already maintains rather than asking it to build a risk model. ServiceNow CMDB supplies criticality, data classification, ownership, and exposure; Splunk supplies what is actually observed on the network. Each finding’s risk score combines the cryptographic issue with that business context, and the score explains itself — which factor raised it, and which source that factor came from — so the order of the queue is something a CISO can defend rather than something a tool asserted. The customer’s CMDB is authoritative by default, and absence of evidence is never treated as evidence: no observed traffic never gets recorded as “not internet-facing.”
Coverage that feeds that queue does not have to wait on an agent rollout. CPM scans GitHub repositories directly, imports the SBOMs and CBOMs an organization already produces, and ingests network and passive-sensor data, all correlating to the same asset records the CMDB context attaches to.
For remediation, CPM proposes rather than imposes. CPM packages a fix with evidence and files it as a ServiceNow change request with a rollback plan, for the system owner to approve on their schedule. When it runs, it automatically rolls back if a health check fails, and completion is verified by rescanning what the change touched rather than trusting a status flag. The remediation paths use SafeLogic’s own CryptoComply modules where a validated library is the fix, so the replacement is FIPS-validated and post-quantum-capable rather than one more thing to evaluate.
And to keep the queue from refilling while it is being worked, the same cryptographic policy that scores the estate can be enforced as a gate in CI — one definition, evaluated in both places.
How to Move a Stalled PQC Program Forward
If your program has an inventory and not much movement, the blockage is almost certainly one of the two questions above, not the scan. Three questions usually locate it:
- Can we produce the top twenty things to fix, in order, and explain why each one is where it is — using context we already have?
- When we decide to fix something, does it become a change request our change process will accept, with an owner and a way back?
- How do we know a fix actually took effect?
None of these requires a better inventory. They require connecting the inventory to how the organization already decides and already changes things. The programs that meet the post-quantum deadlines will not be the ones that found the most. They will be the ones that fixed the right things first.
If you would like to talk through where your program is stalling, our team is available for a PQC consultation.
