Post-Quantum Cryptography: Why We Should Start in the Middle

Post-quantum cryptography is often presented as a problem of discovery.

Find the cryptography. Identify what’s vulnerable. Work out what’s important. Pick a few representative systems. Run a pilot. Prove the technology. Then gradually expand the programme.

It is a sensible approach. In fact, much of the current guidance around post-quantum migration quite rightly emphasises discovery, inventory, prioritisation and risk-based migration planning. NIST, for example, describes understanding where and how cryptography is being used as a fundamental part of preparing for the transition. (NIST)

But there is another way to think about the problem.

Start in the middle.

Rather than beginning at the edge of the estate with a narrowly defined pilot, or trying to identify the single biggest quantum risk before doing anything else, establish the point around which the entire migration can be governed.

Treat post-quantum cryptography as what it ultimately is: another enterprise cyber transformation programme.

Don’t start with the cryptography. Start with the programme.

One of the challenges with PQC is that the problem initially feels almost impossibly broad.

Cryptography is everywhere. It is embedded in operating systems, applications, databases, network infrastructure, identity systems, cloud services, appliances, firmware, certificates, APIs and third-party services. Some of it will be obvious. Much of it won’t.

That can make the first question seem like:

“Where do we start looking?”

I think a better first question is:

“Where are we going to manage this?”

Establish a central point of governance for the programme.

That might be a dedicated PQC capability within an existing cyber platform, or a new platform designed specifically to provide the central control point. The important thing is that it becomes the place where the organisation builds its understanding of the problem, records decisions, tracks progress and ultimately demonstrates that it is managing the transition.

This changes the character of the exercise.

It stops being a collection of discovery projects and technology pilots and starts looking much more like the compliance, vulnerability management, asset management and cyber transformation programmes organisations already know how to run.

And that familiarity matters.

Establish the baseline you already have

The first input shouldn’t necessarily be a cryptographic scanner.

It should be the organisation’s existing understanding of itself.

• Import the CMDB.
• Bring across the known applications, servers, devices, services, business systems and owners.
• Connect that information to whatever other sources already exist across the organisation.

Suddenly, the PQC programme has an environment in which to operate.

• You have assets.
• You have ownership.
• You have relationships.
• You have business context.
• You have something against which new intelligence can be overlaid.

And, importantly, you don’t have to create another parallel version of the organisation’s technology estate just because the problem happens to be quantum cryptography.

Then add the business context

Technology inventory on its own isn’t enough.

The organisation needs to understand what actually matters.

Which business services are critical? Which processes underpin them? Which systems support those processes? Which data is commercially sensitive, operationally important or subject to long-term confidentiality requirements?

This is where the PQC programme becomes much more than a technical exercise.

Map infrastructure and applications to business priorities and critical functions.

Now, when a new cryptographic dependency is discovered, it isn’t simply another finding in a giant spreadsheet.

It has context.

The organisation can begin to answer questions such as:

• What business capability does this system support?
• How important is that capability?
• What data is involved?
• Who owns the system?
• What other systems depend upon it?
• Is the technology approaching an existing refresh or replacement cycle?
• Does the supplier have a PQC roadmap?
• What would remediation actually involve?

That is a much more useful conversation than simply asking whether a particular algorithm is quantum vulnerable.

Bring in the intelligence you already have

The next step is to bring existing intelligence into the same picture.

• Existing vulnerability information.
• Technology inventories.
• Supplier information.
• Certificate inventories.
• Architecture data.
• Cloud inventories.
• Application information.
• Known cryptographic dependencies.
• Existing risk assessments.
• Threat intelligence.

Anything that helps describe the environment should contribute to the picture.

Then begin adding the new sources.

• Cryptographic discovery.
• Network scanning.
• Endpoint telemetry.
• Application analysis.
• Certificate discovery.
• Vendor assessments.
• Software bills of materials.

Whatever sources are available and appropriate.

The important change is that discovery is no longer the programme. Discovery becomes an input to the programme.

Let the picture emerge

This is where a central platform becomes particularly powerful.

Instead of expecting the organisation to know the answer before it starts, let the platform progressively construct the answer.

Initially, the picture will be incomplete.

That’s fine.

• You might know that an application exists but not exactly where it uses public-key cryptography.
• You might know that a server exists but not which services depend upon it.
• You might know that a supplier provides a critical service but not when they will support PQC.
• You might have vulnerability information without a clear understanding of business impact.
• As additional information arrives, the picture becomes richer.

CMDB + business context + existing intelligence + discovery + scanning + supplier information + risk = an emerging organisational view of PQC exposure.

That is considerably more valuable than a static cryptographic inventory.

The objective isn’t simply to produce a list of vulnerable algorithms.

It is to build an evolving model of where quantum risk exists, why it matters, what depends upon it and what the organisation should do about it.

Then prioritise

This doesn’t mean ignoring risk. Quite the opposite.

It means that risk prioritisation happens inside the wider governance model rather than being used as the starting point for the entire programme.

Once the picture starts to emerge, the organisation can identify the systems and dependencies that matter most.

Some will be obvious candidates for early migration. Others may be approaching technology refresh anyway.

Some may depend entirely on a supplier roadmap. Others may require significant application redevelopment.

Some may be technically vulnerable but relatively straightforward to address.

Others may represent small technical findings sitting underneath hugely important business services.

The point is that prioritisation becomes informed by multiple dimensions rather than a single technical risk score.

Plan the migration — and drive it

At this point, the organisation has something it can actually manage.

• Create the roadmap.
• Assign ownership.
• Set target dates.
• Record dependencies.
• Track supplier commitments.
• Link remediation activity to projects and technology refresh cycles.
• Identify blockers.
• Monitor progress.
• Escalate where necessary.

And keep updating the underlying picture as new intelligence arrives. The platform becomes the system of record for the programme.

• Not just an inventory.
• Not just a scanner.
• Not just a dashboard.

The governance layer for the transition.

That distinction is important because PQC migration is unlikely to be a single project with a clean beginning and end.

It will be a multi-year transformation.

Standards will evolve. Products will acquire PQC capabilities. Suppliers will publish roadmaps. New vulnerabilities will be discovered. Systems will be replaced. Organisations will acquire and retire technology.

The picture will change continuously, and the governance capability therefore needs to change with it.

Proper governance

We know the problem is broad and potentially deeply embedded in the technology estate, yet our instinct is often to make the first step smaller.

Pick the highest-risk assets. Prove the technology. Then expand. There is nothing wrong with any of those activities. They will all have a role. But perhaps the first step doesn’t need to be at the edge of the problem.

Start in the middle.

This approach doesn’t attempt to solve the entire PQC problem on day one. It creates the machinery through which the organisation can progressively understand and solve it.

And perhaps most importantly, it makes PQC feel like something organisations already know how to do.

• They already know how to run compliance programmes.
• They already know how to manage vulnerabilities.
• They already know how to govern technology risk.
• They already know how to assign ownership, track remediation and report progress.

The opportunity is to make post-quantum migration another managed cyber transformation, rather than a mysterious new discipline requiring an entirely separate way of working.

The quantum problem may be new, but The way we manage it doesn’t have to be.

We have this PQC governance platform ready for you now. And you can try it with no obligation. Just get in touch.

LINK – Taylor Harrow – Linked In or Mark Sones – Linked In