PQC Implementation: Funding Migration Through Refresh Cycles

Funding post-quantum migration through refresh cycles

Most of the cost of post-quantum migration is avoidable. Hardware, software and contracts are already being replaced on cycles that are budgeted, and specifying post-quantum capability at that point costs close to nothing. The expensive version is the one that misses those cycles and replaces assets early.

Why post-quantum migration is hard to fund as a programme

Presented as a standalone capital request, post-quantum migration competes badly. The benefit is the avoidance of a threat with no agreed date, the regulatory driver is guidance rather than obligation for most UK organisations, and the completion deadline is a decade away. Against a business case for a revenue system, it loses.

Presented as a set of requirements attached to spend already committed, it competes very differently, because it is no longer asking for money. It is asking for a specification change on a purchase that is happening anyway.

This distinction determines most of the total cost. Two organisations with identical estates can differ by an order of magnitude in what migration costs them, depending on whether the requirements were attached to the refresh cycle or the refresh cycle was allowed to pass without them.

Which post-quantum solutions ride existing cycles

The pattern holds across every row. Specified in advance, the cost is a line in a requirements document. Missed, it becomes early replacement of an asset with remaining book life, which is both a capital cost and a business case that has to be made separately.

The refresh window arithmetic

The reason this matters now is that most asset classes have very few cycles left before the dates that count.

An organisation refreshing servers on a five year cycle has one, possibly two, refreshes between now and 2031, the NCSC's highest-priority migration milestone. If post-quantum capability is not specified in the next one, the assets purchased will still be in service at the deadline, and the choice becomes early replacement or missing the milestone.

For end-user devices the position is more comfortable, with two or three cycles available, which is why endpoint procurement is the easiest place to start.

For operational technology it is severe. An asset with a twenty-five year service life purchased today will be running in 2051. The current procurement cycle is not the best opportunity to specify post-quantum capability; it is the only one before 2035, as covered in quantum risk in embedded and operational technology.

The practical conclusion is that the deadline for specification is considerably earlier than the deadline for migration, and for long-lived assets it has effectively already arrived.

How to specify post-quantum solutions in procurement

Add cryptographic requirements to the standard specification template

The requirement set is short and stable: support for NIST-approved post-quantum algorithms with named parameter sets, a field-updatable root of trust rather than a fixed verification key, an update mechanism whose trust anchor can itself be replaced, provision of a cryptographic bill of materials for the product, and a dated post-quantum roadmap.

Adding this to the standard template once means it applies to every subsequent purchase without further intervention, which is the highest-leverage single action available.

Raise cryptographic terms at contract renewal

For SaaS and managed services, renewal is the point at which terms can change. Algorithm disclosure, a dated migration commitment, subprocessor disclosure and notice periods for cryptographic change are all reasonable asks at renewal and are close to unobtainable mid-term.

Attach agility requirements to planned application change

Any application already being modified can absorb crypto-agility requirements at low marginal cost: configurable algorithm selection, dynamic buffer sizing and externalised cryptographic parameters. Retrofitting the same properties as a separate exercise is substantially more expensive and rarely funded.

Use version currency rather than a migration project

A significant proportion of post-quantum capability arrives through routine upgrades. OpenSSL 3.5 carries ML-KEM, ML-DSA and SLH-DSA in the default provider and is supported to April 2030, and the default TLS group preference means upgrading the library enables hybrid key agreement without further configuration. Maintaining version currency is already funded in most organisations as a patching and support obligation.

What post-quantum solutions require direct funding

Four things do not ride any existing cycle, and they should be the funding request rather than the whole programme.

Discovery is first and unavoidable. It is the longest single activity in most programmes, requires specialist effort, and produces the inventory without which nothing else can be estimated. It is also the item with the clearest independent return, since the same inventory supports audit, incident response and outage prevention.

Target architecture and a parallel hierarchy come second. Post-quantum certificate authorities cannot generally be created by upgrading existing ones. Microsoft's ML-DSA support in Active Directory Certificate Services, for example, offers no in-place migration path, so a parallel hierarchy must be stood up alongside the existing one and endpoints moved across.

A test environment is third, and it is cheap relative to what it prevents. The failures encountered in post-quantum deployment are interoperability failures rather than cryptographic ones, and they are far less expensive to find before rollout.

Replacement of unmigratable assets is fourth and is the only genuinely large capital item. Devices with immutable roots of trust cannot be migrated at any price and require replacement, which needs identifying early enough to enter a capital plan rather than late enough to become an emergency.

How to phase the funding request

The sequencing that works is to ask for the small number first.

Fund discovery on its own, on the independent benefits, without requiring a decision about the wider programme. It is a bounded professional services cost with a defined output.

Use the discovery finding to size everything else. Until the inventory exists, any figure for the remainder of the programme is invented, and finance functions recognise that.

Then bring two requests. A modest direct budget covering architecture, the parallel hierarchy, test capability and programme effort. And a specification change costing nothing, applied to refresh and renewal cycles already in the plan.

That structure converts a large, uncertain capital request into a small, defensible one plus a procurement policy change, which is a materially easier proposition.

Common funding mistakes

The first is waiting for a business case before starting discovery. Discovery is what makes the business case possible, and it is small enough to fund on its own merits.

The second is allowing a refresh cycle to pass without cryptographic requirements. This is the single most expensive error available, because it converts a specification into a capital replacement.

The third is bundling everything into one large request. A single number covering discovery, architecture, migration, replacement and platform licensing is easy to defer in full, whereas a phased request is not.

The fourth is funding the platform and not the operating model. Automation tooling without ownership, standards and supplier engagement delivers a fraction of the benefit, and the shortfall usually appears eighteen months later.

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 deliver discovery as a bounded engagement through our PKI health check and cryptographic bill of materials services, producing the inventory that lets everything else be costed accurately rather than estimated. We then design the target architecture and parallel hierarchy through our PKI design and build practice, and support procurement teams in writing cryptographic requirements into standard specifications so that the majority of the migration is absorbed by spend already committed.

Because we are vendor-neutral, the sequencing we recommend follows the estate and the refresh calendar rather than a product roadmap. If you are preparing a funding submission, we are happy to review the assumptions behind it.

‍