up:: Doing the Work MOC
PQC for Banks
A bank CISO reading about post-quantum cryptography usually finds material about card payments, and cards are a real surface but a small share of the problem. The estate that actually sets a bank’s migration timeline is the core banking platform, the wire and messaging rails it connects to, the certificate and hardware-security-module layer that signs everything underneath, and a vendor stack whose post-quantum roadmaps somebody else writes. Most of that sits outside the bank’s own code, which changes what migration means: the work is inventory, contract leverage, and sequencing rather than engineering.
This note is general education about supervisory expectations and market practice, not legal or compliance advice. What any particular examiner expects of any particular institution is a conversation with its own counsel and regulators.
The short version:
- The card rail is the visible surface and the smallest one. Payments covers it; this note covers everything else.
- The only test of post-quantum cryptography inside an operational large-value payment system, run by central banks with Swift, measured signature verification at 209.9 ms against 28.1 ms for classical, and left the client-side HSM path unmeasured.
- The FFIEC withdrew the Cybersecurity Assessment Tool on 31 August 2025 and named no replacement, so a bank now chooses the framework its own cryptography gets assessed against.
- If the bank is New York licensed, encryption of nonpublic information in transit is already unconditional under 23 NYCRR 500.15, against a standard the regulation names only as “industry standards.”
- The lever is the same one every regulated buyer has and few use: the vendor contract, at renewal.
Where does a bank’s cryptography actually live?
In five places, and only one of them is usually the bank’s own code. Sorting the estate with the three zones produces a shape most bank security teams recognize immediately:
| Surface | Typical zone | Why it decides the timeline |
|---|---|---|
| Core banking platform | Zone 2 | Multi-decade vendor platform. Its cryptography changes when the vendor ships, not when the bank decides |
| Wire, ACH, and messaging rails | Zone 2 | Signature and channel security set by the scheme or network operator |
| Certificate estate and PKI | Zone 1 | The bank’s own, and usually the largest countable inventory it has |
| HSMs and key ceremonies | Zone 1 and 2 | The bank owns the process, the vendor owns the firmware and the algorithm support |
| Fintech, BaaS, and third-party connections | Zone 3 | Cryptography inside somebody else’s environment, reached only by contract |
The last row is the one that has grown fastest and is inventoried least. A bank running sponsor or banking-as-a-service relationships has extended its cryptographic estate into partners whose controls it supervises on paper and cannot see directly, which is the general problem vendor-controlled surfaces describes, arriving in the sector with the most regulatory attention on third-party risk.
What did the only operational test actually find?
The BIS Innovation Hub’s Project Leap Phase 2, published December 2025, ran post-quantum signatures inside a live large-value payment system with Banca d’Italia, Banque de France, Deutsche Bundesbank, Nexi and Swift. It is the closest thing the sector has to evidence rather than projection, and three of its findings matter to a bank.
Verification measured 209.9 ms against 28.1 ms. That is the post-quantum average against the classical equivalent for the same task, a factor of 7.5. ⚠️ The report’s own prose says the increase is “by at least an order of magnitude,” which its own published figures contradict, so quote the two numbers rather than the characterization. Its framing of the consequence holds either way: this “gives an indication of the potential need for more computing power.”
⚠️ The client-side HSM path was not measured. In the report’s words, “On the client side, the impact was not measured as an HSM was not utilised,” and it notes performance “can significantly vary depending on the type of HSM used, as manufacturers implement different hardware architectures.” For a bank this is the caveat that matters, because the HSM is where signing happens in production. The published figure is a floor rather than an estimate.
The algorithm tested was not the standardized one. Leap used CRYSTALS-Dilithium 6 at NIST security strength category 3, a Round 3 parameter set, and the report flags that the standardized version is ML-DSA and that the difference “will need to be addressed in future testing phases.”
Source: BIS Innovation Hub, “Project Leap Phase 2: quantum-proofing payment systems,” December 2025, bis.org/publ/othp107.pdf. Verification timings and the HSM caveat are from the Performance section; the algorithm note is from the technical footnotes.
What supervisory framework does this fall under now?
An unusually open one, and that is recent. The FFIEC sunset the Cybersecurity Assessment Tool on 31 August 2025, having decided not to update it for NIST Cybersecurity Framework 2.0 or CISA’s performance goals. It named two resources rather than a replacement: the NIST Cybersecurity Framework 2.0 and CISA’s Cybersecurity Performance Goals, and told institutions they may consider industry-developed resources for self-assessment.
Source: OCC Bulletin 2024-25, 29 August 2024, occ.gov; FDIC Financial Institution Letter, “Sunset of FFIEC Cybersecurity Assessment Tool,” fdic.gov, which is the source for the two named resources and the sentence quoted above. Other write-ups add the Cyber Risk Institute Profile and the CIS Controls to that list; neither appears in the primaries checked here, so they are omitted rather than repeated.
The consequence for cryptography is specific. The CAT was the default self-assessment for a large share of US institutions, so for years the question of what a bank assessed itself against had a common answer. Now every institution picks its own, and the framework it picks determines whether cryptographic inventory and agility get assessed at all, and the named alternatives differ on exactly that point. That is a governance choice sitting with the bank, made once, that shapes what an examiner sees for years.
And a state overlay can be stricter than any of them. A New York licensed institution is a covered entity under 23 NYCRR Part 500, whose definition reaches anyone operating under a license under the Banking Law. Section 500.15 requires a written policy mandating encryption “that meets industry standards” for nonpublic information in transit and at rest, and the Second Amendment struck the provision that had allowed CISO-approved compensating controls where in-transit encryption was infeasible. In-transit encryption is now unconditional for those institutions, and the standard it points at moves.
Source: NYDFS, Second Amendment to 23 NYCRR 500, effective 1 November 2023, sections 500.1(e), 500.15 and the transitional periods at 500.22(d)(2), dfs.ny.gov.
Why is the card rail the wrong place to start?
Because it is the surface a bank controls least and depends on most, and because it is already governed by scheme mandates that will move on their own schedule. A bank that opens its post-quantum program on EMV is starting with the one area where its own decisions barely change the date.
The higher-leverage first move is the certificate estate, for three reasons. It is countable, so it produces a real inventory in weeks rather than quarters. It is Zone 1, so nothing is waiting on a vendor. And it is where an unplanned expiry already causes outages, which means the bank has an owner, a process and a budget line for it before post-quantum enters the conversation. Certificate lifecycle management is the existing muscle this migration runs on.
What does a bank do about the vendors that actually set the date?
Ask in writing, on a renewal clock. The questions in the vendor-claims checklist are the ones that separate a vendor with a plan from a vendor with a paragraph, and procurement language turns an answer into an obligation. A core banking contract renegotiated without a cryptographic-agility clause is a multi-year commitment to somebody else’s timeline.
The bank-specific version of the ask is narrower than the generic one:
- Which components sign, and with what. Core, messaging adapters, and any module touching the rails.
- Dated support for ML-KEM and ML-DSA, by named release, separated into available and default.
- HSM firmware support, including which algorithms the currently deployed models can hold and which need replacement rather than an update.
- A CBOM scoped to the deployed version, not the current product.
- Documented downgrade behavior when a counterparty cannot negotiate post-quantum.
Common misconceptions
“Our card processor handles the cryptography.” They handle theirs. The core platform, the certificate estate, the HSMs and the third-party connections are not in that scope.
“We’ll follow the FFIEC’s guidance when it arrives.” The FFIEC withdrew the tool it had and pointed at external frameworks instead. Choosing among them is the bank’s decision and it is already live.
“Performance is a vendor problem.” The only operational measurement available shows verification an order of magnitude slower, taken without an HSM in the path. Capacity planning for that is the bank’s problem.
“We’re not in New York.” Licensing footprint decides it, and many institutions hold a New York license without thinking of themselves as New York banks.
“HNDL doesn’t apply to us, transactions are public soon enough.” Transaction data ages quickly and customer identity data does not. The test is in the vulnerability question, and account-opening files, beneficial-ownership records and wire instructions all fail it.
Questions people ask
Where should a bank actually start? The certificate estate, because it is countable, owned, and already has a budget owner. Discovery scoped to certificates produces a usable inventory faster than any other slice of the estate.
Do we need to replace HSMs? Some, and the answer is model-specific rather than vendor-specific. Ask which currently deployed models can hold the new algorithms in firmware and which need hardware replacement, because the second answer carries a procurement cycle inside it.
How does this interact with our third-party risk program? It belongs there rather than beside it. The program already collects vendor attestations on a renewal cycle, and the cryptographic questions are five more rows on a form that exists.
What about our fintech and BaaS partners? Their cryptography is inside the bank’s regulatory perimeter even though it is outside the bank’s network. Using a third party does not transfer responsibility for the controls, which is why the contract is the instrument.
Is a hybrid deployment the right first step? For anything negotiating with counterparties, yes, because it is where the deployed ecosystem is. Hybrid vs Pure PQC covers the tradeoff.
How long does the inventory take? Longer than a quarter for a full estate and a few weeks for the certificate layer. The variable is how much of the estate is vendor-hosted, which is also the variable that decides how much of the migration the bank can schedule itself.
Does any of this have a hard deadline for a commercial bank? No US supervisory deadline binds a commercial bank the way IR 8547 and CNSA 2.0 bind federal systems. The dates that will reach a bank first are a vendor’s release schedule and a scheme mandate, neither of which the bank sets.
Everything here is the map, given freely. When a bank needs its certificate estate and its core-platform dependencies inventoried and turned into contract language its vendors will actually sign, that’s the work I do.
Last verified 2026-09-07 · Updated 2026-09-07 · Maintained by Addie LaMarr, LaMarr Labs.