Point-to-Point Encryption

21.0 What this chapter gives you#

1. You will be able to explain why a shop can take card payments for a decade and never once hold a readable card number, and why that is a design decision rather than an achievement.
2. You will be able to tell a PCI-listed P2PE solution from a non-listed encryption solution, and say which of the two entitles a merchant to the short questionnaire.
3. You will be able to read a key serial number, name its fields in both the TDEA and the AES layouts, and explain why real-world KSNs so often begin FFFF.
4. You will be able to work out why a DUKPT device gets 1,048,575 transactions under TDEA and 2,448,023,842 under AES, rather than the powers of two those counters would suggest.
5. You will be able to explain why extracting a terminal’s key state exposes every future transaction and no past one, and why the remedy is re-injection rather than investigation.
6. You will be able to say why the card number and the PIN in the same transaction travel under different keys, and point at the derivation data that makes it so.
7. You will be able to explain to a merchant why encryption cannot support a refund six weeks later, and name the mechanism that can.
8. You will be able to list the four conditions that silently destroy a merchant’s scope reduction while the shop carries on working perfectly.
9. You will be able to diagnose the standard failures — key or KSN mismatch, counter exhaustion, a format 4 PIN block meeting a format 0 host, key block version mismatch — from their symptoms.
10. You will be able to explain why perfectly functional card readers were replaced in 2024, and what the supplier meant when it said “compliance”.

There is a garden centre outside Norwich that takes about eleven hundred card payments a week and has never held a card number. Not in the till. Not in the back-office PC that runs the stock system. Not in the cloud service that sends the loyalty emails. Not in the nightly export that goes to the accountant. Card numbers have passed through that building at a rate of one every four minutes since 2016, and not one of them has been legible to anybody on the premises, including the owner.

This is not because the garden centre is unusually sophisticated. It is because the card reader on the counter arrived from the supplier already loaded with a secret, and turns every card it reads into an unreadable block before the till software is allowed near it. The shop is not trusted with card numbers. It is not asked to be trustworthy. The design assumes that sooner or later somebody will get into the shop’s network, and arranges for that to be uninteresting.

The previous chapter was about the terminal as a certified object. This chapter is about what the terminal does with what it reads, and about the single commercial fact that pays for all of it. Encryption in the terminal is not bought for elegance. It is bought because a merchant who cannot read card numbers has a much smaller compliance problem than a merchant who can, and the difference is measured in weeks of audit and thousands of pounds a year.

The plain version#

Imagine you run a shop, and imagine that the most dangerous thing in the shop is not the cash in the till but a notebook by the door in which every customer’s card number is written down. You do not want the notebook. You never wanted the notebook. But every card machine you have ever seen had to read the number in order to ask the bank for the money, and if the machine read it, something in your shop knew it.

Now imagine a different machine. This one has a slot for the card and a little sealed box inside it. When a customer inserts a card, the number goes straight into the sealed box and is scrambled there. What comes out of the machine is not a card number. It is a block of nonsense, thirty-two characters long, that looks like somebody sat on a keyboard. Your till receives the nonsense. Your network carries the nonsense. Your broadband router, your stock system, your accountant’s export, the hacker who eventually gets into your Wi-Fi: all of them get nonsense.

Somewhere else entirely, in a building you will never visit, there is a matching sealed box. It is the only thing in the world that can turn that nonsense back into a card number, and it does so for a fraction of a second, inside its own metal case, in order to ask the bank for the money. There are exactly two points in this story where a readable card number exists: inside the sealed box in your card reader, and inside the sealed box in that distant building. Between them there is a pipe full of nonsense. That is why it is called point-to-point encryption. The two points are the only places worth attacking, and neither of them is in your shop.

A worked example#

A customer buys £46.80 of compost and bark chippings. She taps her card. Inside the reader, the chip hands over a card number, sixteen digits long, and the reader immediately does two things with it.

First, it keeps a small, deliberately useless summary: the first six digits and the last four, so the till can print •••• •••• •••• 0016 on the receipt and so the software knows the card was a Visa debit rather than an American Express. Second, it takes the full number and scrambles it with a key.

Here is the part that is cleverer than people expect. The reader does not have one key. It has a book of keys, and it uses a different page for every single transaction. The compost sale uses page 1. The next customer, buying a rose bush at 10:14, uses page 2. The man who buys two bags of gravel at 10:19 uses page 3. And each page, once used, is torn out and burnt: the reader physically overwrites the key it just used so that it no longer exists inside the machine. The book has room for roughly a million pages in older readers and around two thousand million in newer ones, which at eleven hundred transactions a week is more than the reader will live to spend.

So the block of nonsense that arrives at the till carries one extra thing with it: a page number. Not a key, a page number. Something like “device 90123456, transaction 1”. The distant sealed box holds the master recipe from which every page of that particular reader’s book can be worked out, so when it is told “device 90123456, page 1”, it can reconstruct page 1, use it once to unscramble the compost sale, and throw it away again.

Count what the thief gets if he owns your shop completely. He gets the nonsense blocks. He gets the page numbers, which are not secret and are useless without the master recipe. He gets •••• 0016 and the fact that a Visa debit card spent £46.80 on compost. He cannot manufacture a card, buy a television, or sell a list of numbers, because the shop never had a list.

And the boring reason anybody bothers#

Everyone who takes card payments has to answer to a rulebook called PCI DSS. If your systems handle readable card numbers, the version of that rulebook you have to satisfy is enormous: hundreds of individual requirements about firewalls, patching, anti-virus, logging, password rules, penetration tests and network segmentation, applied to every computer that the card number could conceivably touch, which in a small business means every computer.

If you use one of these encrypting readers, and if the encrypting reader is part of a scheme that has been formally inspected and published on a list, you are allowed to answer a much shorter questionnaire instead. It asks whether your card readers are the ones you think they are, whether anybody has glued a fake one on top, whether you followed the manual the supplier gave you, and whether you have written down who is responsible. That is very nearly the whole of it, because there is no computer in the shop holding card numbers for the long questionnaire to protect.

That reduction is the product. The cryptography is the mechanism.

Where the plain version stops being true#

The reader does not encrypt everything, and it does not use one key#

The plain version implies that nothing readable leaves the sealed box. In practice the box deliberately emits readable things, because the shop cannot function otherwise. Almost every deployment returns the first six or eight digits and the last four in clear, so that the till can route by card range, apply the right surcharge rules and print a receipt a human can match to a card. Many return the expiry date and the cardholder name in clear too. That is a choice made by the solution designer, and it is a choice with consequences: a BIN plus last four is not a card number, but it is not nothing either.

More importantly, the PIN is not protected by the same key as the card number, and never was. Card data and PIN travel under separate keys derived from the same hierarchy, so that a compromise of the account-data key does not hand over PINs, and so that PIN handling stays inside the older, stricter regime that governs PINs specifically. There is not one encrypted blob in the message. There are two, with different keys, different formats and different rulebooks.

Encrypting is not the same as being out of scope#

This is the correction that costs merchants the most money. A vendor who says “our terminals encrypt end to end” has told you something about their engineering and nothing about your paperwork. The short questionnaire is available only where the whole arrangement — device, firmware, key loading, key management, decryption environment, and the manual the merchant is handed — has been assessed against the P2PE Standard by a qualified assessor and published on the Council’s list of validated solutions.

Solutions that encrypt in hardware but have never been through that process are called non-listed encryption solutions, and there is a separate, formal, and distinctly less generous route for them: an assessor documents what the solution actually achieves, and the merchant’s acquirer decides how much scope reduction, if any, to grant. It may be a great deal. It is not automatic, and it is not the merchant’s decision.

One-time keys are not one-time pads, and the protection runs backwards in time only#

The plain version’s book of pages suggests that each transaction is sealed off from every other. That is half true, and the half that is false matters.

The keys are derived from one another in a chain that cannot be run in reverse. An attacker who extracts the working state from a reader cannot compute the keys it used yesterday, so yesterday’s captured traffic stays safe. But the state he extracts is precisely the material from which every future key of that device is derived. From the moment of compromise until the device is taken out of service and re-keyed, he can decrypt everything it sends. The scheme protects the past, not the future.

And behind every device’s book of pages sits one master secret, held by the solution provider, from which the initial key of every reader in the family is derived. Lose one reader and you lose one shop’s future traffic. Lose that master secret and you lose every reader derived from it, retrospectively and prospectively, at which point the only remedy is to re-inject the entire estate. This is why the master secret never exists in one piece, in one person’s hands, outside a tamper-responsive box.

The second point is not your bank, and encryption gives you nothing to hold on to#

“Point to point” invites the assumption that the far point is the merchant’s bank. Usually it is not. The decrypting box normally belongs to whoever runs the encryption scheme — a gateway, a processor, a terminal estate manager — and the card number is decrypted there before an authorisation message is built and sent onward. The merchant’s acquirer may be a further hop away, and may never see the encrypted form at all.

There is also something encryption structurally cannot do. Because the ciphertext changes on every transaction, it is useless as an identifier. It cannot tell you that the woman buying compost today is the same woman who bought a hosepipe in May, cannot be stored for a refund six weeks later, and cannot be used to bill a subscription. For those a merchant needs a stable substitute for the card number, valid for months, safe to store, and that is a different mechanism with a different name and a different scope story. Encryption protects data in flight. Tokenisation replaces it at rest. Most real estates use both, and confusing them is the commonest error in this field.

The technical version#

What “P2PE” means in the Council’s own words#

Point-to-point encryption in the ordinary engineering sense is any arrangement that encrypts account data at the point of capture and decrypts it somewhere trusted. P2PE with a capital P is narrower: it is a PCI Security Standards Council programme, with a standard, an assessor qualification, a reporting template and a public list.

The Council’s own summary is worth quoting because the wording is load-bearing. A PCI-listed P2PE solution “cryptographically protects account data from the point where a merchant accepts the payment card to the secure point of decryption”, with the effect that account data — “cardholder data and sensitive authentication data” — “is unreadable until it reaches the secure decryption environment”. The current standard is the PCI Point-to-Point Encryption Standard v3.2, published in June 2025, superseding v3.1 of September 2021; the accompanying Program Guide reached v3.2 in July 2026.

Four defined objects do most of the work in that programme, and practitioners who mix them up write incoherent contracts:

A P2PE solution is the complete package — devices, applications, key management, decryption — offered to merchants and listed as a unit. A P2PE application is “software with access to clear-text account data, intended to be loaded onto a PCI-approved point of interaction (POI) device and used as part of a P2PE solution”. A P2PE component is a service that is assessed and listed on a stand-alone basis and can be incorporated by reference into somebody else’s solution. A P2PE solution provider is “an entity, usually a third-party such as a processor, acquirer (merchant bank), or payment gateway, that designs, implements, and manages the P2PE solution”, and — the sentence that decides liability arguments — “may outsource certain responsibilities, but will always retain overall responsibility for the P2PE solution”.

The merchant is not on that list, with one exception: a merchant that builds and runs its own encryption estate is assessed as a merchant-managed solution, against its own reporting template, and cannot then use the short questionnaire as if it were somebody else’s customer.

Five domains and the paperwork that maps onto them#

The v3 standard organises its requirements into five domains, numbered 1 to 5, and assessments are reported as a set of Reports on Validation, abbreviated P-ROV. The mapping is set out explicitly in the summary table of the Solution P-ROV template:

Read that table as an architecture diagram rather than a filing system. Domain 1 is the encryption side: the devices, their deployment, their firmware, their chain of custody. Domain 2 is any software running on the device with sight of clear-text account data. Domain 3 is the governance of the solution as a whole, including the instructions given to merchants. Domain 4 is the decryption environment. Domain 5 is cryptographic key operations, and it is shared, which is why it appears twice: the same key-management requirements bind the party that injects keys into terminals and the party that decrypts with them.

Requirements are identified in a compound style — Domain 1’s requirement 1B-1.1.1 and Domain 2’s 2A-3.1.2, for instance, both concern devices and applications that facilitate merchant-managed decryption — and anyone drafting a gap analysis should cite them in that form rather than by paraphrase.

The programme also lists individual components, referred to throughout the templates by abbreviation: EMCP, PDCP, PMCP, KMCP and KLCP, along with key injection facilities (KIF) and certification and registration authorities (CA/RA). A solution provider assembles validated components and inherits their assessed scope. Where remote key distribution is used, its requirements are additional to, not instead of, the rest.

Two more artefacts matter operationally. The P2PE Instruction Manual (PIM) is the document the solution provider must produce and the merchant must follow; deviating from it is the most common way a merchant silently loses eligibility for the short questionnaire. The Attestation of Validation (AOV) is the signed summary that accompanies the P-ROV and precedes listing.

The device: PTS POI approval and the SRED module#

P2PE encryption happens in a PCI PTS approved point-of-interaction device. The relevant standard is the PCI PIN Transaction Security (PTS) Point of Interaction (POI) Modular Security Requirements, v7.0 as of May 2025, with v6.2 (January 2023) and v6 (June 2020) still supporting large fielded populations. Its structure is modular, and the module that makes P2PE possible is Evaluation Module 4, Secure Reading and Exchange of Data — SRED — whose requirements are lettered K under the heading “Account Data Protection”.

SRED is where the sealed box of the plain version is specified. Requirement numbering has been revised between POI versions, so cite the version you are certifying against, but the substance of the K series has been stable since it was introduced:

All account data must be “either encrypted immediately upon entry or entered in clear-text into a secure device and processed within the secure controller of the device”, with no method of accessing the clear-text data. Encryption must use “only ANSI X9 or ISO-approved encryption algorithms (e.g., AES, TDES)” and should use approved modes of operation. Secret and private keys held in the device to support account data encryption must be “unique per device” — a single requirement that rules out the entire class of shared-key deployments that used to be normal. Encrypting or decrypting arbitrary data with an account-data key or key-encrypting key is forbidden, which closes the obvious decryption-oracle attack. When operating in encrypting mode there must be “no mechanism in the device that would allow the outputting of clear-text account data”, and the secure controller may release clear-text account data only to authenticated applications executing within the device. Where the device generates surrogate PAN values for output, it must not be possible to determine the original PAN from the surrogate, and where a hash is used the input must include a salt of at least 64 bits. Devices must also have characteristics that “prevent or significantly deter” their use for exhaustive PAN determination — that is, for BIN-range brute forcing by a criminal with a stolen terminal.

Determining the account-data encryption keys by penetrating the device or by monitoring its emanations, including power fluctuations, must require an attack potential above a defined threshold: SRED is tested against side channels, not only screwdrivers.

Note what SRED does not cover. PINs are governed by the PIN-related modules of the same document and by the PCI PIN Security Requirements. A device can be PTS approved without SRED, which is why “PCI approved terminal” is not a synonym for “encrypting terminal”, and why terminal estates contain both.

What counts as account data#

The scope of encryption is account data, not merely the PAN: the primary account number, the full track data or track-equivalent data from chip or stripe, the expiry date, the service code, and the card verification values where present. Sensitive authentication data — full track data, card verification codes, PINs and PIN blocks — must not be retained after authorisation at all, encrypted or otherwise, a prohibition that survives every scope reduction in this chapter and is stated in PCI DSS v4.0.1 at Requirement 3.3.1.

Where a PAN is displayed, the maximum that may be shown is the BIN and the last four digits (Requirement 3.4.1); where it is stored, it must be rendered unreadable (Requirement 3.5.1). Those two rules, not P2PE, are the source of the •••• 0016 convention on receipts.

DUKPT, part one: the TDEA scheme#

Derived Unique Key Per Transaction is the key-management scheme that makes per-transaction keys practical without a network round trip. It is specified in ANSI X9.24 — Part 1 for the original triple-DEA scheme, Part 3 for the AES scheme. Every practitioner meets the TDEA version first because it is what most fielded devices still use.

The structure is a three-level hierarchy. At the top is the base derivation key (BDK), a double-length TDEA key held only inside the solution provider’s HSMs. From the BDK and a device-specific serial value, the provider derives one initial PIN encryption key (IPEK) per device, injects it, and does not keep it. The device then never uses the IPEK for a transaction: it uses it to populate a set of twenty-one future-key registers, and from those it derives the key for each transaction in turn, erasing each key after use through a transformation that cannot be inverted. That non-reversibility is the whole security argument: the device’s present state does not reveal its past keys.

Every message carries a key serial number (KSN) so the receiving HSM knows which key to reconstruct. The TDEA KSN is ten bytes. In the conventional layout it is read as a 24-bit key set identifier, a 19-bit device identifier and a 21-bit transaction counter, left-padded with F nibbles to fill the ten bytes — which is why real-world KSNs so often begin FFFF. Field engineers also describe the same thing as “6-5-5” after the hexadecimal digit groups; on that reading a scheme permits roughly sixteen million BDKs, five hundred thousand devices per BDK and a million transactions per device.

The million is not 2^21. The algorithm increments the counter so that no more than ten of its twenty-one bits are ever set at once, because the count of set bits determines how many derivation steps are needed. The usable counter values therefore number 1,048,575, and a device that reaches the end of its counter must be re-injected rather than rolled over.

DUKPT, part two: the AES scheme, with real numbers#

ANSI X9.24-3-2017 replaces the TDEA construction with an AES one, and changes the vocabulary: the per-device key is now the initial key (IK) rather than the IPEK, since it derives data and MAC keys as well as PIN keys. Key types may be two-key TDEA, three-key TDEA, AES-128, AES-192 or AES-256, and the same tree serves all purposes.

The AES KSN is twelve bytes: a 32-bit BDK identifier, a 32-bit derivation identifier and a 32-bit transaction counter. The first eight of those bytes together are the initial key ID, which is what the IK is derived from.

Derivation is a keyed function over a sixteen-byte block of derivation data whose layout is fixed:

The key block counter exists so that keys longer than one AES block can be produced from more than one derivation block. The algorithm indicator distinguishes key types: 0000 for two-key TDEA and 0002 for AES-128 in the standard’s own test vectors. The key usage indicator is the field that separates purposes, and its values are worth memorising because they appear in HSM command traces:

The published test vectors accompanying X9.24-3-2017 make the whole mechanism concrete, and they are the fastest way to prove a new implementation correct. Take the base derivation key FEDCBA98 76543210 F1F1F1F1 F1F1F1F1 and the initial key ID 12345678 90123456. The derivation data for the initial key is 01018001 00020080 12345678 90123456 — version 1, block counter 1, usage 8001 for an initial key, AES-128, 128 bits, then the full initial key ID — and it yields the initial key 1273671E A26AC29A FA4D1084 127652A1.

Now take transaction 1. The device’s derivation key for that transaction is 4F21B565 BAD9835E 112B6465 635EAE44, and from it three working keys fall out, differing only in two bytes of input:

Note the last eight bytes: not the whole initial key ID but its low four bytes, 90123456, followed by the transaction counter 00000001. And note that the PIN key and the data key for the very same transaction are different keys. When this chapter said earlier that the card number and the PIN travel under separate keys, that is the arithmetic that makes it so.

The AES counter is 32 bits and, as in the TDEA scheme, only values with a limited number of set bits are used — up to sixteen one-bits rather than ten. That yields 2,448,023,842 usable transactions per device, which is the practical meaning of “the reader will not live to spend the book”.

The PIN block row is a migration trap in its own right. Format 4 is the AES format and is required with AES keys; a host expecting format 0 will decrypt an AES-era PIN block into rubbish and reject perfectly good PINs.

Why a different key every time#

State the threat model precisely, because “more keys is more secure” is not an argument.

An attacker with a year of a shop’s traffic holds a year of ciphertexts, each under a distinct key. No volume of traffic helps him: he cannot accumulate material under one key, and breaking one transaction gains him one transaction. With a single static terminal key — the arrangement DUKPT replaced — the same capture is one key away from a year of card numbers.

An attacker who steals a terminal and successfully extracts its live key state gains every future transaction of that terminal and no past ones, for the reason given earlier: the derivation runs one way. In practice extraction is what SRED’s tamper and side-channel requirements are there to prevent, and the commercial consequence of a suspected extraction is a re-injection, not an investigation.

An attacker inside the merchant’s network gains ciphertext plus KSNs. The KSN is not secret; it is an index. Publishing it is not a weakness, and in fact its counter is useful defensively: a host can detect duplicate KSNs, replayed transactions and impossible counter jumps, because the counter of a healthy device only ever increases.

The party with real exposure is the solution provider holding the BDK, which can regenerate any key of any device in its family from the KSN alone. Hence the requirements in Domain 5, and hence HSMs.

Key blocks, and why integrations broke in 2023 and 2025#

A key in transit needs its attributes bound to it. A bare 16-byte value carries no statement of what it is for, and a host that will use whatever it is sent as whatever it is told can be manipulated into using a PIN key as a data key, or a data key as a key-encrypting key. Key blocks solve this by encrypting the key together with a header that states its usage, algorithm, mode of use and exportability, and authenticating the whole structure.

The format that the payments industry standardised on was ANSI X9 TR-31, since superseded by ANSI X9.143-2022; the two are generally interoperable and the names are used interchangeably in vendor documentation. The key that protects a key block is a key block protection key (KBPK), distinct in principle from a plain key-encrypting key because it protects the header as well as the key.

Key blocks stopped being optional on a published timetable. PCI PIN Security Requirement 18-3 states that encrypted symmetric keys must be managed in key blocks, and the Council’s revision bulletin of 17 July 2020 fixed the phases as follows:

Those dates explain a decade of integration pain. Phase 2 broke host-to-network links that had exchanged variant-format keys for twenty years. Phase 3 pushed the same change out to terminal estates and merchant hosts, which is why perfectly functional readers were replaced in 2024 by suppliers who described the reason as “compliance” rather than explaining it.

Underneath sits the algorithm question. PCI’s requirements are expressed in terms of effective key strength, and double-length TDEA at 112 bits still satisfies them; NIST, in SP 800-131A Rev. 2, treats three-key TDEA encryption as deprecated through 2023 and disallowed thereafter. The practical result is a long overlap in which AES DUKPT and TDEA DUKPT coexist in the same estate, sometimes in the same shop, and every host must support both.

Key injection#

An initial key has to get into a device without ever existing in the clear where a person could read it. There are two accepted routes.

The first is a key injection facility: a physically secured room, assessed against the relevant domain requirements, where devices are connected to a key loading device driven by an HSM. Access is under dual control — no single person can perform a key operation — and the BDK components are held under split knowledge, so that no individual has enough material to reconstruct the key. Components are usually delivered as printed component sheets held by named custodians in tamper-evident envelopes, combined only inside the HSM during a witnessed and logged key ceremony.

The second is remote key distribution, in which the device authenticates itself cryptographically to a distribution host and receives its initial key over an untrusted network. The mechanism is asymmetric: ANSI X9.24-2 specifies the approach, and TR-34 is the protocol implementation used in practice, with a key distribution host and a key receiving device exchanging signed and enveloped material. The POI requirements insist on mutual authentication between host and device for remote key distribution, and the P2PE templates treat remote key distribution requirements as additional to the baseline. Remote injection is what makes it economically possible to ship a reader to a merchant by courier rather than through a depot.

Chain of custody is assessed as seriously as cryptography. Devices must be shipped with tamper-evident packaging, tracked by serial number, inspected on receipt against a manifest, and stored securely before deployment. A device whose whereabouts cannot be accounted for between the injection facility and the shop counter is, formally, an unknown device.

The decryption environment#

At the far point, decryption occurs inside a hardware security module. This is not an ordinary server with a cryptographic library: it is a tamper-responsive device that erases its secrets when opened, holds a local master key that never leaves it, and refuses to output the keys it protects. Payment HSMs are certified against the PCI PTS Hardware Security Module (HSM) Modular Security Requirements — v4.0 of December 2021 for most currently fielded units, with v5.0 published in May 2026 — and typically also against FIPS 140-3 (formerly 140-2) at Level 3 under the NIST validation programme. ISO 13491 covers secure cryptographic device requirements generally, and ISO 11568 covers retail key management, both of which the P2PE and PIN standards reference.

The properties that matter architecturally are simple to state and expensive to achieve. Clear-text account data exists only inside the HSM’s boundary. Keys are used, not read: the application asks the HSM to decrypt a block under the key derived from a given KSN, and receives plaintext, never the key. Key operations require dual control and are logged. The BDK exists in the clear nowhere.

In P2PE terms this is the Decryption Management Services function, assessed against Domain 4 with the shared key requirements of Domain 5. It is also the point at which the merchant’s scope reduction is paid for by somebody else’s scope: everything the merchant no longer has to protect, the solution provider protects instead, under audit, and prices accordingly.

Scope reduction, stated honestly#

The commercial case is real, and it is narrower than sales decks imply.

A merchant using a PCI-listed P2PE solution, and following the PIM, may validate using SAQ P2PE instead of the long self-assessment questionnaires or a full Report on Compliance. What remains is drawn chiefly from the physical-security and policy requirements: knowing which devices you have and where, checking them for tampering and substitution, controlling physical access to them, handling any paper records that carry card numbers, training staff, maintaining an incident response plan, and managing the third parties involved. What disappears is the mass of network, patching, malware, logging and segmentation requirements — not because they stopped being good ideas, but because there is no in-scope system in the shop for them to apply to.

Four conditions routinely destroy that position, and all four are common:

The solution must be listed, and listed for the specific device types and applications in use. A validated solution running an unlisted application on a listed device is not a validated solution.

The merchant must not have another route by which clear-text account data enters its systems. A shop with a beautiful P2PE estate on the counter and a member of staff typing telephone orders into a browser has a cardholder data environment again, and the browser is in it.

The PIM must be followed. It specifies device inspection frequency, permitted device configurations, what to do about a suspected tamper, and how devices must be shipped and stored. Ignoring it is not a technical failure; it is loss of eligibility.

Encrypted account data that the merchant stores is out of scope only if the merchant genuinely has no means of decrypting it. A merchant who holds ciphertext and also holds, anywhere, the key or the decryption service is back in scope for that data.

For non-listed solutions, the Council’s Assessment Guidance for Non-listed Encryption Solutions (June 2020) sets out how a QSA documents the solution’s effect so that the acquirer can decide what scope reduction to accept. This route is widely used and perfectly respectable. It is simply not the same product, and it does not entitle a merchant to SAQ P2PE.

Tokenisation at the acquirer versus encryption in the terminal#

These are complementary mechanisms that solve different problems, and the confusion between them causes real architectural mistakes.

Encryption in the terminal protects a card number in flight, from capture to decryption, and produces a value that changes on every transaction. Tokenisation replaces a card number with a surrogate that persists, so it can be stored, quoted, refunded against and billed again.

There are three distinct kinds of token in payments, and only one of them belongs in this chapter. Acquirer or gateway tokens are issued by the merchant’s acquirer or gateway after decryption: the vault stores the PAN, returns a surrogate, and the merchant stores the surrogate. EMVCo payment tokens are network tokens, issued by a token service provider, with their own device and domain controls, covered in the chapter on the token in your phone. Device-generated surrogate PANs are produced inside the POI itself, under the SRED requirements quoted earlier, and are useful for local matching where the merchant needs no server round trip.

The right architecture for a merchant that needs both is a listed P2PE solution for capture and an acquirer token returned in the authorisation response for storage. The terminal sends ciphertext plus KSN; the provider decrypts, authorises, and returns a token; the merchant stores the token and never the number. Refunds, subscriptions and analytics all run on the token.

Two cautions. A token a thief can present for payment without further authentication has merely moved the value rather than removed it, which is why tokens are scoped to one merchant and one channel. And format-preserving tokens that pass the Luhn check are convenient for legacy software and treacherous for governance, because nothing in a schema distinguishes them from real card numbers.

What actually goes on the wire#

The encrypted blob does not travel on the card networks. It travels from the terminal to the decrypting party over that party’s own protocol, and it dies there.

A typical terminal-to-host request carries the ciphertext as a hexadecimal or base64 string, the KSN in the clear, an indication of the encryption scheme and format in use, a masked PAN, the expiry if the solution exposes it, and the ordinary transaction fields — amount, currency, the EMV data from the chip. The host passes the ciphertext and KSN to its HSM, which derives the transaction key from the BDK and the KSN, decrypts inside its boundary, and returns the account data.

Only then does the message the rest of this book is about get built. The clear PAN goes into the ISO 8583 primary account number field, DE 2; track data, where present, into DE 35 or DE 45; the PIN block, encrypted under a different key and translated by the HSM from the terminal’s key to the acquirer’s working key, into DE 52, with key management data in DE 53. The scheme never sees the P2PE ciphertext, has no knowledge of the BDK, and cannot tell from the authorisation message whether the merchant’s terminal was encrypting or not. That handoff is the subject of the next chapter.

A short field guide to failures#

Key or KSN mismatch. Decryption returns plausible-length rubbish. Almost always the host has been configured with the wrong BDK for that key set ID, or the KSN is being parsed with the wrong field boundaries. Check the key check value of the BDK before suspecting anything subtle.

Counter exhaustion. A device that has quietly reached the end of its counter stops encrypting. It is not broken; it needs re-injection. On TDEA devices this is reachable inside a decade at high volume.

Format assumptions. An AES-era device sending an ISO 9564-1 format 4 PIN block to a host expecting format 0 produces PIN verification failures that look like customer error. The same class of fault arises when a host assumes the encrypted field includes the expiry and it does not.

Key block version mismatch. A host that only accepts one key block format will reject an otherwise valid key. This is the ordinary consequence of the 2023 and 2025 phases arriving at different times in different estates.

Tamper trips in transit. Tamper-responsive devices sometimes respond to being dropped, frozen or X-rayed. A device that arrives dead has done its job.

Silent loss of eligibility. The most expensive failure has no error message. Somebody installs an unlisted application, or starts keying card numbers into the back office, or stops doing the device inspections the PIM requires, and the shop stays fully functional while its right to the short questionnaire lapses. This is discovered at the next assessment, or after a breach.

The through-line of this chapter is that none of the cryptography here exists to protect the merchant from the merchant’s enemies. It exists to remove the merchant from the problem entirely. A shop that cannot read card numbers cannot leak them, cannot be socially engineered out of them, and cannot be sued for them, and that is a stronger security property than any amount of diligence in a shop that can.

21.98 Common wrong ideas#

Wrong: an encrypting reader means nothing readable leaves the sealed box. Right: almost every deployment deliberately emits the first six or eight digits and the last four in clear, and many emit the expiry date and cardholder name too, because the till cannot route, surcharge or print a receipt otherwise.

Wrong: “our terminals encrypt end to end” means the merchant qualifies for SAQ P2PE. Right: the short questionnaire is available only where the whole arrangement has been assessed against the P2PE Standard and published on the Council’s list; anything else is a non-listed encryption solution, and how much scope reduction it earns is the acquirer’s decision, not the merchant’s.

Wrong: the card number and the PIN are protected by the same key. Right: they are two separate encrypted blocks under keys derived for different usages, with different formats and different rulebooks, which is why compromising the account-data key does not hand over PINs.

Wrong: per-transaction keys mean every transaction is sealed off from every other. Right: derivation runs one way only, so an attacker who extracts a device’s live state cannot compute yesterday’s keys but can compute every future one until the device is re-injected.

Wrong: the far point of point-to-point encryption is the merchant’s bank. Right: the decrypting box normally belongs to whoever runs the scheme — a gateway, a processor, a terminal estate manager — and the acquirer may be a further hop away and never see the encrypted form at all.

Wrong: encryption and tokenisation are two names for the same protection. Right: encryption protects data in flight and produces a value that changes on every transaction; tokenisation replaces the number at rest with a stable surrogate that can be stored, refunded against and billed again.

Wrong: a PCI-approved terminal is an encrypting terminal. Right: the encryption requirements live in Evaluation Module 4, SRED, which is optional; a device can be PTS approved without it, which is why terminal estates contain both kinds.

Wrong: the key serial number has to be kept secret. Right: it is an index, not a key, and its counter is defensively useful, because a healthy device’s counter only ever increases and duplicates or impossible jumps are detectable.

Wrong: storing only encrypted account data always keeps a merchant out of scope. Right: it does so only if the merchant genuinely has no means of decrypting it; a merchant holding ciphertext and also holding, anywhere, the key or the decryption service is back in scope for that data.

Wrong: a card reader that arrives dead was badly made. Right: tamper-responsive devices respond to being dropped, frozen or X-rayed, and a device that erased itself in transit has done exactly its job.

21.99 Chapter summary in 20 lines#

1. A card reader that arrives from the supplier already loaded with a secret turns every card number into unreadable ciphertext before the shop’s own software is allowed near it.
2. There are exactly two places in the story where readable account data exists — inside the reader and inside the decrypting party’s hardware security module — and neither of them is in the shop.
3. The product being bought is not the cryptography but the scope reduction: a merchant that cannot read card numbers answers a short questionnaire instead of the full PCI DSS regime.
4. The reader uses a different key for every transaction, destroys each key after use, and sends a non-secret key serial number so the far end can reconstruct the key it needs.
5. The plain version overstates the protection, because most solutions return the BIN and last four digits in clear, and often the expiry and the cardholder name as well.
6. Card data and PIN travel as two encrypted blocks under keys of different usages, so a compromise of the account-data key does not surrender PINs.
7. P2PE with a capital P is a PCI Security Standards Council programme with a standard, an assessor qualification, reporting templates and a public list, not a generic description of engineering.
8. The programme defines a solution, an application, a component and a solution provider, and the provider retains overall responsibility however much of the work it outsources.
9. Five domains carry the requirements — encryption, application, solution management, decryption and key management — with key management shared between the encrypting and decrypting sides.
10. The encryption itself is specified in SRED, which demands unique keys per device, approved algorithms, no path by which clear-text account data can leave, and resistance to side channels as well as screwdrivers.
11. What must be protected is account data, not merely the PAN, and sensitive authentication data must not be retained after authorisation at all, encrypted or otherwise.
12. DUKPT makes per-transaction keys practical without a network round trip, deriving every key of every device from a base derivation key that exists only inside the provider’s HSMs.
13. The TDEA scheme uses a ten-byte KSN and yields 1,048,575 usable transactions; the AES scheme uses twelve bytes and yields 2,448,023,842, because both counters are limited by how many bits may be set rather than by their width.
14. Derivation is irreversible, so a compromised device leaks its future traffic and not its past, and the commercial consequence of a suspected extraction is a re-injection rather than an investigation.
15. Key blocks bind a key’s usage, algorithm and mode to the key itself, and the phased mandate of PIN Security Requirement 18-3 in 2019, 2023 and 2025 explains a decade of integration pain.
16. Initial keys reach devices either through a physically secured injection facility under dual control and split knowledge, or by remote key distribution with mutual authentication over an untrusted network.
17. Decryption happens inside a tamper-responsive HSM that uses keys without ever revealing them, and everything the merchant no longer has to protect the solution provider protects instead, under audit and for a price.
18. Four things routinely destroy the scope reduction: an unlisted application, another route by which clear-text card numbers enter the merchant’s systems, deviation from the P2PE Instruction Manual, and holding both ciphertext and the means to decrypt it.
19. Encryption and tokenisation are complementary rather than competing, and the right architecture is a listed solution for capture with an acquirer token returned for storage, so that refunds, subscriptions and analytics all run on the token.
20. None of this cryptography protects the merchant from the merchant’s enemies; it removes the merchant from the problem, and a shop that cannot read card numbers cannot leak them, cannot be socially engineered out of them, and cannot be sued for them.

Sources: PCI Security Standards Council document library, including the PCI Point-to-Point Encryption Standard v3.2 (June 2025) and its summary of changes, the P2PE Program Guide v3.2, the P2PE v3.x Technical FAQs, the P2PE Solution, EMS, DMS, KMS, Application and MMS P-ROV templates, the P2PE Instruction Manual and Attestation of Validation templates, “Securing Account Data with the PCI Point-to-Point Encryption Standard v3” (July 2020), and the Assessment Guidance for Non-listed Encryption Solutions (June 2020); PCI PIN Transaction Security Point of Interaction Modular Security Requirements, Evaluation Module 4 (Secure Reading and Exchange of Data) and its section K, with version history to v7.0 (May 2025); PCI PTS Hardware Security Module Modular Security Requirements v4.0 (December 2021) and v5.0 (May 2026); PCI DSS v4.0.1 Requirements 3.3.1, 3.4.1 and 3.5.1; PCI SSC “Revisions to the Implementation Date for PCI PIN Security Requirement 18-3” (17 July 2020) and the PIN Security Requirement 18-3 Key Blocks information supplement; ANSI X9.24-1 and ANSI X9.24-3-2017, with the Supplement to ANSI X9.24-3-2017 Test Vectors published by the Accredited Standards Committee X9 for the derivation data, key usage indicators and worked key values; ANSI X9.143-2022 and ANSI X9 TR-31 for key blocks; ANSI X9.24-2 and TR-34 for asymmetric key distribution; ISO 9564-1, ISO 11568 and ISO 13491; NIST SP 800-131A Rev. 2 and the FIPS 140-3 validation programme; AWS Payment Cryptography industry terminology documentation for KSN field layouts and key type naming; IBM z/OS and Linux on Z cryptographic services documentation for the X9.24 transaction counter behaviour.