Post-quantum cryptography for payment providers and PSPs

A payment service provider (PSP) can begin its post-quantum migration now, on the parts it controls alone: TLS on public and partner facing endpoints, internal service to service traffic, SSH administration, and the cryptographic inventory that PCI DSS already asks for. The parts that depend on third parties, card scheme specifications, EMV chip and contactless cryptography, hardware security modules (HSMs) and payment terminals, move on their suppliers' timetable. Separating the two is the whole exercise: migrate what you own, document what you do not, and keep both in one dated inventory.

Why key exchange comes first

RSA, ECDSA, EdDSA, ECDH and finite field Diffie-Hellman are all broken by Shor's algorithm on a large enough quantum computer, whatever the key size. No credible date for such a machine is given here. What matters for payments is the shape of the risk, known as harvest now, decrypt later (HNDL): traffic captured today is protected only by the key exchange that produced the session key, so an attacker who records it can decrypt it later, once that key exchange becomes breakable. A signature is different: forging one is only useful while the signature is still being trusted.

That is why hybrid key exchange comes first and signatures follow. For a PSP the recorded traffic is concrete: authorization messages, tokenization API calls, settlement and reconciliation files, batch transfers to acquirers and processors, and administrative sessions into the cardholder data environment. Our article on harvest now, decrypt later sets out the reasoning in detail. A hybrid group combines a classical key exchange with ML-KEM (Module Lattice Key Encapsulation Mechanism), published by NIST as FIPS 203 on 13 August 2024, so the session stays at least as strong as it is today even if one of the two components fails.

What a PSP can migrate now

• Public HTTPS endpoints: hosted payment pages, checkout scripts, merchant dashboards, webhook receivers and public APIs. The hybrid group X25519MLKEM768 (IANA codepoint 0x11EC, see the TLS parameters registry) is offered by default by current Chrome, Edge and Firefox, and clients that do not support it negotiate the classical group instead.
• Service to service TLS inside the cardholder data environment, where you own both ends and can upgrade libraries on your own schedule.
• SSH administration: OpenSSH 9.9 (19 September 2024) added mlkem768x25519-sha256, OpenSSH 10.0 (9 April 2025) made it the default key agreement, and OpenSSH 10.1 (6 October 2025) warns when a connection negotiates a non post-quantum key agreement. See the OpenSSH release notes.
• Pre-standard leftovers: any remaining X25519Kyber768Draft00 group (codepoint 0x6399) is obsolete and should be replaced by the ML-KEM groups.
• The inventory itself, which is a documentation exercise rather than a cryptography project, and which is the deliverable an assessor will usually ask for first.

Check what an endpoint negotiates today before changing anything. OpenSSL 3.5 or later is required for the ML-KEM groups:

openssl version
openssl s_client -connect api.example.com:443 -groups X25519MLKEM768 </dev/null 2>&1 | grep -i negotiated

On nginx built against OpenSSL 3.5 or later, the hybrid group is enabled by listing it ahead of the classical ones, which keeps the fallback in place:

ssl_protocols TLSv1.3 TLSv1.2;
ssl_ecdh_curve X25519MLKEM768:X25519:prime256v1;

Directive names and supported group names differ between servers and distributions, so confirm against your own build. Test in staging first, then watch handshake failure rates and client support after each production change. The hybrid key share is larger than a classical one, which can matter on constrained links and on old middleboxes that inspect the handshake. Hybrid key agreement for TLS 1.3 is specified in RFC 10024 (August 2026).

What depends on schemes, HSM vendors and terminals

The following areas are not a PSP's decision. No post-quantum dates for them are given here, because only dated primary sources are published on this site, and the schemes, EMVCo and HSM vendors are the only authorities for their own plans.

• EMV chip and contactless cryptography, including offline data authentication, which relies on RSA and elliptic curve keys fixed by specification.
• Card scheme network interfaces and the key hierarchies they impose on acquirers and processors.
• HSM firmware, certified configurations, and PKCS#11 support for ML-KEM and ML-DSA (Module Lattice Digital Signature Algorithm, FIPS 204).
• Key block formats and PIN related cryptography.
• Payment terminal hardware, whose replacement cycle is measured in years.

Interpretation, not a requirement: give every one of these dependencies a line in the inventory, with an internal owner, the supplier's published position if there is one, and a review date. When a scheme bulletin or an HSM release note appears, that line changes and the trail shows when you learned it. Supplier questionnaires at contract renewal are the other lever: ask for a written roadmap rather than assuming one exists.

PCI DSS 12.3.3 is already the backbone

PCI DSS v4.0.1 requirement 12.3.3 asks that cipher suites and protocols in use be documented and reviewed at least once every 12 months. It has three parts: an up to date inventory stating the purpose of each algorithm and where it is used, monitoring of the continued viability of what is in use, and a documented strategy to respond to anticipated changes in cryptographic vulnerabilities. It is mandatory since 31 March 2025, having been a best practice before that date; the standard is available from the PCI SSC document library. Our guide to the PCI DSS 12.3.3 cryptographic inventory covers the structure, and the PCI DSS v4.0.1 reference page keeps the dated milestones.

Read the third part closely. Anticipated changes in cryptographic vulnerabilities is where post-quantum belongs. Interpretation: the quantum vulnerability of RSA and elliptic curve key exchange is such an anticipated change, so a PSP's 12.3.3 strategy can name hybrid key exchange, state which endpoints are already migrated, and list the scheme and HSM dependencies with their owners. Requirement 12.3.3 does not require ML-KEM today.

DORA: what the text requires of EU financial entities

Commission Delegated Regulation (EU) 2024/1774, the regulatory technical standards on ICT risk management under DORA, applies to EU financial entities, payment and electronic money institutions included. Art. 6 requires a policy on encryption and cryptographic controls that includes provisions for updating or changing cryptographic technology based on developments in cryptanalysis. Art. 7 requires key management across the whole lifecycle and a register of certificates for ICT assets supporting critical or important functions. Both are summarised with their milestones on the DORA reference page.

The text names no algorithm and sets no post-quantum date. Interpretation: Art. 6 is met by a policy with a defined trigger and an approval route for changing an algorithm, and Art. 7 by a certificate register that already records algorithm and key size, which makes it the natural place to see what is still RSA or ECDSA. NIS2 Art. 21(2)(h) asks for policies and procedures on the use of cryptography in similar terms, through national transposition. This article is information, not legal advice.

Requirement to evidence

Official dates to plan against

None of these is payments specific, and none of them is a legal deadline for a PSP unless the last column says so. Keep the hedges when you quote them internally.

Start with the endpoints you can see

The fastest useful step is to measure what your public payment endpoints negotiate today, then decide the order of work: scan your domain with PQC Status for hybrid ML-KEM support, TLS versions and the certificate chain. Run it on the checkout domain, the API host and the webhook host separately, since they often sit behind different terminators. Record each result in the 12.3.3 inventory with its date, add the scheme, HSM and terminal dependencies as open lines with owners, and set the next review no more than twelve months out.