The Long Inventory: Sequencing Post-Quantum Readiness Into Zero-Trust Delivery, 2026–2030

Every few months a board member asks the same question: are we quantum-ready? The honest answer, in most UK enterprises in 2026, is a polite shrug dressed in programme language. The question itself is badly framed. Cryptography is not a component of the network that can be swapped at the end of a project; it is the substrate on which every zero-trust control — authentication, attestation, tunnelling, signing, key custody — depends. Treating post-quantum cryptography (PQC) as a future encryption upgrade is how organisations end up with a migration they cannot sequence and a trust story they cannot evidence.

The better question is narrower and more useful: what must be true in 2026 for the migration to be provable in 2030?

Why the clock is real, and why 2026 matters

The published UK position is well known. NCSC guidance issued in 2023 asked organisations to set out a migration plan by 2028, complete the highest-priority migrations by 2031, and finish by 2035. NIST finalised its first post-quantum standards — FIPS 203, 204 and 205 — in 2024. None of this is new. What has changed is the composition of the risk register: cryptographic exposure now sits alongside supplier concentration and identity sprawl as a board-level resilience concern, partly because of the harvest-now-decrypt-later pattern and partly because regulated sectors have been pushed toward demonstrable operational resilience.

The harvest-now problem is the one that breaks the usual procrastination logic. An adversary collecting encrypted traffic today does not need a quantum computer today; they need one before the data stops mattering. For organisations holding records with seven-, ten- or twenty-year retention horizons — insurers, NHS trusts, legal firms, financial market infrastructure — the window for confidentiality is already partly closed. The relevant arithmetic is not 'when will Q-Day arrive' but 'how long must this data stay secret, and what protects it until then'.

Discovery is the first control, not a preliminary

You cannot migrate what you cannot list. The single most valuable artefact a UK technology leader can produce in 2026 is a cryptographic inventory with a named owner and a monthly refresh — increasingly described as a cryptography bill of materials (CBOM). In practice this means enumerating TLS endpoints internally and externally, SSH keys, code-signing certificates, firmware signing chains, VPN and IPsec parameters, database encryption, HSM partitions and the key ceremonies around them, plus the asymmetric algorithms baked into identity providers and service meshes.

Two disciplines make the difference between an inventory and a spreadsheet. First, generate it from configuration and telemetry rather than from a survey; self-reported inventories decay within a quarter. Second, record the algorithm alongside the asset, the data classification it protects and the business service it supports. That triad turns a technical list into a prioritisation engine, and it gives auditors something better than assurance by assertion.

Identity and certificates before algorithms

The most common sequencing error is to start with the algorithm upgrade and discover, a year later, that nobody can find the private keys. Machine identity is the practical battleground. Certificate estates in large UK organisations routinely run to five figures, with a long tail of manually issued credentials, undocumented internal CAs and expiry incidents that are tolerated as background noise.

A credible sequence therefore front-loads identity hygiene: consolidate the CA hierarchy, automate issuance and renewal, shorten certificate lifetimes where the estate can tolerate it, and put private key custody under the same governance as human privileged access. Mutual TLS inside service meshes, workload attestation and token-signing keys all deserve an explicit line in the plan. Phishing-resistant authentication is part of the same story — FIDO2 credentials rest on public-key cryptography, and their long-term assurance depends on the signature schemes underneath them.

None of this is wasted effort if PQC timelines slip. Every one of these steps reduces operational risk this year.

Segmentation as a cryptographic control

Zero-trust segmentation is usually discussed in terms of blast radius. It is also a cryptographic boundary: it determines where crypto-agility can be introduced incrementally, and where legacy equipment will otherwise force an organisation to keep a weak algorithm alive for a decade.

Prioritise by data lifetime multiplied by sensitivity multiplied by exposure. Long-lived, highly sensitive, externally reachable estates go first. Where a device cannot be upgraded — an industrial controller, a medical imager, a 1990s-era settlement gateway — the answer is not a procurement queue but isolation behind a policy enforcement point that terminates modern cryptography on its behalf. Record that decision as an accepted risk with an owner and a review date; undocumented workarounds are how entropy accumulates in a network.

Supplier evidence, not supplier reassurance

A migration sequence is only as credible as the third parties inside it. When asking suppliers about PQC readiness, discard the phrase 'we are monitoring developments' and ask for four things: a dated roadmap with dependencies, the crypto-agility of their architecture, the CBOM or equivalent for the components you consume, and a contractual right to receive updated evidence on a schedule. Cloud providers warrant a specific conversation about where the shared responsibility boundary falls for key management and for any customer-managed material.

Public sector buyers should fold these questions into existing routes — the Cyber Assessment Framework, Technology Code of Practice reviews, framework agreements — rather than inventing a parallel assurance process.

Governance that keeps the sequence honest

Six measures are enough to keep a programme moving without inventing a new reporting industry: percentage of assets with a known cryptographic profile; percentage of certificates issued automatically; mean certificate lifetime; number of suppliers with a dated migration commitment; count of crypto-agility exceptions and their age; and the date of the last rehearsal of a CA or key-compromise scenario.

The failure modes are predictable. Boiling the ocean by attempting a full estate inventory in one pass. Waiting for a product that 'does PQC' rather than building the agility to adopt one. Running the work as a procurement exercise with no engineering owner. And allowing crypto-agility to become a project with an end date, after which the estate quietly ossifies again.

A resilience programme assumes the threat will arrive unevenly and prepares to bend. That is the correct posture here. The organisations able to demonstrate trustworthy encryption in 2030 will not be the ones that bought the fastest migration; they will be the ones that started counting in 2026.