How use PQC Migration Budget Builder

Most organizations have to put a post-quantum cryptography (PQC) budget into a planning cycle before they have a cryptographic inventory to price it from. The PQC Migration Budget Builder is a free tool for that situation. This walkthrough explains what it does, what to prepare, what each of its five steps asks for, how to read the results, where every number comes from, and what it will get wrong. It ends with four exercises you can run in under an hour.

What does the PQC Migration Budget Builder do?

It turns three kinds of input into a budget request you can defend before discovery. The inputs are the regulatory and contractual obligations that apply to your organization, a rough picture of your cryptographic estate, and the share of the work that planned refresh budgets already pay for. The outputs are:

• an itemized year-one ask, built from the line items that can be priced before discovery;
• a three-scenario estimate (optimistic, expected, conservative) for the years after discovery;
• gross program cost and net incremental cost side by side;
• annual cash flow with a capital and operating split, and a net present value if you want one;
• the cost of starting one, two or three years later against the same deadline;
• five cross-checks against published benchmarks;
• a draft board paper in the order a funding committee expects: executive summary, detailed budget, risks, governance.

Everything runs in your browser. Nothing you enter is sent to a server or stored. You can save your inputs as a small JSON file and load them again later, copy the paper as text, print it, and export the tables as CSV.

Where does the tool come from?

Marin Ivezic, the founder of Quantum Academy, built the tool and first published it on PostQuantum.com, together with a first-person guide to its method. Quantum Academy publishes the tool and this walkthrough with permission from Marin Ivezic and PostQuantum.com. The calculation is identical in both editions. The Quantum Academy edition names the Applied Quantum PQC Migration Framework v3.0 and Applied Quantum’s 2026 PQC migration cost benchmarks as its sources, and leaves out the blog’s first-person commentary.

Every constant in the tool carries one of four source labels:

• A: Applied Quantum’s 2026 PQC migration cost benchmarks, for the year-one line items, the testing ratio, the vendor and program-management lines and the cross-check bands.
• F: Phase 0 of the framework, Executive Mandate and Business Case, for the size profiles, the buffer before a deadline, the refresh-alignment logic and the five board indicators.
• T: the Global PQC Migration Timeline maintained on PostQuantum.com, for the deadlines.
• C: calculator assumptions. Each one states what it was calibrated against, and each one can be changed in the assumptions register at the bottom of the results page.

Why does it estimate a budget rather than a return on investment?

Because a return-on-investment figure for PQC depends on two numbers nobody can defend. The first is the probability that a cryptographically relevant quantum computer (CRQC), a machine able to break RSA and elliptic-curve cryptography at useful scale, exists in a given year. The second is the loss it would cause your organization. Multiply a guess by a guess and you get a precise-looking number that a finance director will take apart in one question. The framework states “no loss estimation” as a design principle for the business case, and the tool follows it.

What replaces the loss model is a set of dates. Regulators, supervisors, card schemes and procurement rules have published deadlines for PQC migration. A board can fund an obligation with a date on it. The tool therefore starts with obligations, derives the schedule from them, and builds the cost around that schedule.

What should you prepare before you start?

Rough figures are enough for a first pass. Have these to hand:

1. The jurisdictions, sectors and schemes that apply to you: for example, whether you process card payments, operate in the EU, sell to the US federal government, or are supervised by a financial regulator.
2. A rough count of applications that will need migration work, split into four complexity tiers (defined at Step 3).
3. The number of hardware security modules (HSMs) and cryptographic modules you run, and the number of TLS, VPN and SSH endpoints.
4. Your annual IT budget and the number of people you serve (customers, citizens or members). Both are used for cross-checks only.
5. Whether you have a usable asset inventory, whether you already license cryptographic discovery tooling, and how deep your in-house cryptographic skills are.
6. Your refresh calendar for PKI, HSMs and network equipment, if you know it.

If you have none of the counts, the tool fills in typical counts for your size profile at the press of a button, and you edit from there.

How do the five steps work?

Step 1. Organization

The size profile is the most consequential choice on this step. The four profiles come from the framework’s right-sizing guidance: small (under 2,000 employees), mid-size (2,000 to 20,000), large (20,000 to 100,000) and hyperscale or multi-entity (over 100,000). The profile scales the lump-sum lines, such as governance, the discovery team and PKI modernization, by a factor of 0.12, 0.30, 1.0 or 2.0. The mid-size and large factors are anchored to the benchmarks; the small and hyperscale factors are extrapolated.

The sector selector suggests which obligations to look at on the next step and sets the per-person multiplier used in one cross-check (1.5 for financial services and payments, 1.0 for everyone else). The IT budget and the people-served figure feed the cross-checks and nothing else. The program start year is usually your next fiscal year. The currency selector changes the symbol only; every unit cost is a US-dollar figure for a large enterprise.

Step 2. Obligations

This step sets the schedule, so it comes before the estate. The tool lists 33 regimes in five regional groups, curated from the 162 entries in the timeline as of October 2026. Each regime shows its instruments, its binding level and its dated milestones. Open a region and tick what applies. Three dates follow:

• Priority-wave target. The earliest “priority systems migrated” milestone among the regimes you ticked, less a buffer. The buffer defaults to 12 months, the minimum the framework sets in its model risk appetite statement. Under the EU coordinated implementation roadmap, high-risk use cases are due by the end of 2030, so the target becomes 2029.
• Full-migration target. The earliest “full migration” milestone, less the same buffer. For the EU roadmap, end-2035 less the buffer gives 2034.
• First upcoming obligation. Whichever plan, inventory or procurement milestone falls first once your program has started. Milestones already in the past are listed separately, to be reported in the year-one plan as done or in progress.

The binding level is shown because it varies. The US federal civilian schedule under OMB Memorandum M-26-15 and Executive Order 14412 binds agencies. The EU roadmap is a coordinated plan without legal force of its own, which several Member States have adopted in national documents. The PCI DSS v4.0.1 requirement for an annual cryptographic inventory binds anyone in card-payment scope. The United Kingdom’s NCSC timelines are guidance. Supervisory communications to banks in Saudi Arabia, Israel, Singapore and Hong Kong are not laws, and supervised banks treat them as obligations anyway.

You decide what counts for you; the tool uses whatever you tick.

Two checkboxes record exposure. The first is data that must stay confidential for more than ten years, which is the harvest-now, decrypt-later case: an adversary records encrypted traffic today and decrypts it once a CRQC exists. The second is long-lived signatures and trust anchors, such as PKI roots, code-signing keys and firmware keys, which a future CRQC could forge. Both change the paper’s exposure paragraph and the cost-of-delay text. Neither changes a cost line.

Step 3. Estate

Enter the counts you have. At the first stage gate, at the end of discovery, use the panel described below to replace those estimates with inventory counts for the part of the estate covered by discovery.

Applications are counted in four complexity tiers. Tier A is a modern application with its cryptography behind a library, at $50,000 to $100,000 per application. Tier B is a standard enterprise application with configurable cryptography, at $100,000 to $200,000. Tier C is a complex integration with custom protocols, at $200,000 to $400,000. Tier D is a legacy system with embedded cryptographic logic, or one locked to a vendor, at $400,000 to $750,000. Count only applications that need migration work.

The tool adds testing and validation at 25 to 40 percent of application migration, and it shows a reminder that the algorithm change itself is 10 to 20 percent of the total; the remainder is integration, testing, vendor and operational work.

Cryptographic infrastructure takes two counts. HSMs and cryptographic modules to upgrade or revalidate cost $50,000 to $200,000 per module, and FIPS 140-3 validation takes 12 to 24 months. TLS, VPN and SSH endpoints cost $300 to $1,500 each for configuration, certificates and firmware. HSM hardware replacement and the capacity uplift that larger keys and handshakes need are optional fields for your own figures; the tool has no defensible unit price for either, so it leaves them at zero unless you enter one.

Three questions about your starting position change the year-one lines. Without a usable asset inventory the tool budgets $500,000 to $2 million (large enterprise, scaled by profile) to build one before discovery. A partial inventory halves that line. A mature configuration management database removes it. Licensed discovery tooling removes the licence line. In-house skills scale the external advisory line: 1× for a team with PQC-trained engineers, 1.5× for security engineers without PQC depth, 2× when everything is external at first.

Operational technology and embedded devices get a scope selector and a separate figure. The benchmarks treat OT as its own workstream with its own estimate, never as a percentage of the IT migration. If you have no OT figure yet, the totals exclude OT and the paper says so.

The panel at the bottom of Step 3 is for the end of discovery. For applications, HSMs and endpoints, set the status to “Inventoried, coverage measured” and enter two things: the inventory’s counts and its coverage. Coverage is the share of the estate the inventory has read, measured against the estate enumerated before discovery ran (configuration records, service map, application portfolio) and not against what the tools found. The inventory’s count describes only the part of the estate discovery has read.

For the inventoried portion, costs are calculated from the inventory counts. For the portion not yet inventoried, you will see a separate cost line, calculated from whichever is higher: the pre-discovery estimate or the inventory count extrapolated to that portion. You can change this rule in the assumptions register. If you cannot observe an asset class with your discovery method, select “Not observable by discovery”. Its coverage is then recorded as unknown, with costs calculated from the estimate.

In the worked example below, suppose discovery has read 65 percent of the applications and found 38 (22, 11, 4 and 1 across tiers A to D). Entered as if they were the whole estate, they would cut the expected program from $16.6 million to $13.1 million. Entered with their coverage, the program comes to $17.3 million, with about 21 applications not yet inventoried on their own line. Any class below 70 percent coverage triggers a note, because gate G1 → G2 in the framework requires at least 70 percent of Tier-1 systems inventoried, with a signed accepted-gaps register for the scope discovery has not reached.

Step 4. Refresh alignment and schedule

Gross program cost is everything the program spends. Net incremental cost is gross minus the spending that existing refresh and modernization budgets would have made anyway. The framework asks for both numbers side by side and describes the gap between them as the strongest single number in the budget conversation. Step 4 sets that gap, line by line, as the share already in planned budgets:

• PKI modernization, 50 percent, because certificate lifecycle automation is required anyway for the 47-day certificate lifetimes the CA/Browser Forum has scheduled through March 2029.
• HSM upgrades and replacement, 40 percent, because FIPS 140-3 upgrades are required by the FIPS 140-2 sunset and end-of-life HSMs are replaced on their own schedule.
• Network and endpoint work, 30 percent, because data-center, SD-WAN and cloud refreshes replace the same equipment on their own cycle.
• Application migration, 10 percent, because teams upgrade libraries and platforms for known vulnerabilities anyway.
• Capacity uplift, 20 percent, because planned compute and network refresh often pays for it.

These are starting points. Set each slider to what your own refresh plans say.

The schedule has three inputs. The number of years the program needs at a sustainable pace defaults by profile (three for small, four for mid-size, six for large, eight for hyperscale), inside the benchmark range of five to seven years for a large enterprise and the framework’s four to fifteen years of execution. The priority wave, meaning the systems regulators want migrated first, defaults to 30 percent of implementation.

The rush premium defaults to 15 percent of implementation cost for each year the schedule is compressed below the duration needed, applied to the compressed wave only. The rate is a calculator assumption; the mechanism, parallel workstreams, premium external rates and expedited hardware, is the benchmarks’ and the framework’s. A discount rate (default 8 percent) is used only for the NPV.

Step 5. Results and the paper

The results page shows, in order: headline figures; warnings and notes; the scenario range against the reference scenarios; cash flow by year with the CapEx and OpEx split and the NPV; the year-one ask line by line; the post-discovery estimate by category; gross and net per line; the cost of starting later; the cross-checks; and the board paper. The assumptions register at the bottom lists every unit cost with its source letter and lets you change it. Edit a unit cost and the whole page recomputes.

The paper has four parts. The executive summary names the regulatory driver, the approach, the year-one ask and the total range. The detailed budget gives annual cash flows, contingency as a separate line, year one itemized and later years by category. The risk section covers the cost of delay, the exposure paragraph, six common cost traps and nine benefit categories beyond compliance. The governance section names the accountable executive, the steering committee, the stage gates and the framework’s five board indicators: Coverage, Trust, Inventory, Vendors and Agility. Copy it into your own template or print it.

What does a worked example look like?

Take a mid-size payments company with 500,000 customers and an annual IT budget of $35 million, operating in the EU and in card-payment scope. Choose the mid-size profile and the payments sector, enter the budget and the customer count, set the start year to 2027, and tick two regimes: PCI DSS v4.0.1 and the EU coordinated implementation roadmap. Leave both exposure boxes ticked, since a payments company keeps long-lived transaction records and signs its own software.

On the estate step, press the typical-counts button for a mid-size organization, which enters 30, 15, 6 and 2 applications across the four tiers, 6 HSMs and 700 endpoints. Keep a partial inventory, unlicensed tooling, security engineers without PQC depth, and no OT in scope. Leave the refresh sliders and the schedule at their defaults.

The schedule comes out first. The EU roadmap’s end-2030 milestone less the 12-month buffer puts the priority-wave target at 2029. A four-year program starting in 2027 reaches the end of its priority wave in 2029, so nothing is compressed and no premium applies. The full-migration target is 2034, four years of slack. Both of the regimes’ plan milestones (PCI DSS from March 2025, the EU roadmap’s end-2026 national-strategy milestone) are already in the past and are listed for reporting.

Output	Figure
Year-one ask	$1.0M to $2.6M, expected $1.8M
Post-discovery estimate, years 2 to 4	$8.4M to $21.3M
Program total	$9.4M optimistic, $16.6M expected, $23.9M conservative
Contingency held at program level	$7.2M
Already in planned refresh	$1.65M
Net incremental cost, expected	$15.0M
Cash flow	2027 $1.6M, 2028 $5.3M, 2029 $6.9M, 2030 $2.9M
NPV at 8%	$13.6M
Start one year later	expected $17.2M, priority wave compressed by one year
Start two years later	priority wave flagged as infeasible without descoping

The application line is $5.0 million to $9.9 million of the post-discovery estimate, and testing adds $1.25 million to $3.96 million on top of it. Infrastructure, PKI, HSMs and endpoints together, is $1.0 million to $3.5 million. The two-year delay row is the one to show a board: with a 2029 target, a 2029 start leaves one year for a wave that needs three, and the tool stops pricing it and says so.

How do you read the cross-checks?

The cross-checks are the finance partner’s questions, asked before the finance partner asks them. In the example they read as follows.

• Share of IT budget. The expected total is 11.9 percent of the IT budget over the four program years. Comparable transitions, such as ERP, cloud and zero trust, have taken 8 to 15 percent, so the figure is inside the band.
• Cost per person served. $33 per customer, against a comparator of $31.50: the US federal estimate of about $21 per person served, derived from the $7.1 billion the Office of Management and Budget reported for 2025 to 2035, times the 1.5 multiplier for payments. Close to the comparator.
• Year-one ask against the benchmark. The expected year one of $1.8 million sits inside the benchmark band scaled to a mid-size profile, $1.05 million to $2.25 million.
• Redo multiplier. The conservative scenario is 1.43 times the expected one. The benchmark expects post-discovery estimates to grow by 1.5 to 2 times over a program’s life, so the tool flags the conservative column as narrow. Widening the tier D count or raising the high end of the application unit costs would close the gap.
• CapEx share. 47 percent, below the 60 to 70 percent rule of thumb for active migration, because at these counts the program is weighted toward people rather than equipment. Your accounting policy decides what you capitalize.

Do not treat an estimate within every band as proof of accuracy. If you fall outside a band, be ready to explain why before submitting the proposal.

Where do the numbers come from?

From the benchmarks (A): the fifteen year-one line items, from a $20,000 to $50,000 board briefing to a $1.5 million to $3 million discovery team. Also from the benchmarks: application unit costs of $50,000 for a modern application and $500,000 and up for a legacy one, which set the ends of the four-tier scale; HSM validation at $50,000 to $200,000 per module; testing at 25 to 40 percent of application migration; the vendor, program-management and training lines; the 1.5 to 2× redo multiplier; the 8 to 15 percent and $21-per-person cross-checks; the 60 to 70 percent CapEx rule; and the reference scenarios of $16.3 million, $35.5 million and $69.5 million for a large enterprise.

From the framework (F): the four size profiles; the 12-month minimum buffer; the gross-versus-net presentation and the refresh shares as starting points; the duration range of four to fifteen years; the five board indicators; the no-loss-estimation principle.

Calculator assumptions (C): the size factors of 0.12, 0.30, 1.0 and 2.0; the tier B and tier C unit costs, interpolated between the benchmark’s two ends; the endpoint cost of $300 to $1,500 and the PKI lump sum of $1.5 million to $4 million for a large enterprise, both calibrated so that a reference estate reproduces the benchmark’s infrastructure line; the hybrid-operations overhead of 12 to 17 percent, derived from the benchmark’s table; the 30 percent priority share; the 15 percent rush premium; and the CapEx share by category.

Scenarios are sums: optimistic adds the low ends, expected the midpoints, conservative the high ends. Contingency is conservative minus expected, presented as a managed line. The full register, including the cash-flow profiles by category, ships with the plugin as MODEL.md.

What will the tool get wrong?

• Unit costs are 2026 US-dollar figures for a large enterprise. The tool does not adjust for regional labor rates. Scale the people-heavy unit costs in the register if you know your rates.
• Only the mid-size and large profiles are anchored to benchmark figures; the small and hyperscale factors extend the curve beyond them.
• The cash-flow profiles are fixed shapes. Infrastructure falls in years two to four, applications rise and then fall, program management is flat. Your sequencing will differ.
• Three lines are never estimated for you: HSM hardware replacement, capacity uplift, and the OT workstream. Each is zero until you enter a figure.
• The deadline data is a snapshot from October 2026, and some entries are guidance with no legal force. The version number in the footer shows which data you are using.
• The cost of delay prices compression and lost refresh alignment only. It does not price enforcement action, lost contracts or breach losses.
• The board paper is a draft generated from your inputs. It states your assumptions as facts. Check every sentence before anyone else reads it.

How much should you rely on the output?

The output is a planning aid. It is not a quotation, an audit, or legal, financial or regulatory advice. The tool knows nothing about your contracts, your supervisors or your accounting policy. Check every obligation you rely on against the instrument itself and with your counsel before it appears in a paper under your name. The figures are ranges built from published benchmarks and from labelled assumptions, and they carry no warranty.

Nothing you enter leaves your browser; there is no account, no analytics on the inputs, and no server-side copy of your paper. The tool is published under a Creative Commons Attribution 4.0 licence, so you may adapt it for your organization or your clients, with attribution. If you find an error in a figure, a source or a deadline, tell us, and the correction goes into the next version with the change noted.

How do you present the result to a CFO or a board?

Lead with the obligation: the regime, the date and the buffer. Then the year-one ask, itemized, because it is the only number you can defend line by line before discovery. Then the range, with contingency shown as a managed line. Put gross and net on the same page, because the net figure is the one that goes into the incremental budget request.

Fix the stage gates in the paper. At the first gate, load your saved inputs, enter the inventory’s counts and coverage in the stage-gate panel, and show the delta, with the share discovery has not yet read on its own lines. Report any growth in the enumerated estate as a scope change, with its cause. A range that widens with a stated reason is a normal program event. A total that quietly grows is a credibility problem.

Exercises

Each exercise starts from the worked example above. Save the inputs as JSON after you build it, so you can return to the baseline.

1. Move the start year from 2027 to 2028. The priority wave now has two years for work that needs three. Expected cost rises from $16.6 million to $17.2 million, a warning appears, and the paper’s cost-of-delay section gains a year of harvestable traffic. Then try 2029 and read what the delay table says.
2. Set every refresh slider to zero. Net incremental cost rises from $15.0 million to $16.6 million, equal to gross. Now set the sliders to your own refresh calendar and note the gap. That gap is the number the framework tells you to lead with.
3. Change the asset inventory from partial to none. Year one rises by $75,000 to $300,000 at the mid-size profile, the inventory foundation line. Change it to mature and watch the line disappear.
4. Open the assumptions register and raise the tier D high end from $750,000 to $1 million. Watch the conservative scenario, the redo multiplier and the contingency line. Then ask which of your own legacy systems that change describes.

What to take away

Use the tool to prepare a budget request before discovery: an itemized year-one request, a range you can justify, a net figure a CFO can compare with planned spending, and a deadline based on a regulatory obligation rather than a quantum prediction. Treat this as a basis for planning, not a forecast of your migration cost. After discovery, update the counts for the part of the estate you have inventoried, keeping the same budget structure.