Post Quantum Risk Drivers

Seven drivers that determine post-quantum risk exposure

Two organisations in the same sector, of similar size, can carry very different post-quantum exposure. Three drivers determine how exposed an organisation is: data confidentiality lifetime, network exposure and asset longevity. Four determine how quickly it can respond: cryptographic visibility, architectural coupling, key lifetimes and supplier dependency.

What determines post-quantum cyber security exposure?

Sector is a useful first approximation and a poor final answer. Two NHS trusts, two retail banks or two defence suppliers can differ by years in how long migration will take and by an order of magnitude in how much data is already exposed.

The distinction that matters is between drivers of exposure and drivers of response speed. Exposure drivers determine how much harm is accruing and how urgently it must stop. Response drivers determine whether the organisation can act within the window available. An organisation with modest exposure and very poor response capability can be in a worse position than one with high exposure and a well-managed cryptographic estate.

Only the exposure drivers are largely fixed. All four response drivers can be improved deliberately, and improving them delivers value before any post-quantum work begins.

Drivers that set how exposed you are

Driver one: data confidentiality lifetime

The single largest factor. Data that must remain confidential for thirty years and is transmitted today under RSA or elliptic curve protection is exposed now, because encrypted traffic can be captured and stored until a capable machine exists.

The value is set by regulation, contract and the practical sensitivity of the information, not by retention policy. Two organisations handling superficially similar data can differ substantially: an insurer writing annual motor policies and an insurer writing whole-of-life cover hold data with confidentiality lifetimes decades apart.

Driver two: network exposure and adversary interest

Exposure to harvest now, decrypt later requires someone to be collecting. Traffic crossing international links, third-party carriers, satellite paths or the public internet is more collectible than traffic confined to a private network within a single jurisdiction.

Adversary interest compounds this. Nation-state collection is targeted rather than indiscriminate, so organisations of strategic, intelligence or economic significance should assume collection is occurring, while those of low strategic value face a smaller confidentiality risk although the same authentication risk.

Driver three: asset longevity

Migration cannot outpace hardware. An estate refreshed on a three year cycle migrates through normal procurement. An estate containing controllers, meters, medical devices, signalling equipment or embedded modules with twenty-five year service lives contains assets that will not be replaced before 2035 and in some cases cannot be updated at all.

The most severe case is an immutable root of trust, where a verification key is burned into silicon at manufacture. Those assets require replacement rather than migration, which converts an IT change into a capital programme with a multi-year lead time.

Drivers that set how quickly you can respond

Driver four: cryptographic visibility

The largest determinant of migration duration is whether the organisation knows where its cryptography is. Public certificates are straightforward to enumerate. Keys embedded in application code, appliance firmware, hardcoded trust stores, integration middleware and supplier interfaces are not, and enumerating them requires a deliberate discovery programme rather than a report from an existing platform.

Organisations that already maintain a cryptographic inventory start migration at the point others start discovery. That difference alone can be substantial.

Driver five: architectural coupling

Systems that reference algorithms by name, hold cryptographic parameters in compiled code, or assume fixed key and signature sizes require code change to migrate. Systems that reference cryptographic classes, hold parameters in configuration and size buffers dynamically require configuration change.

This is what crypto agility means in practice, and it is inherited rather than chosen. Post-quantum key and signature sizes are one to three orders of magnitude larger than their classical equivalents, so hardcoded field lengths and fixed buffers fail before any cryptographic issue arises.

Driver six: certificate and key lifetimes

Short-lived certificates clear an estate through ordinary rotation. Where certificates are issued for 47 days and renewal is automated, an algorithm change propagates within weeks of the issuing authority being reconfigured. Where certificates are issued for three years and renewed manually, the same change takes years and requires individual intervention on every endpoint.

The same applies to keys. Long-lived signing keys, root certificates and firmware verification keys persist by design, which makes them both the hardest to change and the most attractive target for an early, scarce quantum capability.

Driver seven: supplier and third-party dependency

An organisation cannot migrate a platform its supplier has not upgraded. Where core systems are delivered as SaaS, managed services or vendor-supported appliances, migration timing is set by the supplier's roadmap and by contractual refresh cycles.

Exposure also transfers. Data held or processed by a supplier under quantum-vulnerable protection is exposed on the supplier's terms, not the customer's, and few contracts currently address cryptographic obligations explicitly. This is why the NCSC directs organisations to communicate requirements to suppliers during the discovery phase, in 2028 terms, rather than at the point of migration.

Scoring post-quantum cyber security exposure

The drivers can be assessed quickly, and a first pass usually takes a workshop rather than a project.

Two organisations scoring identically on the first three drivers and oppositely on the last four will have materially different migration durations, which changes the answer to the underlying question in any quantum risk assessment.

How the drivers combine in practice

A worked contrast makes the interaction clear. Consider two NHS trusts of similar size.

The first has a certificate lifecycle management platform in place, automated issuance, a maintained inventory covering internal certificate authorities and medical device certificates, and a clinical systems supplier that has published a post-quantum roadmap. Its exposure drivers are high, since patient data retention runs to decades, but its response drivers are strong. Migration is a planned programme of perhaps two to three years.

The second issues certificates manually from an unmonitored internal certificate authority, has no record of which medical devices hold certificates or from where, and depends on several suppliers who have not been asked the question. Its exposure is identical. Its response time is five years or more, most of it discovery, and it cannot begin the calculation because it cannot estimate migration duration at all.

The difference between the two is not budget or sector. It is four response drivers, all of which were determined by decisions taken before post-quantum cryptography was a consideration.

What regulation changes and what it does not

Regulatory milestones set the compliance deadline. They do not change any of the seven drivers, and they do not accelerate a supplier's roadmap or shorten a discovery exercise.

The NCSC expects discovery and an initial migration plan by 2028, highest-priority migration by 2031, and completion by 2035. NIST IR 8547 deprecates quantum-vulnerable algorithms from 2030 and disallows them from 2035. For organisations supplying US federal customers, Executive Order 14412 set key establishment and signature deadlines of 2030 and 2031 respectively, with contractor obligations attached.

The practical effect of these dates is to convert response driver weakness into a compliance problem with a fixed date, which is usually what secures funding for the discovery work that should have happened anyway.

Improving post-quantum cyber security fastest

Three of the four response drivers can be improved without any post-quantum decision being made, and each delivers benefit independently.

Discovery is first and unavoidable, and it produces an inventory that supports audit, incident response and outage prevention regardless of quantum considerations. Certificate lifecycle automation is second, since it shortens key lifetimes, removes manual renewal and gives the estate the property of clearing itself through rotation. Supplier engagement is third and is largely a procurement exercise: asking each supplier for a stated post-quantum roadmap, and adding cryptographic obligations to contracts at the next renewal.

Architectural coupling is the slowest to fix, because it requires code and design change, which is why it is addressed through standards applied to new systems rather than through remediation of existing ones.

How Unsung helps

Unsung is a UK-based, vendor-neutral consultancy specialising exclusively in public key infrastructure and cryptographic systems, working across central government, defence, healthcare, financial services, nuclear and transport.

We assess all seven drivers through our PKI health check and cryptographic bill of materials services, then address the response drivers directly: discovery to establish visibility, certificate lifecycle management to shorten key lifetimes and automate issuance, and target architecture design to reduce coupling in new systems.

For sector-level context, see how post-quantum risk exposure varies by sector.