Building the Funding Case for Post-Quantum Migration

In May 2022, National Security Memorandum 10 set 2035 as the date by which US federal agencies must mitigate quantum risk across their vulnerable systems, and the NSA’s CNSA 2.0 suite sets 2033 for national security systems. A finance director can do very little with a threat that might arrive sometime in the next decade. Two dates in published government policy are a different kind of object, and a funding request built on them is a different kind of request.

Most post-quantum funding requests fail in the same place. They open with the threat, spend three slides explaining quantum computing, and reach the ask with no date the organisation is actually bound by, no estimate of how long its own migration would take, and no deliverable anyone can inspect twelve months later. This article is about assembling those three things. Post-quantum cryptography (PQC) is the family of algorithms designed to withstand attack by a quantum computer, and the case for funding the move to it is an ordinary planning argument. It is strongest when it’s made that way.

Start from the date that binds you

Page one of the paper is a list of dates, each attached to an authority the organisation already answers to. Not a threat timeline. A compliance timeline.

• United States, federal. National Security Memorandum 10 (May 2022) set 2035 as the target for mitigating quantum risk across vulnerable federal systems. The Quantum Computing Cybersecurity Preparedness Act, signed in December 2022, requires agencies to inventory their cryptography and requires the Office of Management and Budget (OMB) to report the cost of migrating it.
• United States, national security systems. The NSA’s CNSA 2.0 suite sets 2033 as the completion date for national security systems, with earlier dates for software signing and networking equipment.
• European Union. The coordinated implementation roadmap published by the NIS Cooperation Group in June 2025 has member states beginning their transition by the end of 2026, covering high-risk use cases by the end of 2030, and finishing by 2035.
• United Kingdom. NCSC guidance published in March 2025 expects discovery and a costed migration plan by 2028, the highest-priority systems migrated by 2031, and completion by 2035.
• Financial sector. The G7 Cyber Expert Group issued a statement on quantum risk in September 2024 directing financial institutions to begin planning. The Bank for International Settlements runs Project Leap, its quantum-proofing programme for central banks and the wider financial system.

Then identify which of these actually binds your organisation, and by what mechanism. A US-listed manufacturer with a European subsidiary and a defence contract has three separate clocks running at different speeds, and the fastest one sets the plan. For many firms the fastest clock isn’t a regulator at all: it’s a customer contract with a cryptographic-agility clause, or a supplier assurance questionnaire that now asks for a PQC roadmap. Those dates are usually closer than 2030, and they’re the ones a commercial audience takes seriously.

One more point belongs on that page. The destination is fixed. NIST finalised the first three standards on 13 August 2024: FIPS 203 for ML-KEM (key encapsulation), FIPS 204 for ML-DSA and FIPS 205 for SLH-DSA (digital signatures). Nobody is being asked to fund a bet on which algorithm wins.

The shelf-life arithmetic

The threat section of the paper should be short, and it should be about data rather than about qubits. A cryptographically relevant quantum computer (CRQC) is one large and reliable enough to break RSA and elliptic-curve cryptography. Nobody knows the year it arrives. That uncertainty is precisely why the argument should not depend on it, and there’s a well-established way to sidestep it.

Harvest now, decrypt later (HNDL) describes an adversary capturing encrypted traffic or exfiltrating encrypted archives today, storing them, and decrypting them once a CRQC exists. Under HNDL, the exposure date for a given piece of data is not the day it’s stolen. It’s the day the encryption around it fails, which may be many years later.

Michele Mosca, of the University of Waterloo, turned this into a comparison a planner can act on. Three quantities:

• x, the number of years your data must stay confidential
• y, the number of years your migration will take
• z, the number of years until a CRQC exists

If x + y is greater than z, some of your data is already exposed. You control two of the three terms and you can estimate them from your own records, which is what makes the argument fundable.

Work it through for a mid-sized payments firm. Transaction records and customer identity data carry a seven-year confidentiality requirement, so x is 7. The firm runs about 900 applications, a private certificate authority, and four hardware security modules, and an honest internal estimate of full migration is five years, so y is 5. Take a conservative z of 2040. Then x plus y is 12, and the latest safe start is 2028. Take a less comfortable z of 2035, and the latest safe start was 2023.

The paper should present both numbers. The point of showing the range is that the start date moves year for year with the CRQC estimate, while y, the migration duration, is the only term the organisation can shrink. Shrinking it is what the budget buys. And a five-year y is not pessimism: it’s discovery, remediation of what discovery finds, vendor dependency, testing, and a certificate estate that has to be re-issued without breaking production.

If the executive team disputes z, that’s fine. Ask them to name the year they’d accept, and run the arithmetic in the room. The conversation ends in a start date either way.

Cost the first phase, not the program

Asking for a ten-year number is how a request gets deferred. OMB put the cost of migrating federal civilian systems between 2025 and 2035 at roughly 7.1 billion USD, which is a useful comparator for scale and a terrible template for an internal ask. Cost the first phase, and make the second phase conditional on what the first one finds.

Phase one is discovery, and it produces things a finance function can inspect:

1. A cryptographic bill of materials (CBOM), which is an inventory of every algorithm, key, certificate and protocol version in use, with the system it belongs to and the person who owns it. Where “inventory” appears later in the paper, it means this artefact.
2. A ranked list of systems, ordered by data shelf life and by how hard they are to change, so that remediation sequencing is an output of the phase rather than a guess made before it.
3. A defensible value for y, replacing the estimate used in the shelf-life arithmetic with one built from a real count of applications, certificates and dependencies.
4. A supplier position, meaning a written answer from each significant vendor on when their products will support the NIST standards.
5. A costed plan for phase two, with a decision gate the executive committee owns.

Name the headcount, the tooling category and the duration. Twelve months is a reasonable phase-one length for a large estate, and it’s short enough to sit inside a normal planning cycle. Then state plainly what the organisation cannot do until discovery finishes: it cannot size the migration, cannot answer a customer questionnaire with evidence, and cannot tell a regulator which systems fall under a 2030 obligation.

The benefits the CFO can inspect at twelve months

A funding case that only pays off in 2035 competes badly against every other line on the security budget. Discovery pays off immediately, and this section of the paper is where a sceptical reader is most likely to change position.

Assets nobody was managing. A cryptographic inventory reaches parts of the estate that asset management usually misses, because it follows certificates and key material rather than procurement records. Expect to find running systems that no current owner has claimed.

Crypto debt. This is the accumulated set of weak or expired cryptography already in production: SHA-1 signatures, TLS 1.0 and 1.1 endpoints, 1024-bit RSA keys, self-signed certificates in front of internal services, keys hard-coded into application source. Every one of these is a present-day finding, not a quantum one, and several are already audit exceptions. Discovery surfaces them as a by-product, and remediating them improves this year’s risk posture.

Crypto-agility. Agility means the ability to change an algorithm without re-engineering the system around it: cryptography reached through a service or library rather than compiled into application logic, certificate issuance automated rather than manual, key rotation tested rather than theoretical. An organisation that builds this for PQC gets it for the next cryptographic change too, whatever prompts that one.

Supplier answers on the record. Asking suppliers for their PQC timelines produces a documented position from each of them, which then feeds contract renewals. The Financial Services Information Sharing and Analysis Center (FS-ISAC) has published guidance for financial firms on the questions to put to suppliers, and the same questions work outside financial services.

Less data to protect. Deciding which data must stay confidential for a decade forces a retention review. Data deleted this year is data that needs no re-encryption, no storage, and no breach notification.

The three objections, answered inside the paper

Write the answers into the document. An objection handled in the room sounds defensive; an objection handled on page four sounds like the work was done.

“The timeline is speculative”

Agree with it, then show that the plan doesn’t depend on it. The regulatory dates are fixed regardless of when a CRQC appears. The algorithms are standardised. The shelf-life arithmetic yields a start date across the whole plausible range of CRQC estimates, and the paper shows the range rather than picking a year.

“Our vendors will handle it”

Partly true, and the distinction is what the organisation still owns. Vendors will update their own products on their own schedules, and you will discover those schedules only by asking. Nobody else owns your internal certificate authority, your custom applications, your embedded and operational technology, your key management processes, or the contract clauses that make a supplier’s schedule binding. A vendor-dependency map is a phase-one deliverable, and it converts this objection into a list.

“Insurance will cover it”

Treat this as a question rather than an assumption. At the next renewal, ask the underwriter in writing whether a loss arising from cryptography that was deprecated at the time of the incident is covered, and keep the answer. Insurers price what they can assess, and questionnaires generally follow published regulatory expectations within a cycle or two. An organisation with an inventory and a dated plan is in a better position at renewal than one without, whichever way the policy language moves.

What the paper looks like

Six elements, in this order, on no more than four pages:

1. The binding dates, with the authority and the mechanism for each.
2. The shelf-life arithmetic for your two or three longest-lived data classes, with the resulting start date at two CRQC estimates.
3. The scope of what has to change, in counts: applications, certificates, HSMs, external interfaces, suppliers.
4. Phase one only, costed, with its five deliverables and a duration.
5. The near-term findings the phase will produce, and how they will be reported.
6. The decision the executive committee is being asked to take at the twelve-month gate.

The threat explanation belongs in an annex. Anyone who wants it will read it, and putting it up front reliably converts a planning discussion into a physics discussion.

The capability you’re actually funding

The line item says migration. What the organisation gets, if the phase-one deliverables are real, is the ability to answer three questions on demand: what cryptography do we run, what would it cost us to change it, and how long would that take. Very few organisations can answer any of the three today, and each of them is now being asked by regulators, customers and auditors independently of quantum computing.

People run that capability, and tools only report what they find. Someone has to read a certificate chain, interpret a cipher suite, judge whether a supplier’s roadmap is a commitment or a hope, and translate all of it into the numbers on page one. Budgeting for the migration without budgeting for the skills to run it produces an inventory nobody can act on.

Quantum Academy’s training is built for that gap: cryptographic discovery, migration sequencing, supplier assessment, and the executive communication this article is about. Start at quantumacademy.com/. For migration methodology in depth, the PQC Framework covers the phase structure referenced here, and PostQuantum.com carries the technical background for the annex.