PQC for Banking

Why banks should start now

PQC is the principal mitigation described in the cited guidance for the future threat posed by large-scale, fault-tolerant quantum computers to today’s public-key cryptography. The timing problem is not only the date on which such a computer might exist. Sensitive encrypted information can be collected now and decrypted later, so a bank must consider the confidentiality lifetime of its records, customer information, transaction data, strategic information, and other protected material when deciding what to migrate first. The guidance therefore supports beginning preparation now, while preserving uncertainty about the arrival of a cryptographically relevant quantum computer.12

For a bank, the practical scope is broader than internet-facing encryption. Public-key cryptography can support encryption, key establishment, digital signatures, certificates, user authentication, software and firmware updates, and secure communications. It can appear in applications, databases, communication tools, cloud services, enterprise software, network protocols, libraries, servers, endpoints, hardware, and firmware. A migration that addresses only one customer channel or one transport protocol will not establish enterprise quantum readiness.32

1. Establish governance, scope, and migration goals

Create a formally sponsored quantum-readiness programme with a project-management team that can plan and scope migration. Include security and privacy risk managers, technology and operational owners, architecture, procurement, resilience, legal and compliance stakeholders, and representatives for customer, payment, identity, PKI, infrastructure, and third-party services. The purpose is not to create a separate cryptography silo: the cited guidance presents PQC migration as a broad IT and operational-technology change that can be integrated with wider cyber-resilience and modernization work.31

Define goals before prescribing technologies. Goals may include reducing exposure of long-lived confidential data, maintaining trusted authentication and signing, preserving payment and interbank interoperability, avoiding unplanned legacy estates, meeting applicable regulatory requirements, and enabling controlled cryptographic change. Record the business services and risk outcomes that each goal protects. The NCSC describes defining migration goals, discovery, and planning as interrelated phases rather than a rigid delivery method; a bank can therefore run discovery, risk analysis, vendor engagement, and pilot planning in parallel, provided dependencies and decisions are recorded.14

• Name an executive accountable for the programme and owners for each material service or cryptographic dependency.
• Define the systems, data, business processes, jurisdictions, suppliers, and operational environments in scope.
• Set decision criteria for confidentiality lifetime, business impact, updateability, interoperability, performance, resilience, and regulatory or contractual exposure.
• Create a decision log that distinguishes confirmed obligations, internal risk decisions, supplier commitments, assumptions, and unresolved uncertainty.
• Budget for preparatory work as well as implementation, testing, replacement, and operational support; the cited NCSC guidance warns that the total cost can be significant and the work can span multiple leadership cycles.

2. Build a cryptographic inventory that follows business dependencies

Discovery is the foundation of prioritization. Build an inventory of where the bank relies on quantum-vulnerable cryptography and connect each occurrence to the service, data, function, owner, supplier, protocol, implementation, key or certificate lifecycle, and update path. The CISA, NSA, and NIST fact sheet warns that organisations are often unaware of the breadth of application and functional dependencies on public-key cryptography. The inventory should therefore combine automated discovery with architecture reviews, procurement records, supplier evidence, source or binary analysis where appropriate, and interviews with service owners.32

At minimum, examine customer-facing and staff-facing channels; APIs and network protocols; payment and interbank connectivity; web, mobile, and enterprise applications; databases and encrypted stores; identity and access management; PKI and certificates; signing and verification; key-establishment mechanisms; code and firmware signing; endpoint and server libraries; on-premises products; cloud services; bespoke systems; hardware security modules and other cryptographic modules; operational technology where present; backup and archival systems; and third-party managed services. The cited evidence explicitly identifies applications, services, protocols, software, hardware, firmware, infrastructure, cloud products, and signing verification as relevant surfaces.324

Record data criticality and confidentiality lifetime, not merely the algorithm name. Capture where data moves or is accessed, which external parties have access, and whether a component is custom-built, commercial off-the-shelf, cloud-based, or embedded in a device that may be difficult to update. Include dependencies that validate signatures, because some deployed devices cannot feasibly be updated after manufacture. Treat missing inventory data as a risk finding with an owner and remediation plan rather than silently classifying it as safe.23

3. Prioritize by impact, longevity, and migration difficulty

Use the inventory to perform a quantum-risk assessment and produce a ranked migration backlog. Early attention should generally go to high-impact systems, critical processes, systems containing information with long-term confidentiality or secrecy needs, and components whose replacement or update requires long lead times. The cited guidance also highlights custom-built and older systems as likely to require the most effort. These are prioritization principles, not a substitute for the bank’s own threat, business-impact, resilience, and regulatory analysis.23

A useful prioritization model combines at least four dimensions: the consequence if confidentiality, integrity, authentication, or signing fails; the sensitivity and required lifetime of the protected data; the exposure and dependency structure of the service; and the feasibility and lead time of migration. A high-impact payment, identity, certificate, signing, or interbank dependency may need early testing even if its immediate quantum exposure is not the highest, because interoperability and operational change can be difficult. Conversely, a lower-impact component with a long replacement cycle may deserve early engineering attention.234

Do not confuse “PQC-ready” with “using a particular algorithm everywhere.” Readiness means that the bank knows where cryptography is used, understands its risks and dependencies, has a controlled transition strategy, can test and operate candidate mechanisms, and can replace or adapt cryptography without unacceptable disruption. That interpretation aligns with the cited definition of crypto agility as the capability to replace and adapt algorithms across protocols, applications, software, hardware, firmware, and infrastructure while preserving security and ongoing operations.4

4. Engineer crypto agility into the transition

Crypto agility should be an architectural and operational requirement for new work and major upgrades. Separate application and service logic from cryptographic implementation where practical; centralize policy and algorithm configuration; maintain explicit inventories of certificates, keys, algorithms, libraries, modules, and protocol versions; and provide tested replacement paths. The cited NIST material describes crypto agility broadly across protocols, applications, software, hardware, firmware, and infrastructure. It does not prescribe one design pattern, so each bank should select controls appropriate to its architecture and assurance requirements.4

In application and service modernization, plan for changes in key sizes, algorithm performance, protocol negotiation, certificate profiles, message formats, storage, and user or operator interfaces. NIST’s initial public draft states that applications and services may need modified cryptographic implementations, updated protocols and libraries, code refactoring, extensive testing, and potentially redesigned interfaces. These effects make PQC a product, platform, and operations concern, not solely a security-library upgrade.24

For PKI, identity, signing, and HSM-related functions, map certificate issuance and validation, trust anchors, key generation and storage, signing workflows, module dependencies, rotation, revocation, recovery, and device verification. The evidence confirms that cryptographic standards cover key-management practices and cryptographic modules, but it does not establish a universal banking HSM migration pattern or certification requirement. Document the applicable module, assurance, interoperability, and operational constraints for each use case instead of assuming that one transition method fits all.32

5. Test transition paths before production change

Transition planning must preserve backward compatibility and interoperability while new mechanisms are introduced. Establish representative test environments for customer channels, internal services, payment and interbank connections, identity, PKI, signing, cloud integrations, backups, and supplier interfaces. Test functional correctness, authentication and authorization, certificate and key lifecycle operations, latency, throughput, message and storage sizes, failure handling, recovery, monitoring, logging, and rollback. NIST’s draft specifically notes changes in key sizes and algorithm performance and the need for extensive testing.24

Where an application can justify it, a hybrid key-establishment mode or dual signatures may help maintain transition security or interoperability. The cited NIST draft says existing standards and guidelines accommodate such use when at least one component digital-signature algorithm is NIST-approved, and that NIST will accommodate hybrid key establishment and dual signatures in FIPS 140 validation when suitably combined with a NIST-approved scheme. It also leaves the decision to the specific application after considering implementation cost, performance reduction, engineering complexity, and proper independent security reviews. Hybrid is therefore a case-specific transition option, not a blanket banking mandate.2

1. Select representative high-priority services and dependencies from the inventory.
2. Define acceptance criteria for security, interoperability, performance, resilience, supportability, and rollback.
3. Test with internal systems, customer or partner interfaces, and supplier implementations where applicable.
4. Conduct independent review of cryptographic design, implementation, configuration, and operational procedures.
5. Record residual risks, incompatibilities, performance effects, and prerequisites before approving a production migration.

6. Make third parties and procurement part of the plan

Banks should ask technology vendors and cloud providers how they are addressing quantum readiness, how they will migrate products and services, when they will test and integrate PQC algorithms, and which versions or upgrades will be required. The cited joint fact sheet says this engagement applies to both on-premises commercial off-the-shelf and cloud-based products. For custom-built technology, assess whether the bank or supplier can migrate the implementation or must apply a compensating security upgrade while continued use is evaluated.31

Turn supplier conversations into evidence and contract controls. Request an identified product or service scope, cryptographic dependencies, planned transition approach, testing and interoperability evidence, support dates, upgrade paths, operational impact, and responsibilities for certificates, keys, modules, and incident response. The evidence encourages proactive planning for necessary changes to existing and future contracts; it does not provide standard contract wording or guarantee that any particular supplier will meet a date. Preserve those limitations in procurement decisions and third-party risk records.31

Supply-chain visibility is also an operational-resilience issue. The NCSC identifies clear views into systems, services, infrastructure, and actively managed supply chains as foundations for successful migration. A bank should therefore link supplier milestones to service continuity plans, replacement options, concentration risk, exit planning, and change windows, especially where a provider controls a shared protocol, PKI service, HSM capability, payment connection, or embedded device update path.13

7. Deliver in controlled waves and report residual risk

Convert the ranked backlog into waves: discovery and evidence gathering; architecture and crypto-agility foundations; pilots and interoperability testing; migration of the highest-priority services; then estate-wide remediation and retirement of vulnerable dependencies. Keep discovery active because new acquisitions, releases, suppliers, certificates, libraries, and services can reintroduce cryptographic dependencies. Gate each wave on evidence rather than calendar completion: inventory quality, approved design, test results, operational readiness, supplier commitments, rollback capability, and residual-risk acceptance.314

Report progress in terms meaningful to risk owners. Useful measures include the proportion of in-scope services inventoried; the proportion mapped to data lifetime and business impact; high-priority dependencies with an approved transition path; services tested with relevant partners; suppliers with documented roadmaps; unsupported or difficult-to-update components; and accepted residual risks with review dates. The cited evidence supports inventory, prioritization, vendor engagement, budgeting, and broader cyber-resilience governance, but it does not define a mandatory metric set.31

Conclusion

PQC readiness for banking is a managed transformation of cryptography, dependencies, suppliers, and operational processes. Begin with accountable governance and a defensible inventory; rank long-lived sensitive data, high-impact services, difficult-to-update technology, and critical dependencies; then build crypto agility, test interoperability and performance, engage vendors, and migrate in controlled waves. Use hybrid mechanisms only where the application’s risk and engineering analysis supports them. Because the cited guidance does not establish one universal banking deadline, a credible bank plan should distinguish binding obligations from recommendations, document uncertainty, and show how residual risk is governed.1342