How Should Banks Plan and Budget for Post-Quantum Cryptography by 2026?

Direct Answer: Treat Post-Quantum Cryptography as a Multi-Year Cryptographic Transition

Banks should begin budgeting for post-quantum cryptography, or PQC, as a portfolio-wide technology and risk-management program rather than as a single cipher replacement. By 26 September 2026, the immediate issue is not whether a cryptographically relevant quantum computer will arrive on a fixed date; no credible forecast provides that certainty. The practical concern is that many banking systems depend on public-key algorithms whose security can be weakened by a sufficiently capable quantum computer, while the data requiring protection—customer records, payment instructions, code-signing assets and authentication secrets—may remain sensitive for years.

Also worth reading: How Should Banks Conduct a Quantum Risk Assessment Before the 2030 Deadline? · How Much Will Post-Quantum Bank Migration Cost, and What Is the 2026–2035 Timeline? · What is a post-quantum cryptographic agility roadmap and how should financial systems implement it?

A defensible bank budget needs to cover cryptographic inventory, risk assessment, vendor discovery, software upgrades, certificate or token changes, testing, employee training, migration exceptions and contingency capacity. A useful planning assumption is a three-stage program: establish governance and discover the estate during 2026; prioritize and pilot replacements during 2027–2028; then scale production migration over 2029–2033. Banks should also maintain classical algorithms temporarily because PQC migration cannot safely rely on wholesale “rip-and-replace” deployment. Costs cannot responsibly be given as one universal price: a bank with a small API estate may spend tens of thousands of dollars on initial planning, while a global institution with thousands of applications and regulated dependencies may need seven figures annually. The strongest budget case is based on exposure, system criticality and remediation lead time—not fear-based deadlines.

Why PQC Changes the Economics of Banking Cybersecurity

Quantum risk differs from ordinary cyber-threat planning because an attacker can record encrypted traffic today and attempt to decrypt it later. This is known as “harvest now, decrypt later.” Traditional transport encryption generally protects data in transit, but encrypted archives, retained records, scanned identity documents and high-value transaction workflows may give an attacker time to store information until better hardware becomes available. Payment data is not automatically the only concern: authentication credentials, private keys and operational instructions can be more valuable because they permit fraudulent access or manipulation.

PQC addresses that future risk through new mathematical algorithms and standardized implementations. NIST finalized its first three post-quantum standards in 2024: FIPS 203 for ML-KEM, FIPS 204 for ML-DSA and FIPS 205 for SLH-DSA. Earlier drafts have changed, and a migration begun only from memory may target obsolete or incorrect parameters. As of 2026, standards adoption remains active across hardware, operating systems, key-management products, certificate authorities and network appliances. A bank should therefore buy upgrade paths and measurable compatibility rather than assume that every product advertised as “quantum safe” has completed certification.

Budgeting is harder because quantum risk is asymmetric. Preventing ordinary credential theft may require constant spending, but cryptographic replacement costs are concentrated into discrete projects with long lead times. Banks that wait for a final vendor ecosystem may face rushed procurement, limited specialist staff and simultaneous hardware, software and compliance work. Conversely, replacing cryptography before a material quantum threat exists can produce weak returns if the project displaces controls against present-day attacks. The answer is staged spending: fund discovery and prototypes now, reserve capacity for difficult systems, and release large migration budgets as standards and supplier road maps become reliable.

A Practical Budget Model for Banks

The first budget category should be governance and discovery. Banks need an accountable executive, usually under the chief information security officer or chief technology officer, with representation from cryptography, architecture, legal, compliance, internal audit, procurement and business continuity. The team should identify algorithms, libraries, certificates, hardware security modules, secure code-signing systems, document-signing workflows and third-party connections. It also needs to classify data according to confidentiality and required secrecy lifetime. A payment instruction that must be protected for five years deserves different treatment from public product information, even if both use similar encryption technology.

The second category is remediation. Banks should create a migration cost per system, including design, development, integration, security testing, user acceptance, parallel operation, rollback, retraining and eventual retirement of legacy components. They should not budget only for cryptographic libraries, because changes can propagate into message formats, certificate chains, key sizes, latency, packet sizes and vendor contracts. A 2026 planning exercise might allocate 10%–20% of the initial PQC budget to inventory and architecture, 15%–30% to pilots and enabling platforms, and the remainder to phased production changes. These percentages are planning heuristics, not industry standards, and should be adjusted after the first inventory.

A useful financial control is to track “crypto-years,” meaning systems multiplied by the years they remain exposed or unsupported. Prioritize assets by confidentiality lifetime, quantum sensitivity, business impact, external dependencies and difficulty of replacement. Banks should place a strict date on collecting cryptographic bills of materials from critical suppliers, while accepting that no single quantum deadline is scientifically certain. As a starting threshold, systems supporting high-value payments, privileged administration, customer authentication and long-retained records should enter discovery immediately. Ordinary public-facing web content can be scheduled after the highest-risk dependencies, provided management explicitly accepts the residual risk.

Technical Alternatives and Comparison

PQC migration is not simply a choice between RSA and one replacement algorithm. Banks should compare different post-quantum primitives and hybrid approaches according to function, performance and ecosystem support. The relevant decision is rarely “which algorithm is best”; it is which algorithm is approved, supported and appropriate for a particular system, with a safe transition plan. Classical algorithms remain necessary during a staged migration, and many deployments will use hybrid classical-plus-quantum protection for a period.

Hybrid mode deserves particular scrutiny. It can preserve protection if the post-quantum component has a deployment defect and if the classical component remains secure against both current and future attacks. However, a hybrid design increases key size, configuration complexity and testing burden; it is not automatically superior in every application. Banks should compare hybrid, post-quantum-only and classical-only options for each use case rather than apply a blanket policy. They should also test downgrade behavior, certificate validation, randomness generation and failure modes.

Implementation Roadmap: From Inventory to Production

A bank can begin with a 90-day discovery sprint, followed by a longer program. During discovery, central teams should scan code repositories, configuration databases, certificate stores, network diagrams, cloud accounts, data centers and supplier contracts. The output is not a simple list of algorithms; it is a dependency graph showing where keys originate, where operations occur, which versions are used and which external organizations must upgrade. Software composition analysis is useful but insufficient because runtime configuration, embedded devices and vendor-managed services may never appear in source code.

The bank should then select representative pilots, such as internal authentication, public web access, API protection, payment-related signing and document verification. Each pilot needs a non-production environment, a rollback plan, performance baselines and clear success thresholds. For example, teams can measure handshake latency, throughput, memory consumption, certificate size, packet fragmentation, signing throughput, recovery behavior and interoperability with important customers or partners. They should run implementation testing against malformed inputs and verify that secret material is deleted or rotated correctly. A pilot that passes only the happy path is not evidence of production readiness.

From 2027 onward, banks should move the highest-risk systems first, but avoid depending on one primitive. They need a common cryptography abstraction, updated certificate profiles, approved key sizes, automated certificate lifecycle management and monitoring for unsupported algorithms. A central platform can reduce duplicated effort, while local application teams retain responsibility for business logic and acceptance testing. Migration should be wave-based: low-risk components can follow a broader platform release, while isolated devices and embedded systems may require longer procurement windows or compensating controls. The bank should rehearse rollback before every major cutover and document who can authorize continued use of a legacy algorithm.

Common Mistakes That Can Waste the Budget

The most common error is buying “quantum-resistant” products without an algorithm and dependency inventory. A vendor label does not reveal whether a product implements a standardized algorithm, uses vulnerable hybrids, exposes keys in application memory or depends on a certificate authority that cannot issue the required post-quantum certificate. Another mistake is treating the transition as a network-security project. It affects identity, code signing, secure email, databases, payments, customer onboarding, regulatory reporting and business-continuity systems. A limited budget focused only on external web traffic can leave a more dangerous internal or third-party dependency untouched.

A second error is equating a quantum deadline with a production-ready ecosystem. Media coverage often compresses a long research and migration process into a dramatic countdown, which encourages executives to demand immediate replacement. That approach can create rushed standards, poor key hygiene and duplicated spending. Banks should plan to a program horizon, refresh assumptions annually and distinguish a political target date from a known technical capability date. They should not delay discovery, but neither should they claim that every system must switch algorithms by a particular night in 2027.

A third mistake is ignoring people and process. Cryptographers, security architects, application owners and procurement specialists may be scarce, and vendor contracts may prohibit the disclosure needed for a complete inventory. Training should explain why dual controls, key rotation and algorithm agility matter. Legal and compliance teams should examine records-retention obligations, regulator expectations and contractual commitments. Internal audit should test whether the inventory is accurate and whether exceptions have named owners and expiration dates. Removing legacy cryptography too quickly can also create outages, so rollback and parallel validation deserve explicit budget lines.

When Banks Should Act and What It May Cost

All banks with customer authentication, payment operations, valuable stored data or critical cloud dependencies should act in 2026, even if they do not expect a cryptographically relevant quantum computer in the immediate future. The first action should be limited and concrete: appoint an owner, inventory public-key cryptography, identify data with long confidentiality lifetimes and ask the five to ten most important technology suppliers for post-quantum road maps and standards plans. A small institution can perform this exercise with a cross-functional team and external specialist support; it does not need to build a quantum computer or purchase a bespoke encryption platform.

Indicative spending must remain deliberately broad because published prices are not comparable across banks. A basic assessment or focused consulting engagement may cost roughly $25,000–$150,000, while larger discovery, laboratory and integration programs can run into the low or mid six figures. Hardware, certificate and managed-security services add recurring fees, and large migration programs can reach $1 million–$10 million or more depending on application count, regulatory scope and vendor readiness. These are planning ranges, not vendor quotes. They exclude the cost of replacing business applications, retraining large workforces or waiting for third-party ecosystems.

The best financial approach is to fund a small discovery tranche now, use it to produce a defensible total-cost estimate, and release subsequent tranches at defined milestones. Management should receive a register of systems ranked by exposure, estimated migration effort, supplier dependency and confidentiality lifetime. The board should receive the range of plausible costs, major assumptions, residual risks and the consequences of delay. That reporting is more useful than a single inflated “quantum security” number. PQC is a risk-reduction program, not a separate revenue line, and its success should be measured by fewer unsupported dependencies, tested migrations and documented exceptions—not by the volume of quantum-related technology purchased.

How an AI Financial Advisor Can Help Without Creating Hype

An AI financial advisor can help a bank organize PQC planning data, but it should not decide cryptographic standards or replace security testing. It can read inventories, classify systems using approved criteria, compare vendor questionnaires and generate draft cost scenarios. It can also summarize pilot results, flag inconsistent assumptions and produce reports for executives. Those capabilities are especially relevant because the task involves thousands of data points, changing vendor answers and relationships between applications, suppliers and data classes.

The limits are material. An AI model may hallucinate an algorithm name, attach an outdated NIST parameter, infer that a product is certified when it is not, or recommend a cost without understanding local labor rates and application complexity. PQC plans should therefore use a retrieval system grounded in current standards and approved supplier documentation, with citations shown to the reviewer. Every recommendation should identify its inputs, confidence level and unresolved assumptions. A human cryptography owner must approve the resulting policy, budget and migration sequence.

For a bank AI advisor, the best output is a repeatable planning workspace rather than a prediction of quantum attack timing. It could maintain a system register, map dependencies, estimate internal effort, compare hybrid and post-quantum pilots, and update risk scores when NIST guidance or vendor road maps change. It should not automatically treat an AI-generated ranking as an audit record. This approach lets banks use automation to reduce administrative effort while preserving expert accountability for cryptographic risk.

The Recommended 2026 Decision

The defensible decision on 26 September 2026 is to start a governed PQC budget now, with discovery and pilots as the first commitments. Banks should identify all public-key uses, prioritize long-lived secrets and high-impact services, and require suppliers to explain how they will support ML-KEM, ML-DSA, SLH-DSA or other approved mechanisms. They should reserve a migration budget for platforms and difficult systems rather than making an unsupported claim about a universal total cost.

The next 12 months should produce a dated roadmap, a prioritized system register, at least two technical pilots, a hybrid and post-quantum test policy, and an executive decision on funding waves. Management should review the plan quarterly because standards, products and guidance will continue to change. By 2027, the bank should be able to state which systems must move first, which suppliers are blocking progress, what rollback mechanisms exist and how much capital will be required in 2028–2030. That is more prudent than a dramatic deadline, and more credible than waiting until a quantum capability is demonstrated.

NIST’s publication on post-quantum cryptography, NIST’s finalized FIPS standards, the UK National Cyber Security Centre’s migration guidance, McKinsey’s banking-sector analysis of quantum communication and computing, PwC’s work on AI and banking, and BCG’s cybersecurity analysis all support the same general point: PQC is a long transition requiring institutional preparation. None of those sources justifies pretending that AI can calculate a guaranteed quantum date or that every bank needs the same immediate expenditure.