ISO Compliance Insights & Best Practices
CART
ISO Compliance Insights & Best Practices
PCI PIN key blocks are the structure that cryptographically binds a key’s permitted usage to the key itself, so a key issued for one purpose cannot quietly be used for another. Requirement 18-3 of the PIN standard mandates them, and it does so on a three-phase timetable that finished on 1 January 2025.
All three phases are now in the past. What is still very much live is the confusion about what Phase 3 actually required — and a great deal of published material gets it wrong in a direction that costs money.
An encrypted key on its own is just ciphertext. Nothing about it says what it is for, so a key intended to encrypt PINs can be presented to a device as a key-encryption key, and the device has no way to object. That substitution is the attack the requirement exists to close.
PCI PIN key blocks solve it by binding usage attributes to the key cryptographically, so that altering the attributes invalidates the block. The standard names three acceptable ways of achieving that integrity binding: a message authentication code computed over the clear attributes together with the enciphered key, a digital signature over the same data, or an integrity check implicit in the key-encryption process itself.
| Phase | Scope | Effective date |
|---|---|---|
| Phase 1 | Internal connections and key storage within service provider environments, including applications and databases connected to hardware security modules | 1 June 2019 |
| Phase 2 | External connections to associations and networks | 1 January 2023 |
| Phase 3 | All merchant hosts, point-of-sale devices and ATMs | 1 January 2025 |
Each phase of PCI PIN key blocks was estimated at roughly 24 months after the one before it. There is no Phase 4, and no further key block date has been announced.
This is the part that matters commercially, and it is the part most often reported incorrectly.
Existing POI deployments were not required to convert. PCI SSC addressed this directly in its technical FAQs: deployments of point-of-interaction devices that existed before the Phase 3 date are not required to convert to PCI PIN key blocks, although they may choose to. New deployments must.
Read that carefully, because the difference is enormous. A processor with 40,000 terminals in the field did not have a project to retrofit 40,000 terminals. It had an obligation to ensure that everything deployed from January 2025 onward implements key blocks, and a choice about the existing estate.
A programme built on the assumption that the whole estate had to convert produces months of work that was never required, and it also produces the wrong risk conversation with the business. The right question is not “how fast can we convert everything” but “which population is each of our connections and estates actually in”.
New deployments implement PCI PIN key blocks, and PCI SSC’s FAQ gives two worked cases of what that means in practice:
The first of those has a practical consequence worth planning for: the decision about PCI PIN key blocks has to be made at the point a device is injected, not later. If a device leaves a key-injection facility without the key block protection keys it needs, retrofitting them means bringing the device back.
Three places account for most of the gaps found at assessment, and none of them is the terminal estate everyone worries about.
Internal application-to-HSM connections. Phase 1 closed in June 2019 and covered exactly this: applications and databases connected to hardware security modules inside a service provider environment. It is the oldest obligation and the one most likely to sit in legacy middleware nobody has opened since.
Host-to-host links with parties that are neither an association nor a network. Phase 2 is usually read as covering the card networks. PCI SSC’s FAQ guidance treats organisation-to-organisation links — for example between a processor and a third-party key-injection service provider — as falling within the Phase 3 sunrise. Those links get missed because they do not look like the connections either phase seemed to describe.
Session key updates after deployment. A device can be injected correctly and still fail, if the key block protection keys needed to update session keys were never established at injection. That is a defect created at the facility and discovered in the field.
The standard’s own technical reference names ASC X9 TR-31 as an example of an acceptable method. The supporting material and PCI SSC’s later FAQ guidance refer to ANSI X9.143, which is TR-31’s successor.
Both names appear in current PCI material, and the practical instruction is the same either way: record which specification each of your implementations actually uses, by name and version. “We use key blocks” is not an answer an assessor can test. A vendor’s description of its own proprietary format is not sufficient either, unless it maps to one of the accepted integrity-binding methods above.
Because the obligation differs by population, the artefact an assessor wants is a register rather than a statement. For every connection, host and device population, record:
That last point is a control in its own right. A key block whose attributes permit more than the key’s declared purpose weakens exactly the protection the block exists to provide, so the attributes should be checked against the key inventory rather than assumed correct.
Expect the conversation to start with populations rather than technology. A Qualified PIN Assessor will want to know how many distinct connections, hosts and device estates you have, which phase each falls under, and how you established that — because the answer determines what they need to test.
From there the questions get concrete. Which specification does this implementation use? Show me the usage attributes set on a key, and show me the same key’s declared purpose in the inventory. For a device deployed after January 2025, show me that key blocks were implemented. For one deployed before, show me the recorded decision that conversion was not required.
That last one catches people out. Choosing not to convert an existing estate is a legitimate position, but it is a decision, and an undocumented decision is indistinguishable from an oversight.
Requirement 18-3 sits in Control Objective 5, which covers preventing and detecting unauthorised key usage. It works alongside Requirement 19, which binds every key to a single purpose, and Requirement 20, which requires unique keys per device.
PCI PIN key blocks are the mechanism that makes Requirement 19 enforceable rather than merely stated. Without them, “this key is only for PIN encryption” is a line in a register; with them, it is a property of the key. Our guide to the PCI PIN Security Requirements sets out how the seven control objectives fit together, and PCI PIN vs PCI DSS covers which of the two standards applies to you.
Where devices are keyed at a facility, the key block protection keys have to be established at injection — see key injection facilities — and PCI PIN scope determines whether Annex B applies to you at all.
No. Deployments that existed before 1 January 2025 are not required to convert, though you may choose to. New deployments must implement them.
No. The standard sets three phases, all now past, and no further key block date has been announced.
X9.143 is the successor to TR-31 and both names appear in current PCI material. What matters for an assessment is recording which one each implementation actually uses, by name and version, rather than describing your position as “key blocks” generically.
In PCI PIN Security Requirements and Testing Procedures v3.1, free to download from PCI SSC’s document library after accepting their licence. There is also a dedicated information supplement on key blocks in the same library.
Evidencing PCI PIN key blocks means holding a migration register that distinguishes the populations that had to convert from the ones that never did, and a key inventory whose declared purposes match the usage attributes actually set. Neither is something a standard hands you.
Our PCI PIN Security Toolkit ships a Key Block Implementation Standard and a Key Block Migration Plan and Status Register among its 149 templates, both written to the position set out above — including the fact that Phase 3 never retrofitted anything. The pack covers all 145 sub-requirements across all four scope columns.
September 8, 2026
September 8, 2026
September 8, 2026
September 8, 2026
September 8, 2026