10 payment surfaces: 4 that need PQC, 6 that don't

Mental model

In M8 you saw PQC’s impact at the protocol layer of TLS, IKEv2 and SSH, and in M9 HSMs and key management. This lesson applies both to an area specific to the payments world: a bank’s payment cryptography is not a single “move to PQC” decision but an inventory of 10 different surfaces, each to be assessed separately according to its own cryptographic mechanism.

The criterion: asymmetric or symmetric

There is one criterion that separates these 10 surfaces: does the mechanism rest on asymmetric cryptography (RSA/ECC, the direct target of Shor’s algorithm from M1), or on symmetric cryptography (AES/TDES, whose effective key length Grover only halves, which AES-128+ already covers)? Applying this criterion to each surface splits the 10 cleanly in two: 4^ESTIMATED surfaces really need PQC, and 6^ESTIMATED structurally do not.

The 4 surfaces that really need PQC

Online card-issuer authentication: authenticating the cardholder to the issuing bank’s server over an online connection (TLS, certificates); asymmetric.

EMV 3DS (3-D Secure): an extra authentication layer in online card-not-present (e-commerce) transactions; TLS and certificate based, entirely asymmetric.

ISO 20022 signed messages: protecting the integrity of interbank messages with digital signatures (you will see the detail in M10’s third lesson); asymmetric signatures.

Payment gateway TLS: a payment gateway’s own TLS connections; a payment-specific example of the general TLS PQC transition you saw in M8.

The 6 surfaces that structurally do not

DUKPT (Derived Unique Key Per Transaction): the mechanism defined by ANSI X9.24 in which an initial key derived from a Base Derivation Key (BDK, a master key that stays central in the HSM and is never loaded into the terminal) and a Key Serial Number (KSN) are loaded into the terminal, and a unique working key is derived for each transaction (you will see the full flow in the next lesson); entirely symmetric (AES or TDES), with no asymmetric component at all.

PIN block encryption: encrypting a PIN while it travels between the terminal and the HSM; symmetric.

The EMV chip-offline transaction cryptogram (MAC): cryptograms such as the ARQC/TC a card produces in an EMV transaction are produced with symmetric session keys derived from the card’s own master key; careful, this must not be confused with SDA/DDA/CDA (Offline Data Authentication), a different EMV feature, which is asymmetric (you will see the detail in the next lesson).

Card personalization symmetric keys: keys loaded during a card’s production or personalization; symmetric.

ATM network encryption: encrypting network traffic between ATMs; usually symmetric.

HSM-internal symmetric operations: symmetric key operations a payment HSM performs internally (you will see how a payment HSM differs from a general-purpose HSM in the next lesson).

An exception: this list of 10 is not complete on its own

The warning in the “EMV chip-offline transaction cryptogram” item above must be taken seriously: SDA/DDA/CDA (Offline Data Authentication, ODA) is an asymmetric (RSA, and since 2022 also ECC) mechanism entirely separate from EMV’s transaction cryptogram, and it fits cleanly into none of the items of this list of 10 (this course’s own classification frame, the inventory the ADVISOR is expected to memorize): “online card-issuer authentication” covers an online scenario, while ODA is by definition offline. So this list should not be presented as “4 that need PQC + 6 that don’t = 10, complete and comprehensive”; ODA is a real, asymmetric eleventh item outside the list that must be tracked separately. In the next lesson you will see in detail how to tell this mechanism apart from the transaction cryptogram. By this course’s own discipline, this gap (the frame of 10 not covering ODA) must be stated openly rather than hidden; saying “10 surfaces, that’s all” would violate the very rigour this lesson teaches.

The corpus’s own error: a contradiction about DUKPT

A real example found during this research shows why this classification must be done carefully: one line of a research file (2026-08-15.md) says “AES-128 DUKPT PIN blocks are affected by PQC”, but in five separate places in the same file (lines 42, 87, 133, 307, 391) it is correctly repeated that DUKPT is symmetric and therefore not affected by PQC. This is probably a copy-and-paste or negation error, but it sits exactly in the section most likely to be skimmed and read first (①); if left uncorrected, a wrong claim would have been placed in the most visible spot. This lesson records the correct position clearly (DUKPT is entirely symmetric and not affected by PQC), based on ANSI X9.24’s own normative definition.

Numbers to know

Of the 10 payment surfaces, the 4 that really need PQC: online card-issuer authentication, EMV 3DS, ISO 20022 signed messages, payment gateway TLS (all asymmetric, TLS or certificate based)

The 6 that structurally do not: DUKPT, PIN block encryption, the EMV chip-offline transaction cryptogram (MAC), card personalization symmetric keys, ATM network encryption, HSM-internal symmetric operations (all symmetric; Grover's effect is already covered by AES-128+)

The exception, outside these 10: EMV's ODA (SDA/DDA/CDA), an asymmetric mechanism separate from the transaction cryptogram; the list of 10 does not cover it, and it is an eleventh real PQC surface to track separately

Lab: Mark the 10 surfaces for your own bank

[not run] This is an inventory and classification exercise, not a runnable command

shell

# Take your own organization's payment infrastructure and, for each of the 10 surfaces: do we have it, and if so which algorithm does it use (RSA/ECC or AES/TDES), and what is its PQC priority

Recorded output

A 10-row table: surface, present/absent, current algorithm, PQC priority (high/medium/not needed)

At the table

How to say this in a bank meeting.

To an executive

Our payment infrastructure's PQC risk is not 'everything equally urgent': of the 10 surfaces only 4 really rest on asymmetric cryptography; the other 6 are symmetric and structurally not under the quantum threat. Budget and priority should focus on those 4.

To an architect

The classification criterion is simple: does a mechanism rest on asymmetric cryptography (RSA/ECC, Shor's target) or on symmetric cryptography (AES/TDES, which Grover affects far more mildly)? Mechanisms such as DUKPT and PIN blocks are entirely symmetric; EMV 3DS and ISO 20022 signatures are entirely asymmetric. The confusion usually comes from the word 'EMV' itself covering both symmetric (the transaction cryptogram) and asymmetric (SDA/DDA/CDA offline authentication) components.

Objection

“"DUKPT is used for PIN encryption, and a PIN is very sensitive data, so shouldn't DUKPT be affected by PQC too?"”

Answer

Sensitivity and quantum exposure are different questions: DUKPT protecting sensitive data (the PIN) does not change the fact that it is symmetric (AES/TDES); by ANSI X9.24's own definition DUKPT contains no asymmetric component, so Shor's algorithm does not touch it, and Grover's effect is already covered by AES-128+ key lengths. This is exactly a corpus error this lesson corrects: one research file wrote 'DUKPT is affected by PQC' in one place, contradicting 5 correct statements in the rest of its own document.

Sources

ESSENTIALANSI X9.24-3: Retail Financial Services Symmetric Key Management, Part 3: DUKPT

ANSI/ASC X9, 2017. The normative source that DUKPT is entirely symmetric (AES-based) and contains no asymmetric component

overview / 5 min

ESSENTIALEMV Application Specification: Offline Data Authentication (SDA/DDA/CDA)

EMVCo, 2022. The source that EMV's offline card authentication (SDA/DDA/CDA) uses asymmetric algorithms such as RSA/ECC and is a mechanism separate from the transaction cryptogram (symmetric)

ODA (Offline Data Authentication) section / 10 min

Project linkThe direct skeleton of the payment cryptography section of Project 3 (crypto inventory and prioritization); the 10 surfaces of this lesson are the starting rows of Project 3's inventory template.