The distinction is important because it changes the task from an expensive, panic-driven encryption swap into a long migration program. IBM’s Think article frames the risk around “harvest now, decrypt later,” where an attacker preserves encrypted traffic, records, or backups until a future quantum computer can attack RSA and elliptic-curve cryptography. That risk model is credible enough that the G7 Cyber Expert Group, chaired by the U.S. Treasury and the Bank of England, published a financial-sector roadmap for quantum-resilient technology in January 2026.
The G7 guidance is also a useful corrective to the implication that a new compliance deadline has already landed. Treasury described the roadmap as non-prescriptive: it gives financial entities, authorities, and suppliers considerations for transition, rather than imposing a universal technical mandate. Organizations should plan for post-quantum migration now, but they should not mistake vendor urgency for a single global regulatory requirement or a proven near-term encryption collapse.
The payment risk is more than card data
Payment infrastructure has unusually durable information flows. The obvious targets include payment credentials, account identifiers, customer records, transaction histories, private keys, certificates, API authentication material, and cross-border payment messages. Data can outlive the session in which it was transmitted by years, particularly when it is copied into fraud systems, compliance archives, dispute records, data warehouses, backups, and partner-operated platforms.
That makes harvest now, decrypt later a data-retention problem as much as a cryptography problem. A quantum-safe key exchange deployed in 2030 or 2035 cannot retroactively protect traffic captured under a vulnerable key-establishment method in 2026. It also cannot erase historic data replicated to a ledger, archived by a counterparty, or retained in long-term backup media.
A 2025 Federal Reserve research paper examined this problem through distributed-ledger payment networks. The paper said that post-quantum mitigations may protect future network security and integrity, while previously recorded transaction privacy can remain exposed if an adversary has already retained data for later analysis. The authors were explicit that the work reflected their views, rather than a supervisory finding by the Federal Reserve Board. Still, the core operational point applies broadly: future-proofing a protocol does not repair old ciphertext.
For conventional payments, the highest-priority systems are not confined to consumer checkout pages. Real-time gross settlement participants, ACH operators, correspondent-bank gateways, HSM-backed certificate services, payment APIs, mobile-app back ends, VPNs, remote administration channels, code-signing systems, and managed file-transfer links all use cryptography in ways that can affect payment confidentiality, integrity, or availability.
RSA and ECC need migration plans, not a wholesale rip-out
IBM correctly identifies RSA and elliptic-curve cryptography as the public-key families threatened by a sufficiently capable quantum computer. Shor’s algorithm would undermine the mathematical assumptions used by RSA, Diffie-Hellman, and elliptic-curve systems. Those tools are foundational for establishing encryption keys and producing digital signatures.
But “payment encryption” is too broad a phrase. Symmetric encryption such as AES does not face the same type of break. Quantum attacks would reduce its effective security margin, which is why long-term designs commonly favor stronger symmetric key sizes, but an organization does not replace all of its encryption with a post-quantum algorithm. The pressing migration target is quantum-vulnerable public-key cryptography: key establishment, certificates, signing, identity, and trust chains.
NIST provided a concrete destination in August 2024 when it approved the first three post-quantum cryptography standards:
- FIPS 203 specifies ML-KEM, a key-encapsulation mechanism for establishing shared secrets.
- FIPS 204 specifies ML-DSA, a digital-signature standard.
- FIPS 205 specifies SLH-DSA, a second, hash-based signature standard.
These are standards, not a deployment checklist. A payment platform may depend on TLS libraries, Java runtimes, operating systems, smart cards, network appliances, hardware security modules, tokenization services, public certificate authorities, and payment-industry specifications that each move on different schedules. Changing an algorithm at one layer can reveal packet-size limits, latency issues, certificate-chain incompatibilities, firmware constraints, or partner systems that have no support for the new cryptography.
That is why NIST’s migration work emphasizes discovery and interoperability alongside algorithms. Its National Cybersecurity Center of Excellence is developing practices around cryptographic inventories, risk prioritization, and testing implementations in common standards. The difficult work is locating every dependency before it becomes an outage or a compliance exception.
Crypto inventory is the first real deliverable
IBM’s strongest point is its focus on poor visibility into keys and certificates. In large payment environments, cryptography is embedded well beyond the PKI team’s certificate manager. It may be hard-coded into application libraries, configured in an API gateway, delegated to a cloud key-management service, implemented within an HSM, bundled with a device SDK, or hidden behind a vendor’s managed service.
A useful inventory needs more than a count of X.509 certificates. It should identify the algorithm, key size, purpose, protocol, owning application, environment, data classification, certificate authority or trust anchor, dependency chain, rotation method, service-level requirement, and supplier responsible for the component. A certificate expiring in 90 days and a static elliptic-curve key baked into a payment-terminal firmware image deserve very different migration treatment.
For Windows and enterprise administrators, this means expanding the scope beyond Active Directory Certificate Services and the Windows certificate stores. Inventory should include IIS and reverse proxies terminating TLS; Remote Desktop gateways; SQL Server encryption and backup paths; Windows code-signing certificates; VPN appliances; third-party payment applications running on Windows Server; endpoint-management infrastructure; and hardware or cloud services whose cryptographic settings are managed outside the operating system.
The critical question is whether a service can change algorithms and keys without redesigning the application or breaking a business partner. That property, often called crypto-agility, is more valuable than simply having one post-quantum option available in a product menu. A platform with well-defined configuration, versioned APIs, automated certificate rotation, and tested rollback procedures has a viable path. A platform that treats algorithms and key formats as permanent implementation details does not.
Payment partners will determine the migration pace
Payment networks are federated systems. A bank can modernize its own TLS endpoint, but it cannot unilaterally force every correspondent, fintech processor, software vendor, card-network connection, terminal estate, and government settlement gateway to accept an unfamiliar key-exchange or signature scheme. The migration will therefore run at the speed of the least adaptable business-critical connection.
The G7 roadmap recognizes this coordination problem by addressing financial entities, authorities, and suppliers together. Its value is less about choosing ML-KEM or ML-DSA for an individual service and more about making quantum resilience a shared supplier-management and operational-resilience issue.
Financial institutions should start requiring answers in vendor reviews now: Which public-key algorithms are in use? Which products support NIST’s standards? Are hybrid deployments available, combining classical and post-quantum methods during transition? What are the performance effects? Can keys and certificates be rotated at scale? Which versions of client software, appliances, HSM firmware, and SDKs are required? And what happens when a payment partner cannot upgrade?
The absence of those answers is itself a risk finding. An organization that waits until its regulator names a mandatory date may discover too late that its core payments vendor, legacy terminal fleet, or cross-border connection needs a multiyear replacement cycle.
The countdown is to readiness, not Q-Day
IBM’s breach-cost figures and survey percentages should be treated as IBM’s own research claims, rather than evidence that post-quantum weaknesses have caused current payment breaches. There is no public indication that RSA or modern elliptic-curve cryptography has been defeated by a quantum computer in production. Conflating future cryptanalytic risk with an active break would obscure the real issue: sensitive information encrypted today may need to remain protected longer than an organization’s ability to re-engineer the systems carrying it.
The practical response is to classify data by required confidentiality lifetime, map where quantum-vulnerable public-key cryptography protects it, and prioritize systems whose records, credentials, signing keys, and trust relationships will still matter years from now. Payment operators should also test their first post-quantum-capable paths in isolated environments, with interoperability and rollback treated as production requirements rather than laboratory details.
The quantum deadline remains uncertain. The migration problem does not. For payment infrastructure, the first milestone is not deploying a fashionable new algorithm; it is producing an accurate cryptographic inventory and identifying the connections that cannot be upgraded without every party at the table.
