
Regulation usually works like falling dominoes: government sets the first one, banking and finance follows, then heavily regulated industries and the rest. Predictable, orderly, almost boring.
Except now: the government tapped the domino. It fell. The banking domino wobbles but refuses to fall, a few dominos behind see opportunity and fall on their own.
Financial institutions are stuck on quantum cryptography. Many have started discovery initiatives, asset inventories, and awareness building. But the ‘responsible’ approach that got them started often prevents them from moving to remediation.
FS-ISAC (a global consortium focused on minimizing cyber risk across the financial sector) recently published a timeline paper providing a perfectly phrased diagnosis: crypto-procrastination. Most institutions have accepted that migration to the new cryptographic standards is necessary. RSA-2048’s days are numbered. Regulations are shaping up. The dominos are lining up and the requirements are clear… yet banking remains stuck in discovery, mapping what’s vulnerable without actually protecting it.
The SEC released their Post-Quantum Financial Infrastructure Framework noting exactly one real financial institution pilot to date. One out of thousands of banks globally.
Huzzah, someone did it! The SEC wrote: “technically feasible and operationally practical for major financial institutions.”
So why aren’t more financial institutions moving from discovery to deployment?
Aha moment: this is not a technology problem. The cryptographic community has done its homework and the playing field is clear with methods and tools available today.
The culprit is decision making. The gap between knowing what to do and doing it reveals how institutions evaluate risk under uncertainty. That gap is why dominos stand still.
Why “Responsible” Feels Like A Trap
Cautious approaches exist for great reasons. Banks do not experiment with customer financial data or deploy unproven technology. Being careful keeps banks in business.
There does come a point when threat timelines compress, and the conventional approach becomes a liability.
What feels responsible (comprehensive analysis) creates irresponsible delay. What feels safe (waiting for software vendors to migrate to PQC) cedes control. What feels correct (rewriting application code) creates paralysis.
Rational choices at each decision point. Collective paralysis as the outcome.
The paradox is not that financial institutions are being irresponsible. Rather, taking control of the PQC migration requires letting go of approaches that feel secure because they feel like control but are ultimately maintaining a vulnerability.
Three Compounding Patterns
Three patterns emerge when meeting with institutions that have not yet begun the great migration. Think of it as compound interest on organizational inertia – many small, rational choices that multiply into paralysis.
1. Perfect Becomes The Enemy of Begun
“We need to map all our cryptographic assets before we begin.”
Cryptography is everywhere: embedded in applications, legacy systems, protocols. The more one looks the more is found in unexpected places. Scope inevitably creeps.
Eighteen months pass still mapping, new systems added, no vulnerabilities fixed. ‘Complete’ becomes a moving target while adversaries get hundreds of qubits closer.
A colleague once observed a security leader present their 18-month discovery plan – many phases, cross-functional working groups, comprehensive results projected.
Deadpan, he asked, “Your house is on fire. The first thing you’re really going to do is rearrange your filing cabinet?”
The threat is not theoretical – Steal Now, Decrypt Later attacks are happening today for critical data. Yet the response for many is to spend two years making a very organized spreadsheet of what is burning.
The desire for perfection delays decisions to actually protect anything. Teams learn more from protecting one real system than mapping a hundred in spreadsheets.
Let’s be clear: comprehensive discovery matters. Many institutions have started there – good. However, completeness should not be a pre-requisite for starting to deploy new standards and protect data. These can and should be done in tandem. Just as you would if your home was ablaze – grab the high value assets first then go back for the rest.
2. The Dependency Dilemma
“We need to wait for our vendors to provide quantum-resistant solutions”
Why build something yourself when the vendors you already pay will deliver it? That is what they are there for after all. Plus, if we are being honest, cryptography feels scary to manage internally – better to have someone else be liable if something breaks.
Observe the loop: vendors wait for customer demand signals before prioritizing PQC. Customers wait for vendor solutions before starting migration planning. Thus everyone waits for industry coordination… meanwhile regulatory timelines move forward.
Aside from procrastination, this approach falls when even 99% of a financial institution’s vendor stack upgrades and that one hold out still creates a red mark on your compliance report. Cryptography is a bit of a weakest link problem and your slowest vendor ultimately determines your timeline if you cede control.
Bonus points, when the breach happens and that one vendor didn’t prioritize PQC yet becomes the entry point, whose business is exposed? Whose customer data is compromised? Not theirs… the financial institution.
Sure, the financial institution may not be contractually liable, and you can argue about indemnification but at the end of the day hard earned customer trust will be lost, and data will still be exposed.
Dependency may feel safer than ownership, but it means you are moving at the speed of your slowest critical vendor.
Another fear is uncovered at this level: “If we own cryptographic management, we will have to reskill our team and create an army of PhDs and experts.”
Not really.
Modern cryptographic management platforms emerging from this upgrade are designed for security operations teams, not cryptographers. The expertise is designed in the tooling, thus enabling teams to manage policies and monitor compliance rather than understanding the mathematical foundations of ML-KEM.
Yes, investment in new tooling and operational responsibility are required. The benefit far outweighs for the early adopters of PQC: control over their timeline and their risk.
Those who are migrating today have put their trust not in vendors and their strategies not in hopes that others move in time. They decided when to move.
Optimizing for a financial institution’s customer trust is not the responsibility of the institution’s vendors… that falls to the institution.
3. Architectural Paralysis
“We need to fix this at the application layer where cryptography actually lives.”
In reality, this plays out as: coordinating hundreds of dev teams, rewriting code without expertise, and testing systems documented in someone’s memory. A multi-year program requiring so much coordination that it never begins.
Here is the big one: Upgrading encryption does not require touching application code.
Cryptography does not have to be managed where it is embedded. It can be managed where it is well, more manageable: at the network layer. Data in transit can be protected without touching a single line of app code.
Protection is the goal not what has been built up as architectural purism. The institutions that embrace a new approach consistently find it simpler than expected. The way it has been done is not the way it has to be done.
Let the Dominos Fall
Protection requires one to protect. Start with what matters, not everything at once. Learn by doing while there is time to learn.
Everything is lined up – financial institutions that move now define the path for everyone else. Time to let the domino fall.
Join our LinkedIn group Information Security Community!
















