PQC Migration Cost Benchmarks for Enterprise: What to Budget

The first thing to say about PQC migration cost benchmarks is that good ones are scarce. Most published figures are analyst projections based on programme scoping exercises, not averages from completed migrations. As of mid-2026, very few large enterprises have completed a full post-quantum cryptography migration. Most are in cryptographic inventory phases or early migration. The data that exists reflects what programmes are expected to cost, not what they have cost once all the surprises have been absorbed.

That limitation is worth stating at the outset, because the CFO or programme manager reading this needs to build a budget that a board can defend. A budget built on projections presented as actuals will be challenged as soon as anyone does a basic source check. The more credible approach is to present analyst range estimates as analyst range estimates, build in explicit contingency for the factors that routinely expand timelines and budgets, and structure the programme in phases so that each phase is funded from a completed inventory rather than an upfront whole-programme estimate.

This article sets out the cost component breakdown, segment-based ranges from available analyst data, the HSM replacement variable that drives most of the budget variance at enterprise scale, and a phased budget structure that is defensible to a CFO and traceable to regulatory obligations. Before estimating migration costs, organisations should first understand their cryptographic exposure. The Quantum Threat Exposure Assessment and the Q-Day Timeline Calculator provide the risk baseline that makes the budget conversation credible rather than speculative.

Why Cost Benchmarks Are Hard to Find

The absence of reliable cost data is not a research gap. It reflects the current state of the migration market. Most large enterprises have not completed PQC migration. The programmes underway are in early phases. The cost data being discussed in analyst reports and vendor briefings is based on programme scoping, not completed programme actuals.

This creates a systematic underestimation problem. Programme scoping estimates are built on assumptions about what the cryptographic estate contains. Those assumptions are frequently wrong in one direction: the actual number of systems, certificate types, legacy algorithm dependencies, and hardware replacement requirements is consistently larger than the pre-inventory estimate. Gartner's 2024 PQC maturity research suggests enterprises underestimate migration timelines by a factor of two to three as a common pattern. Budget estimates derived from timeline estimates inherit the same underestimation.

The practical consequence: initial cost estimates for PQC migration programmes should be treated as lower bounds rather than central estimates. Contingency should be modelled at 30 to 50% of the base estimate for programmes that have not yet completed a cryptographic inventory. Once the inventory is complete, the confidence interval narrows substantially.

Cost by Organisation Segment

Tier-1 Financial Services: Wide Range, High Floor

Large banks, insurers, exchanges, and clearing houses face the highest PQC migration costs at enterprise scale. Three structural factors drive this.

Cryptographic estate scale. A tier-1 bank may hold hundreds of thousands of TLS certificates across trading systems, customer portals, payment infrastructure, and internal services. The key hierarchy supporting those certificates typically spans multiple HSM fleets, certificate authority tiers, and key management systems. An inventory at that scale takes 12 to 18 months before migration can begin.

Regulatory complexity. Tier-1 financial institutions operate under the most stringent regulatory requirements of any enterprise sector. DORA Articles 6, 9, 24-27, and 28 apply to EU and EEA financial entities: Article 6 covers the ICT risk management framework, Article 9 covers protection and prevention measures (including cryptographic controls), Articles 24-27 govern advanced digital resilience testing (TLPT), and Article 28 covers third-party ICT risk management. For UK institutions, FCA operational resilience policy (PS21/3) and NCSC guidance apply instead of DORA. NIS2 Article 21(2)(h), where applicable, requires cryptographic measures. NIS2 Article 21(2)(d) covers supply chain security, which encompasses cryptographic library and HSM vendor dependencies. The regulatory change management cycle for cryptographic systems in payment infrastructure and securities clearing can extend 12 to 24 months beyond the technical migration itself.

Change management overhead. Regulatory approval for algorithm changes in payment systems, insurance ledgers, and securities clearing imposes calendar time that does not compress under commercial pressure. A migration that takes 6 months of engineering may require an additional 12 months of regulatory review before deployment.

Analyst estimates for tier-1 financial services PQC migration range from $5M to $50M over 18 to 36 months. The width of that range reflects the HSM replacement question: a tier-1 bank with a modern HSM estate on a vendor PQC roadmap will spend significantly less than one facing full physical HSM replacement. The floor of the range assumes favourable HSM and vendor conditions. The ceiling assumes full hardware replacement across a large estate with regulatory change management overhead.

Mid-Market Enterprises: Narrower Range, Achievable Timeline

Mid-market enterprises with 250 to 2,000 employees and annual revenue of $50M to $1B typically have a smaller cryptographic estate but face similar component costs at reduced scale. The cost dynamics are more predictable than for tier-1 firms.

Fewer HSMs, or cloud-managed key management systems where the vendor handles the PQC upgrade path, reduce the capital expenditure risk. A smaller TLS certificate estate reduces discovery time and migration scope. Shorter regulatory change management cycles allow engineering to drive the programme timeline rather than approval cycles. Greater reliance on third-party libraries, including OpenSSL 3.x, BoringSSL, and Bouncy Castle, means upstream vendor updates carry a larger fraction of the migration cost.

Indicative range for mid-market enterprises: $500K to $5M over 12 to 24 months. This is achievable for organisations with a complete cryptographic inventory, a defined migration sequencing plan, and no legacy embedded devices requiring physical replacement. Organisations without a completed inventory should treat $500K as the floor of phase 1 discovery costs rather than the floor of total programme cost.

SMBs: Largely Vendor-Covered, With Residual Internal Cost

For small and medium-sized businesses that rely on cloud infrastructure (AWS, GCP, Azure) and cloud SaaS, the majority of PQC migration cost is absorbed by the cloud providers. AWS KMS, Azure Key Vault, and GCP Cloud KMS have all published PQC migration roadmaps. TLS certificate migration for cloud-hosted services will largely be handled at the CDN and cloud provider layer.

SMB residual cost covers: staff training on PQC concepts and new library usage; any on-premise systems with legacy cryptography that the cloud provider does not manage; and a basic cryptographic inventory to confirm that the assumption of broad cloud coverage is actually correct. Estimated range for most SMBs without significant on-premise infrastructure: $10K to $100K. Organisations with on-premise server estates or legacy applications running outside the cloud provider envelope should verify coverage before assuming the lower end of this range applies.

Cost Components Breakdown

Five cost components account for the total programme cost across all segments. Their proportional contributions are estimates based on enterprise programme structures, not audited figures.

Discovery and inventory: 5 to 15%. The inventory phase is the prerequisite for everything else. Before migration can be sequenced, the organisation must enumerate every system, library, protocol, and key material type that uses Category 2 algorithms under NIST IR 8547 IPD: RSA, ECDH, ECDSA, DSA. A CBOM (Cryptography Bill of Materials) is the output format that tracks this inventory through the migration programme.

Two regulatory frameworks support CBOM-adjacent practices. The NTIA Minimum Elements for a Software Bill of Materials (SBOM), published by NTIA in July 2021, establishes the minimum data requirements for software transparency; an SBOM that tracks cryptographic library dependencies provides a foundation for cryptographic inventory. The EU Cyber Resilience Act requires manufacturers to document the software components included in their products, per Annex I Part II point (1); organisations with CRA-in-scope products will have SBOM obligations that directly support cryptographic discovery. Organisations with mature SBOM programmes will spend less on discovery because the enumeration work is partially done. For detailed guidance on building the inventory foundation, see CBOM Foundation and PQC Readiness.

Library migration: 40 to 60%. The largest single cost component across all segments. Replacing or updating cryptographic libraries across application, middleware, and platform layers includes: updating TLS libraries (OpenSSL 3.x, BoringSSL) to versions with ML-KEM and ML-DSA support; updating application-layer cryptography (Java JCA/JCE providers, Python cryptography library, .NET CNG); updating code signing pipelines; updating VPN gateway firmware. Engineering cost is proportional to the number of distinct codebases and the percentage that use direct algorithm calls rather than standard library abstractions. Custom cryptographic implementations are the highest-cost migration targets because they cannot be addressed by a library version update.

HSM replacement: 15 to 30%. Hardware Security Modules without a vendor-confirmed path to FIPS 140-3 validated ML-KEM or ML-DSA support require physical replacement. This is capital expenditure: new hardware, provisioning, key migration, and validation. FIPS 140-3, the current NIST standard for cryptographic module security, is the baseline for regulated sector deployments. The NIST Cryptographic Module Validation Programme (CMVP) at csrc.nist.gov is the authoritative source for current validation status. Organisations should verify module validation status directly against the CMVP rather than relying on vendor roadmap claims.

Indicative enterprise HSM unit cost range: $20K to $100K per unit for enterprise-grade devices from major vendors. A tier-1 financial institution with 50 to 200 HSM units faces capital expenditure of $1M to $20M for hardware alone, before provisioning and migration labour. These are indicative ranges based on publicly available enterprise HSM pricing; actual prices are negotiated and volume-dependent.

Staff training: 5 to 10%. Cryptographic engineers, security architects, and infrastructure teams require training on post-quantum algorithm properties: ML-KEM key encapsulation mechanics (FIPS 203), ML-DSA signature properties (FIPS 204), SLH-DSA stateless hash-based signature characteristics (FIPS 205), and hybrid mode configuration for TLS and IKEv2. Training cost is a small fraction of total programme cost but is frequently omitted from initial budget estimates, producing a gap when implementation begins and engineers need capabilities they have not yet developed. The FIPS 203/204/205 Implementation Decision Map is a useful reference for teams scoping the algorithm selection component.

Audit and assurance: 5 to 15%. Post-migration verification covers: cryptographic audit to confirm Category 2 algorithms have been removed from production; penetration testing of hybrid mode configurations; CBOM update to reflect the migrated estate; and regulatory compliance documentation. Regulated organisations in financial services, healthcare, and critical infrastructure will spend at the higher end of this range due to external audit requirements. This is the component that converts "we migrated" into "we can demonstrate compliance" and it should be budgeted from the outset, not discovered as an additional cost after migration is nominally complete.

The HSM Replacement Variable

HSM replacement is the cost variable that most frequently causes enterprise budget estimates to be revised upwards materially. The question is straightforward: does the organisation's current HSM fleet have a vendor-confirmed roadmap to FIPS 140-3 validated ML-KEM and ML-DSA support?

If yes: the migration cost for the HSM layer is primarily engineering labour for configuration and validation, not capital expenditure. If no: physical hardware replacement is required, and it is capital expenditure that sits outside most security team budgets and requires procurement and finance committee approval.

Major HSM vendors, including Thales, Utimaco, and Entrust, have published PQC roadmaps. Availability of FIPS 140-3 validated PQC firmware varies by product line and firmware version as of mid-2026. Older HSM models that are not on the vendor's firmware update roadmap require physical replacement. Organisations should verify current product-level support against the CMVP validation list and against direct vendor confirmation before building the HSM line into the programme budget.

One HSM-specific cost that is frequently missed: key migration. Migrating key material from an existing HSM to a replacement unit requires careful sequencing to avoid creating windows where key material is exposed outside hardware protection. The labour cost of a properly managed key migration can be significant, particularly for complex key hierarchies with strict regulatory requirements around key custody.

Regulatory Cost Drivers

PQC migration cost is not optional for organisations subject to the following regulatory obligations. The regulatory references convert the cost from a discretionary investment into a compliance requirement.

NIS2 Article 21(2)(h) requires cybersecurity risk management measures to include policies and procedures on the use of cryptography. Transposition deadline was October 2024. National authorities are enforcing from that date. Organisations in scope should be able to demonstrate cryptographic governance, not just a migration plan.

NIS2 Article 21(2)(d) covers supply chain security. PQC readiness of cryptographic libraries and HSM vendors is within scope as a supply chain cryptographic dependency. Vendor assessments and contractual PQC requirements are within this obligation.

DORA Articles 6 and 9 require EU and EEA financial entities to maintain an ICT risk management framework (Article 6) and implement protection and prevention measures including cryptographic controls (Article 9). Advanced digital resilience testing (TLPT) is governed by DORA Articles 24-27. Cryptographic resilience is within scope of Articles 6 and 9. DORA applied from 17 January 2025. UK financial institutions are not bound by DORA; they face FCA operational resilience requirements and NCSC guidance.

UK NIS Regulations 2018 (SI 2018/506) impose equivalent obligations for UK operators of essential services. These are a UK Statutory Instrument, not derived from the EU directive. The regulatory obligation persists post-Brexit.

Building a Defensible Budget

A defensible PQC migration budget is structured in phases, with each phase funded from the completed deliverables of the preceding phase. Attempting to budget the full programme before discovery is complete produces wide confidence intervals that make the budget difficult to defend. Governance structure determines whether phased budgets get approved: the Quantum Security Steering Committee Structure guide covers the budget approval thresholds and escalation paths a committee charter must define.

Phase 1: Discovery and inventory (Year 1). Budget this phase independently. The inventory determines migration scope, and therefore migration cost. Attempting to fund the full programme before discovery means either over-budgeting (and losing the budget to competing priorities) or under-budgeting (and needing a change request before the programme reaches its most expensive phase). Indicative cost for a standalone discovery engagement: $50K to $500K for mid-market organisations; $200K to $2M for enterprise, depending on estate scale. These are indicative ranges, not audited figures.

Phase 2: Migration sequencing by data sensitivity and system criticality. Systems handling IP, financial records, and regulated archives should migrate first. This produces a phased cost profile that spreads capital expenditure over two to four years, allows the organisation to demonstrate regulatory progress against the NIST IR 8547 2030 milestone for priority systems, and reduces the budget risk from simultaneous procurement, engineering, and regulatory change management demands.

Phase 3: Verification and assurance. Budget this from the outset. A post-migration audit phase is what converts a completed technical migration into a documented compliance position. For regulated organisations, this is not optional. External auditors and regulators will look for evidence of verification, not just a project completion record. Building assurance budget into Phase 1 estimates prevents it from being cut under budget pressure in Phase 3.

The regulatory deadline structure provides the budget planning anchor. No new Category 2 algorithm deployments after 2030, per NIST IR 8547 IPD. All Category 2 algorithms disallowed after 2035. A programme that completes discovery by 2026 or 2027, migrates priority systems by 2028 to 2029, and completes the full estate by 2033 is defensible against the current regulatory timeline and provides a buffer against the 2035 hard deadline.

Common Misconceptions

Our cloud provider handles PQC migration for us. For TLS and cloud-managed key management services: largely yes, for those specific components. Application-layer cryptography, code signing, VPN gateways, and on-premise HSMs remain the organisation's responsibility. The cloud provider covers the infrastructure layer it manages; the application and data layer sits outside that boundary.

We can defer until the standards mature. FIPS 203, 204, and 205 were finalised in August 2024. The standards are mature. Deferral shortens the available programme window without reducing the migration scope. It does not reduce cost; it concentrates it into a shorter timeframe, which typically increases cost through accelerated delivery premiums and reduced vendor negotiating leverage.

This is a one-time cost. The initial migration is front-loaded capital expenditure. Maintaining PQC-ready infrastructure requires ongoing investment in library updates, HSM firmware management, and certificate lifecycle management. Cryptographic agility is an ongoing operational capability, not a completed project.

The 2030 deadline is optional. NIST IR 8547 IPD Category 2 deprecation is a NIST standard, not a legal mandate in itself. However, NIS2 Article 21(2)(h) and DORA Article 6 create regulatory obligations to maintain appropriate cryptographic controls, and regulators are already referencing NIST standards as the operational benchmark for what "appropriate" means. The distinction between a voluntary standard and a regulatory expectation is narrowing.