A bank’s PQC migration timeline is not entirely its own. Supplier roadmaps, embedded cryptography and crypto-agility all shape when critical systems can move.
A bank can have a clear view of which systems need to move to post-quantum cryptography (PQC) and still find that it cannot move them when it wants to.
In many cases, the constraint sits outside the bank. Cryptography may be embedded in an HSM, payment switch, certificate service, core banking platform, network appliance or cloud service where changes depend on a supplier releasing new firmware, software or hardware support.
A cryptographic inventory can show where RSA, ECC, certificates, keys and cryptographic libraries are being used, but it does not by itself establish who controls each change, when support will become available, or what other systems may need to move at the same time.
For financial institutions, those external dependencies can be extensive. The G7 Cyber Expert Group, in its January 2026 roadmap for the financial sector, notes that financial institutions are often highly dependent on technology products, suppliers and third parties, and that access to detailed supplier roadmaps can be important for effective migration planning.
Findings published in July 2026 in the whitepaper on quantum preparedness of Hong Kong’s banking sector, supported by the Hong Kong Monetary Authority (HKMA), show how this plays out in practice. Third-party dependencies were ranked among the top three barriers to PQC readiness by around 87% of the banks surveyed, and roughly 85% pointed to the absence of vendor PQC roadmaps. The same survey found that about 45% had no formal cryptographic bill of materials, and that around 71% had neither conducted nor planned any proof-of-concept or live testing of post-quantum algorithms or cryptographic agility solutions. The sector’s initial Quantum Preparedness Index score was 2.3 out of 10.
There is also a date to plan against. NIST’s transition roadmap for post-quantum cryptography standards proposes that quantum-vulnerable public-key algorithms, including RSA and ECDSA, are deprecated after 2030 and disallowed after 2035. That gives supplier conversations something more specific than a general sense of urgency: a release date only helps if it leaves the bank enough time to test and deploy before the algorithms it replaces are no longer considered acceptable.
For banks building a post-quantum migration roadmap, supplier readiness needs to be understood much earlier than the implementation stage.
Cryptographic discovery should come before the PQC roadmap
Cryptographic discovery remains the starting point because an institution first needs to understand where cryptography is being used and what depends on it.
The Bank for International Settlements (BIS) recommends developing a comprehensive cryptographic inventory and using automated discovery where possible across both on-premises and cloud environments. Once that inventory exists, institutions can distinguish between changes they can make internally, changes that depend on third-party suppliers and upgrades that may happen through the underlying service or platform.
That distinction should be recorded during discovery rather than added later.
Two systems, for example, may both rely on quantum-vulnerable public-key cryptography such as RSA or ECC. In one system, the algorithm may be configurable through a supported setting. In another, it may be embedded in commercial software and only become replaceable after the supplier releases a new version.
Figure 1. Two systems can carry the same cryptographic risk and sit on entirely different migration timetables.
From a cryptographic risk perspective, the two systems may initially look similar. From a migration perspective, they are very different, because one can potentially move according to the bank’s own schedule while the other is tied to a timetable the bank does not control.
A PQC roadmap that ranks systems by risk without understanding this dependency can therefore be technically sound while still being difficult to execute.
Figure 2. The same inventory, sorted by who controls the cryptographic change rather than by risk rating.
Supplier engagement should begin during PQC discovery
A common approach is to complete discovery, build the roadmap, and then start asking suppliers when their products will support post-quantum cryptography. The problem with that sequence is that the roadmap may already contain dates and assumptions that depend on answers nobody has obtained.
It is more useful to run supplier engagement alongside discovery. As systems and cryptographic dependencies are identified, the institution can start establishing which changes sit within its own control and which depend on an external product roadmap.
Figure 3. Running discovery and supplier engagement together keeps assumed dates out of the roadmap.
The inventory helps identify the suppliers that matter most, while supplier responses feed back into prioritization and migration sequencing.
The HKMA-supported whitepaper takes a similar position, recommending early engagement with critical vendors and bringing their post-quantum plans and readiness commitments into contracting decisions.
The aim is to move beyond a general assurance that a product will become “quantum ready” and establish enough detail for the bank to plan around it.
Four questions banks should ask critical suppliers about PQC
Question 1
What has to change in this product?
Saying PQC support is “on the roadmap” doesn’t tell a bank much. What matters is how the change lands: through a config setting, a software update, new firmware, or new hardware? Which algorithms and protocols get supported? Do certificates or key management need to be changed? What else does this touch – other applications, appliances, interfaces?
BIS lists the technology this could hit: cryptographic hardware, routers, firewalls, operating systems, applications, TLS, VPNs, SSH, PKI certificates, identity systems, developer libraries. A cryptographic bill of materials (CBOM) helps here. Instead of a supplier describing their cryptography in prose, they list it in a structured format the bank can check against its own inventory directly.
There are also performance considerations. Post-quantum keys, signatures, and ciphertexts are often much bigger than what they’re replacing, and that extra processing or bandwidth adds up fast in constrained environments. BIS highlights this in relation to systems such as point-of-sale infrastructure, where computational resources and latency are important. Mastercard’s research raises the same issue for smart cards and other constrained devices, where memory, communications overhead and transaction timing can affect what is practical.
A supplier’s answer needs to be about this product, in this deployment, not a general statement about their portfolio.
Question 2
Who controls the cryptographic change?
The next question is whether the institution can make the change itself or has to wait for the supplier.
If the algorithm can be changed through a supported configuration, the bank has real control over timing. If it is fixed inside the product, or bundled with a major release, the migration schedule becomes partly out of the bank’s hands
FS-ISAC’s guidance for the financial sector recommends assessing third-party products from this perspective. It asks institutions to establish whether PQC adoption will require hardware or architectural changes, how products will support cryptographic agility, and what migration guidance will the supplier provide?
Capturing this early reduces the risk of reaching implementation only to find that a high-priority system cannot move on the expected timetable.
Question 3
How difficult will the next cryptographic change be?
Post-quantum migration shouldn’t just swap in new algorithms; it should leave the bank better positioned for the change after this one. Otherwise, the new algorithms end up locked into the same rigid architecture as the old ones. FS-ISAC treats crypto-agility as a long-term strategy, tied directly to business continuity: if existing cryptography is weakened or broken, can the institution keep operating? That makes the supplier’s ability to change cryptography again just as relevant as its ability to support today’s PQC standards.
If a weakness was identified in an algorithm or implementation after deployment, a bank needs to know: can the supplier move to an alternative through configuration, or does it need a patch? Will connected systems also need changes? How long will that take?
A product that supports PQC but makes subsequent algorithm changes difficult has only solved this migration, not the one after it.
Question 4
When can the bank start testing PQC?
Production availability is only one date that matters.
Financial systems are interconnected, and changes to cryptography can affect application behavior, certificates, protocols, message sizes, latency, network devices, and external counterparties. Banks need real time to test new implementations in their own environment before they are expected to run in production.
FS-ISAC recommends validating quantum-resistant solutions in controlled environments, measuring their performance impact, running regression tests, and beginning migration with non-critical systems before moving into more critical areas.
Supplier discussions need to cover more than production data: when will a testable implementation be available, what interoperability guidance comes with it, and when is production support actually expected? These three answers are more useful for migration planning than a single end date.
Add supplier readiness to the cryptographic inventory
Information gathered from suppliers tends to end up across questionnaires, emails, meeting notes, and account-management conversations. That makes it difficult to use when migration priorities are reviewed months or years later.
A more useful approach is to link supplier readiness directly to the systems and cryptographic dependencies already captured during discovery.
A working record could include:
Supplier readiness register — blank template
The status itself does not need to be complicated. A supplier may have committed to both a capability and a date, confirmed that support is planned without providing a date, or not yet provided enough information for the institution to plan around.
If a critical system has no confirmed migration path, that should be visible in the program record rather than left as an unanswered field.
Build post-quantum readiness into procurement
There is a limit to what a bank can obtain from an existing supplier simply by asking for more detail: quantum readiness must become part of the requirements against which future products and renewals are assessed.
BIS recommends exactly this, coordinating migration with suppliers, using service-level arrangements to support accountability, and incorporating quantum-safe requirements into procurement processes.
For a financial institution, this means asking suppliers to provide information on the cryptographic algorithms and protocols relevant to their service, their post-quantum roadmap, whether cryptography can be changed through configuration, any hardware dependencies, planned testing and production dates, and the process they would follow if an algorithm needed to be replaced again.
Do this consistently, and procurement stops the bank from solving its cryptographic dependencies in one place while creating new ones in another.
A bank’s technology estate is unlikely to migrate at a single speed
Once supplier information is added to the cryptographic inventory, systems are likely to fall into several practical groups.
Figure 4. Three groups, and the different kind of decision each one requires.
Some can move largely according to the institution’s own timetable, because the relevant cryptography is configurable, and the required technology already supports the transition. These can be useful for early testing and migration work.
Others have a viable migration path but remain dependent on a supplier release, product upgrade or external service. These need to be managed as explicit dependencies, with clear ownership and regular review.
There may also be systems where no viable path has yet been established in the current product or architecture. Older platforms, constrained hardware and products nearing end of life are among those that may require closer assessment. In these cases, the institution may need an architectural or risk decision involving replacement, retirement, isolation, compensating controls, or a time-bound decision to continue operating while another path is developed.
Identifying these systems early gives the institution more time to make those decisions and account for the cost and complexity involved.
What banks should report on PQC readiness
A program can report that supplier engagement is 80% complete without telling management very much about whether migration is becoming easier.
For governance purposes, a smaller set of measures is more useful:
- the proportion of critical third-party products with a documented PQC roadmap
- the proportion with committed testing or production dates
- the number of critical systems whose migration remains dependent on an external provider
- the number for which no confirmed migration path currently exists
These numbers show where the real constraints sit and whether they’re easing over time, which “80% engaged” doesn’t. They also give the program evidence of progress before large-scale migration starts, which matters for something expected to run for several years.
A bank’s PQC roadmap must include technology it does not control
The G7 roadmap moves through 5 stages: awareness and preparation, discovery and inventory, risk assessment and planning, migration, testing and continuous validation. Third-party dependencies are called out explicitly during discovery, not left for later
BIS also places cryptographic inventory at the foundation of the transition and cautions against treating post-quantum migration as a simple replacement of one algorithm with another.
The HKMA-supported whitepaper adds the view from inside the banking sector. Institutions report limited visibility into cryptography embedded in third-party software. They report depending on suppliers for the risk information needed to assess it. And they report difficulty finalizing migration sequences without clearer roadmaps from suppliers and other connected parties.
A useful post-quantum cryptography roadmap needs to be captured more than the cryptography that needs to change. It needs to show which changes the bank controls, which depend on someone else, when those dependencies are expected to clear, and how easily the underlying systems can absorb the next cryptographic change.
Recording control alongside the cryptography itself is a discovery decision. It’s easier to make at the point of inventory than to reconstruct once a roadmap is already written. Without that information, the bank may know where it needs to go without yet having a reliable timetable for getting there.
References
G7 Cyber Expert Group, Statement on Advancing a Coordinated Roadmap for the Transition to Post-Quantum Cryptography in the Financial Sector, January 2026.
Quantum Preparedness of Hong Kong’s Banking Sector, whitepaper supported by the Hong Kong Monetary Authority, published with the first Quantum Preparedness Index, 27 July 2026.
NIST IR 8547, Transition to Post-Quantum Cryptography Standards, initial public draft, November 2024.
Bank for International Settlements, publications on quantum-safe migration for the financial system.
FS-ISAC, post-quantum cryptography guidance for the financial services sector.
Mastercard research on post-quantum cryptography in constrained devices and smart cards.