Post-Quantum Cryptography

You commissioned bespoke software. No one is coming to update it for you

Rajiv Abeysinghe · 3 July 2026 · Sources: NIST, NCSC, ETSI · Last reviewed: 3 July 2026
AI-assisted drafting · independent cross-model review (DeepSeek, Gemini) before publication

The application went live in 2018. A development agency built it. Client onboarding, document upload, encrypted data in transit. £180,000 contract. The agency was acquired three years later. The source code is somewhere on a server. Nobody is entirely sure where.

The application still runs. Thousands of client records flow through it every month. Somewhere in its dependencies sits a cryptographic library that last received a meaningful update before post-quantum cryptography was a boardroom conversation.

This is not a hypothetical. It describes a category of risk that most PQC guidance skips entirely — because most PQC guidance assumes you are a large enterprise with a dedicated security team, a software asset register, and a vendor who will push an update. Many organisations are not that. The ones that aren't are the ones most exposed.

The assumption that fails

The standard advice runs like this: post-quantum cryptography is coming; your vendors are preparing; the big platforms have published roadmaps; check with your suppliers and hold them to the published milestones.

That advice is correct — for the slice of your operation that runs on commercial off-the-shelf software. The NCSC's own timeline guidance says as much: organisations on commodity IT should inherit the migration through vendor updates. The same document is equally clear about the other slice — organisations running custom or bespoke systems follow the full migration timetable themselves: plan by 2028, priority migrations by 2031, complete by 2035.

If your organisation has ever commissioned bespoke software — a client portal, an internal workflow tool, a custom API connecting two systems that do not natively speak to each other — you have cryptographic assets that no vendor update will touch. The migration is yours to own. Most organisations have not started.

What NIST settled in August 2024

On 13 August 2024, the US National Institute of Standards and Technology finalised the first post-quantum cryptographic standards. FIPS 203 defines ML-KEM for key establishment. FIPS 204 defines ML-DSA and FIPS 205 defines SLH-DSA for digital signatures.

The algorithms are finalised. The standards are published. The migration path exists. The question is not whether quantum-resistant cryptography is available. It is whether your bespoke software can reach it. For most organisations running legacy bespoke applications, the honest answer is: we do not know, because we have not looked.

The threat that is already active

Post-quantum risk is not entirely a future problem. The attack is retrospective: an adversary captures encrypted data in transit today, stores it, and decrypts it when quantum computers arrive. The NCSC describes the risk plainly — data collected and stored today, decrypted at some point in the future — and notes it is worthwhile precisely for high-value, long-confidentiality data.

Any sensitive data your bespoke application transmitted over the last five to ten years, encrypted under RSA-2048 or ECDH key exchange, is a candidate. Client financial records, medical information, legal privilege, intellectual property — if your bespoke system handled any of it, the exposure window opened years ago.

Three failure modes specific to bespoke software

COTS systems have a defined migration path: the vendor updates the product; you update your instance. Bespoke software has none of that. What it has instead is one of three failure modes.

The source code problem. Many organisations commissioned software without establishing clear ownership of the codebase. The contract specified deliverables, not IP transfer. The agency merged, was acquired, or closed. You cannot migrate cryptographic libraries in software you cannot open.

The dependency blindspot. Organisations that do have the source code often cannot say which cryptographic library it uses or what version. The application works. Nobody has audited its dependencies since the original engagement. Whether it can support ML-KEM is unknown — because nobody has asked.

The architectural entanglement. The hardest case: you have the code, you know the dependencies, and you discover that key-exchange logic is embedded in ways that cannot be swapped cleanly. The migration is not a dependency update. It is a partial rebuild.

None of these are resolvable by asking your cloud provider when they expect to be PQC-ready.

The audit that has to happen first

Migration cannot precede inventory — the sequencing every authority agrees on. ETSI's migration framework puts inventory as stage one of three; the NCSC's first milestone, due 2028, is exactly that discovery exercise. For bespoke software, the inventory answers four questions.

Which applications handle sensitive data that is encrypted? A custom dashboard pulling anonymised metrics is different from an onboarding portal transmitting personal financial data. Start where encryption failure has the highest consequence.

What cryptographic algorithms and libraries do they use? This requires the source code and someone able to read it. The answer is not always what the original documentation says.

Is the source code accessible and under your control? If not, that is a finding before any PQC discussion. IP ownership and escrow are contractual matters, not technical ones.

Who has the expertise to migrate it? The original developer may be gone. Knowing the gap is the beginning of addressing it — and the NCSC now runs a pilot PQC consultancy assurance scheme for organisations that need vetted help.

What the deadlines actually mean for a build

For bespoke systems, 2035 is not a delivery date. It is the end of a programme that works backwards: cryptographic inventory now; source-code ownership resolved through 2027; dependency audits complete by 2028 — the NCSC's planning milestone; migration work, including any partial rebuilds, scheduled across 2028–2031 for the systems that matter most. That is a multi-year programme for organisations that start immediately. Organisations that begin in 2028 will be writing the plan on the day it was due.

The one action that precedes everything else

Commission the cryptographic inventory. Not a full security audit. Not a vendor assessment. Specifically: a structured review of every bespoke application you run, asking the four questions above. The output is a risk-ranked register — applications handling long-lived sensitive data under RSA or ECDH, with uncertain source-code access, at the top.

That register is the starting point for every subsequent conversation — with boards, with development partners, with the suppliers who will eventually do the migration work. Without it, all post-quantum planning is a discussion about a problem the organisation has not yet described.