Most encryption deployed across payment networks today relies on math problems that are hard for classical computers but not fundamentally hard for a large enough quantum computer. RSA and elliptic curve cryptography, the two workhorses behind TLS handshakes, digital signatures, and key exchange in nearly every fintech stack, both fall to Shor’s algorithm once a quantum machine reaches sufficient scale. That machine does not exist yet. The risk to your transaction data already does.
Why ‘harvest now, decrypt later’ means your encrypted data is already at risk
A harvest-now-decrypt-later attack does not wait for a working quantum computer. An adversary copies encrypted traffic today, whether that’s intercepted TLS sessions, stored transaction logs, or archived customer financial records, and holds it until decryption becomes feasible. For data with a short shelf life, that’s not much of a threat. For financial data, it is.
Account numbers, transaction histories, KYC records, and the keys used to sign long-lived contracts or bonds often need to stay confidential for ten, twenty, or thirty years. A mortgage originated this year, a pension record, a cross-border settlement instruction tied to a multi-decade agreement: all of it is being encrypted right now with algorithms that a sufficiently powerful quantum computer will eventually read. The attacker doesn’t need a quantum computer today. They need patience and storage, both of which are cheap.
This reframes the question fintech security teams should be asking. It’s not “when will quantum computers break RSA.” It’s “how much of our currently encrypted data still needs to be confidential on the day that happens.” For a lot of financial data, the answer is yes, and the collection window for attackers is open right now, every day migration gets delayed.
How close a cryptographically relevant quantum computer actually is, and why the estimates keep moving
Estimates for when a cryptographically relevant quantum computer (one with enough stable, error-corrected qubits to actually run Shor’s algorithm against a 2048-bit RSA key) have shifted repeatedly over the past decade, and they keep shifting because the engineering problem is harder than the public conversation suggests. Current quantum hardware suffers from high error rates, and the qubits needed for error correction add overhead that dramatically increases the physical qubit count required for a “logical” qubit capable of sustained computation.
Several research groups and government bodies have offered projections ranging from the early 2030s to considerably later, and some practitioners argue a capable machine could arrive sooner if a breakthrough in error correction or qubit stability changes the trajectory. Others point out that progress in quantum computing has a long history of missing its own timelines. Both camps are right about the uncertainty, which is exactly the point: nobody responsible for securing a payments stack should be planning around a specific date.
What’s not uncertain is the direction of travel, and the fact that standards bodies, national governments, and card networks have stopped treating this as speculative. NIST finalized post-quantum cryptography standards, several governments have issued migration deadlines for their own agencies, and that alone changes the calculus for any fintech handling cross-border or regulated transaction data. Waiting for certainty about the hardware timeline means waiting past the point where a harvest-now attack already has your data.
The NIST post-quantum standards fintechs need to know
In August 2024, NIST finalized three post-quantum cryptography standards after an eight-year public evaluation process. These aren’t theoretical proposals anymore. They’re published, implementable standards, and they’re the ones fintech teams should be building migration plans around.
ML-KEM (FIPS 203), based on the CRYSTALS-Kyber algorithm, handles key encapsulation, the mechanism used to establish a shared secret between two parties over an insecure channel. This is the direct replacement for the key exchange step in TLS that currently relies on RSA or elliptic curve Diffie-Hellman. For a fintech, this is the piece that protects data in transit during API calls, payment authorizations, and session establishment.
ML-DSA (FIPS 204), based on CRYSTALS-Dilithium, handles digital signatures. This is the quantum-resistant replacement for RSA and ECDSA signatures used to authenticate messages, sign transactions, and verify code and firmware. ML-DSA is expected to become the default signature scheme for most applications because of its balance of performance and key size.
SLH-DSA (FIPS 205), based on SPHINCS+, is a second signature standard built on a completely different mathematical foundation (hash functions rather than lattices). It’s slower and produces larger signatures than ML-DSA, but it serves as a hedge: if a weakness is ever found in lattice-based math, SLH-DSA doesn’t share that vulnerability. For high-assurance financial signatures, having a structurally independent backup algorithm is worth the performance cost.
A fourth algorithm, HQC, was selected by NIST as a backup key encapsulation mechanism and is expected to be standardized later, offering the same kind of mathematical diversity for key exchange that SLH-DSA offers for signatures.
None of these are drop-in replacements in the sense of changing a config flag. They have different key sizes, different performance characteristics, and in some cases different failure modes than the RSA and ECC algorithms they replace. That matters for every system in your stack that currently assumes classical key and signature sizes.
Where quantum risk actually lives in a payments stack
Quantum risk isn’t one thing. It shows up in several distinct places in a typical fintech infrastructure, each needing its own migration approach.
- TLS and transport security. Every API call between services, every connection to a payment processor, every customer-facing session depends on TLS, and TLS’s key exchange step is exactly what ML-KEM replaces. Hybrid TLS configurations, which combine classical ECC with ML-KEM, are already supported in current versions of major TLS libraries and give you quantum resistance without dropping classical security as a fallback.
- Digital signatures on transactions and contracts. Anywhere your system signs a transaction, a token, a document, or a piece of firmware, you have a signature algorithm that needs evaluation. Long-lived signed artifacts, like contracts or audit records that must remain verifiable for decades, are higher priority than short-lived session tokens.
- Key exchange in internal systems. Service-to-service authentication, VPNs, and internal API gateways often use the same ECC-based key exchange as customer-facing TLS, and they’re frequently overlooked because they’re not customer-visible.
- Hardware security modules. HSMs generate, store, and use the private keys behind your most sensitive signing and encryption operations, which means they’re also the point where a post-quantum migration has to be physically and operationally supported. Not every HSM on the market today supports post-quantum algorithms, and firmware or hardware refresh cycles for HSMs run on a multi-year timeline, which makes this one of the longer lead-time items in a migration. If your HSM vendor doesn’t have a clear post-quantum roadmap, that’s worth raising now rather than at your next hardware refresh, and it’s worth reviewing against the criteria in a technical buyer’s guide to HSMs for fintech before you commit to a replacement cycle.
Crypto-agility: designing systems that can swap algorithms without a rebuild
The single most useful thing a fintech security team can do right now, independent of any specific algorithm choice, is build crypto-agility into the stack. Crypto-agility means your systems can swap out a cryptographic algorithm, a key size, or a protocol version without requiring a full application rebuild.
In practice, that means a few concrete engineering decisions. Cryptographic operations should be abstracted behind a library or service layer rather than hardcoded into application logic, so changing the underlying algorithm is a configuration change, not a code rewrite scattered across dozens of services. Key and signature sizes should not be hardcoded as fixed-length fields in databases or message formats, since post-quantum keys and signatures are often significantly larger than their classical counterparts. Protocol version negotiation should support running two algorithms side by side (hybrid mode) during a transition period, so you’re not forced into a single cutover date across your entire infrastructure.
Systems built this way absorb the ML-KEM and ML-DSA migration as a planned, incremental rollout. Systems without that flexibility face a forced, high-risk cutover whenever a deadline or a vendor dependency makes the decision for them.
A practical migration roadmap: inventory, prioritize, pilot, phase
A quantum-resistant cryptography migration isn’t a single project. It’s a multi-year program with a sequence that holds up regardless of how the hardware timeline shifts.
Inventory. Catalog every system, API, and data store that relies on RSA or ECC, including TLS configurations, signing services, VPNs, HSMs, and any third-party vendor connections. Most organizations find this list is larger and more tangled than expected, because cryptographic dependencies tend to be invisible until someone goes looking.
Prioritize. Rank what you find by two factors: how long the data needs to stay confidential, and how exposed the system is to interception. Data with long confidentiality requirements, like KYC records or long-term contracts, moves to the top regardless of how visible the system is. Internet-facing systems with short-lived data move up because they’re easier targets for harvest-now collection even if the payoff window is shorter.
Pilot. Start with hybrid TLS deployments on lower-risk, internet-facing services where current libraries already support ML-KEM alongside classical ECC. This gives your team operational experience with the new algorithms’ performance characteristics, larger key sizes, and any compatibility issues with existing load balancers, CDNs, or middleboxes, before you touch anything carrying regulated transaction data.
Phase. Roll the migration out in waves, moving from pilot systems to internal services to customer-facing production systems, with HSM and signature infrastructure treated as the longest lead-time items given hardware and vendor dependencies. Build in overlap periods where both classical and post-quantum algorithms run in parallel, so a problem discovered mid-migration doesn’t take down a production system.
This sequence works whether the cryptographically relevant quantum computer arrives in the early 2030s or later, because it’s built around managing exposure over time rather than hitting a single date.
What regulators, card networks, and standards bodies are already signaling
Regulatory and industry signals on this have moved from advisory to concrete faster than the underlying hardware threat has. Government agencies in several jurisdictions have published migration deadlines for their own systems, which tends to flow downstream into vendor and contractor requirements for any fintech doing business with them. Card networks and major payment processors have begun publishing their own post-quantum roadmaps and testing hybrid TLS in production environments.
Standards bodies beyond NIST, including ETSI and ISO, are incorporating the finalized FIPS 203 through 205 standards into broader frameworks that touch financial services specifically. The practical effect for a fintech security team is that post-quantum readiness is increasingly likely to show up as an audit or procurement requirement before it shows up as a hard legal mandate, which means the organizations that start migrating now will meet those requirements as a byproduct of work already done, rather than scrambling against a deadline they didn’t see coming.
Start the inventory now
The hardware timeline is genuinely uncertain, but the exposure from harvest-now-decrypt-later attacks is not. Start a cryptographic inventory of your transaction stack this quarter, flagging every system that relies on RSA or ECC key exchange, so you know your actual exposure before a migration deadline forces the question.