Skip to main content
Promotional banner ad for the Penetration Testing Report Kit
Quantum Readiness Isn't a Tech ProblemTechnical Controls
4 min readFor Risk Managers

Quantum Readiness Isn't a Tech Problem

The conventional wisdom: Financial institutions should wait for regulatory mandates before investing heavily in post-quantum cryptography migration. After all, you've got a dozen active compliance programs competing for the same budget, and regulators haven't issued requirements yet.

Why we disagree: You're treating quantum readiness like a regulatory checkbox when it's actually a dependency management crisis that will take years to solve. The U.S. Department of the Treasury launched its Quantum-Readiness Task Force on August 28, 2026, not because regulators are about to issue requirements, but because the financial sector faces what Utkarsh Ahuja, founder of Moon Pursuit Capital, calls a migration "with no deadline and no regulator behind it."

That's the problem. You can't schedule this work around an exam cycle.

The evidence

Consider what cryptographic inventory actually means for your institution. You're running encryption you didn't write, inside products you didn't build, on infrastructure that predates the algorithms you're now being told to replace. The Financial Services Information Sharing and Analysis Center warned in a September 2025 white paper about "crypto-procrastination" driven by firms underestimating the scale of the work.

Here's what makes this different from typical compliance migrations: most of the cryptography you rely on arrives inside purchased technology. Your migration timeline isn't set by your CISO or your board. It's set by your payment processors, cloud providers, custodians, software vendors, and counterparties, all of whom are moving at completely different speeds.

President Trump's June executive order requires federal systems to adopt post-quantum cryptography, but it doesn't create a regulatory requirement for your institution. Treasury's task force announcement doesn't signal that requirements are coming. What it signals is that the sector risk management agency recognizes this as a coordination problem, not a compliance problem.

The institutions that have made progress share one characteristic: they started inventory work years ago with dedicated teams and budgets. The ones waiting for regulatory clarity are discovering that inventory alone can take 18 to 24 months when you account for legacy systems, APIs, cloud infrastructure, acquired technology, and third-party software that's been sitting inside your environment for decades.

What to do instead

Start with cryptographic inventory, but frame it as dependency mapping rather than asset discovery. You need to know three things:

Where encryption lives in your critical paths. Don't try to inventory everything at once. Map the cryptographic dependencies in your payment processing, digital identity systems, and market infrastructure connections first. These are the systems where failed interoperability isn't an acceptable outcome.

Which dependencies you control and which you don't. An institution that does everything right internally still depends on external parties moving at their own pace. Document which cryptographic implementations are yours to change and which require vendor coordination or replacement.

What your vendors are doing. If you're a smaller institution without extensive internal capabilities, your quantum readiness depends almost entirely on your technology suppliers. Ask them specific questions: Have you completed cryptographic inventory? What's your migration timeline? Which products will support hybrid cryptography during the transition?

Smaller institutions should utilize the task force's work as it develops. Treasury said it will convene financial institutions, financial market infrastructures, and technology providers around cryptographic inventory, cryptographic agility, and interoperability. That's coordination you can't build alone.

Don't wait for a framework to tell you what to prioritize. The NIST Cybersecurity Framework (CSF) 2.0 already includes supply chain risk management as a core function. Apply that thinking here: your quantum readiness is constrained by your least-ready critical supplier.

When the conventional wisdom IS right

Regulatory mandates do provide clarity, and there's legitimate value in waiting for that clarity before making major technology investments. If you're choosing between two competing cryptographic standards, waiting for regulatory guidance prevents costly rework.

The conventional view is also correct that you can't do everything at once. You've got active programs for SOC 2 Type II, ISO/IEC 27001, NYDFS Cybersecurity Regulation, and a dozen other frameworks. Adding quantum migration as a parallel workstream without clear regulatory drivers is a hard sell to your board.

But here's the distinction: inventory and dependency mapping aren't technology investments. They're risk identification work that belongs in your existing third-party risk management program. You don't need regulatory mandates to document which systems use public-key cryptography or which vendors control your migration timeline.

The institutions treating this as a future compliance problem will discover they needed 24 months of preparation time they didn't allocate. The ones treating it as a dependency management problem today will have options when requirements do arrive.

Your quantum readiness timeline isn't set by regulators. It's set by the slowest critical vendor in your supply chain. Find out who that is now, while you still have time to do something about it.

Application Security Isn’t Optional Anymore.

You Might Also Like