Payment HSMs: How They Protect PINs, Card Keys and Key Exchange

A payment hardware security module (payment HSM) is a tamper-resistant device that performs the cryptography behind card payments, such as PIN translation, card verification value checks and key exchange, so that PINs and payment keys never appear in clear outside certified hardware. Every issuer, acquirer, processor and payment network relies on them, and the rules that govern them (PCI PTS HSM for the device, PCI PIN Security for how it is used) are stricter than for general-purpose HSMs. This guide explains what a payment HSM does, how keys move between parties using TR-31 key blocks and TR-34, what changed with the PCI key block requirement, and how cloud payment HSM services differ from owning the hardware. It is for security architects, payment engineers, assessors and buyers; general HSM operations are covered in the HSM Deployment and Operations Guide.

Key takeaways

• Payment HSMs are a separate class of device. They run payment-specific command sets (PIN, CVV, EMV cryptogram, MAC) and are approved against the PCI PTS HSM standard, not just FIPS 140.
• Key blocks are now the rule. PCI PIN Security Requirement 18-3 requires encrypted symmetric keys to be managed in key blocks that cryptographically bind each key to its permitted use, with the final phase dated 1 January 2025.
• Usage binding stops key misuse attacks. A TR-31 header fixes what a key may do (for example base derivation, card verification, key wrapping) and whether it may be exported; changes can only make it more restrictive.
• Cloud options split into two models. Some services give you a dedicated physical payment HSM you administer; others expose payment cryptography as a managed API where you never touch the device.
• The device is only part of compliance. PCI PIN assessments look at key ceremonies, dual control, split knowledge, logging and the applications calling the HSM, which remain your responsibility in every model.

What it is

A payment HSM is a hardened cryptographic appliance with physical tamper detection that erases (zeroises) keys if attacked. It holds a master key, often called the local master key, and protects every other working key either inside the device or encrypted under that master key in a host database. Applications send commands such as "translate this PIN block from the terminal key to the network key" and receive results, never clear keys or clear PINs.

The PCI Security Standards Council (PCI SSC) maintains the PTS HSM standard, which sets security requirements for HSM characteristics and lifecycle up to initial deployment, and also covers remote administration platforms, key loading devices and multi-tenant HSMs used at cloud service providers. Devices are evaluated by PCI-recognised laboratories, and PCI SSC publishes an Approved PTS Devices listing that buyers are encouraged to use. Separately, the PCI PIN Security Requirements govern how acquirers and their agents manage, process and transmit PINs and keys; Qualified PIN Assessors assess compliance, and the payment brands decide who must validate.

How it works

The key hierarchy

• Master key: created in the HSM during a key ceremony, usually from components held by different custodians under dual control and split knowledge, so no single person ever knows the full key.
• Key encryption keys (KEKs): shared with a partner such as a card network or processor, used only to protect other keys in transit. In TR-31 terms the key that protects a key block is the key block protection key (KBPK, usage K1).
• Working keys: PIN encryption keys, card verification keys (usage C0), MAC keys and base derivation keys (usage B0) used to derive unique per-transaction keys for terminals under DUKPT.

A PIN transaction in outline

1. The terminal encrypts the PIN block under a key unique to that terminal or transaction.
2. The acquirer's HSM translates the PIN block from the terminal key to the key shared with the card network, inside the device.
3. The network's HSM translates it again to the issuer's key.
4. The issuer's HSM verifies the PIN and validates the card's EMV cryptogram (ARQC) and, for card-not-present payments, the CVV2.

At no point does the clear PIN leave HSM hardware. AWS describes its PIN translation feature in the same terms: sensitive data moves between keys without exposing clear text, in line with PCI PIN rules.

TR-31 key blocks and Requirement 18-3

Older systems exchanged keys as bare encrypted values. Nothing stopped a key meant for one purpose being used for another, for example a key encryption key being used to decrypt data, which is a classic route to exposing keys. PCI PIN Requirement 18-3 requires encrypted symmetric keys to be managed in key blocks, with key usage cryptographically bound so that a key cannot feasibly be used if its attributes are altered.

A TR-31 (ANSI X9.143) key block has a clear header, the encrypted key, and a MAC that protects both. The header fields include:

According to AWS documentation, header changes on export can only be more restrictive: a key can lose its verify permission or become non-exportable, but a non-exportable key can never become exportable. The KBPK must be at least as strong as the key it protects. Key check values (KCVs) confirm both sides hold the same key, but they are a validation aid, not integrity protection; the key block MAC provides integrity.

Timeline: PCI SSC set Phase 1 (internal connections and key storage in service provider environments) at 1 June 2019. PCI SSC revised the later phases in 2020 (its August 2020 key block bulletin for P2PE states the same dates, and a Visa bulletin reports the PIN revision): Phase 2 (external connections to associations and networks) moved to 1 January 2023 and Phase 3 (merchant hosts, point of sale devices and ATMs) to 1 January 2025. Confirm current expectations with your payment brands and assessor.

Exchanging key encryption keys

Partners usually establish a KEK first, then move every other key under TR-31. The options documented for one cloud service show the trade-offs:

• TR-34: RSA-based distribution with signed payloads and certificates, replacing paper key components and courier ceremonies.
• ECDH key agreement: derives a one-time KEK from ephemeral keys; both sides must use exactly the same derivation parameters.
• RSA wrap: simpler, but without payload signing or key block metadata integrity, so weaker.
• Physical exchange: key components on paper or smart cards carried by custodians, still used where partners cannot do electronic exchange.

Why it matters

PINs and card keys are high value. A leaked card verification key lets an attacker generate valid CVVs; a leaked base derivation key compromises every terminal derived from it; a misused KEK can expose all keys shared with a partner. Payment HSMs, and the PCI PIN rules that govern how they are used, exist to make those failures improbable.

Choosing a deployment model

Cloud services are listed alphabetically.

Availability: AWS states the service is designed to meet PCI PIN, PCI P2PE and PCI DSS requirements; Microsoft states its data centres housing Payment HSM are PCI DSS and PCI 3DS compliant and that the service can form part of a validated PCI P2PE or PCI PIN solution. Microsoft also offers a separate Azure Payment HSM v2 service based on a different HSM family. Check each provider's current attestations before relying on them for an assessment.

Smaller merchants rarely run payment HSMs at all: their processor or payment gateway does, and their job is to choose a provider with the right attestations and keep keys out of their own systems. Issuers and processors need the full programme below.

Implementing or migrating

1. Inventory keys and connections: list every key, its usage, where it is stored, which partner shares it and whether it is already in TR-31 form.
2. Agree formats with partners: confirm key block versions and KEK exchange method (TR-34, ECDH or physical) with each network and processor.
3. Run a parallel environment: stand up the new HSMs or cloud service and test every command against known test vectors before cut-over.
4. Migrate keys under ceremony: import KEKs, then working keys under TR-31, checking KCVs on both sides and recording custodians and witnesses.
5. Cut over by connection: move one partner or terminal estate at a time, keeping the old path available until transaction success rates match.
6. Retire safely: zeroise old devices and destroy old key components, with evidence for your assessor.

What to monitor

• Command error rates: spikes in PIN verification or translation failures can indicate key mismatch or attack.
• Key usage outside expected applications: calls from unexpected hosts or roles.
• Administrative events: master key loads, user and role changes, firmware updates and tamper alerts.
• Metrics: share of keys held as TR-31 key blocks (target 100%), keys past their crypto-period, open audit findings from PIN assessments, and capacity headroom in transactions per second.

Common misconceptions

• "FIPS 140 is enough": FIPS validation does not demonstrate PCI PTS HSM approval or payment command controls. Check the PCI listing for the exact model and firmware.
• "A cloud service makes us PCI PIN compliant": providers cover the device and their facility; your key management processes, access control and applications are still assessed.
• "Key check values prove integrity": a KCV only shows two parties hold the same key. Integrity comes from the key block MAC.
• "Exportable keys are convenient": marking keys exportable by default widens the blast radius. Set non-exportable unless a documented need exists.
• "The HSM protects the API that calls it": an attacker with access to an authorised application or cloud role can still ask the HSM to verify or translate. Protect the identities that call payment cryptography as tightly as the keys.

Related concepts

• Identities that call the HSM: host applications, service accounts and cloud roles are non-human identities with powerful rights; scope them per key and per operation, and review them as privileged access. See the Cryptographic Key Management Guide.
• General HSM operations: see the HSM Deployment and Operations Guide and the FIPS 140-3 and Cryptographic Module Validation Guide.
• Card data outside the HSM: PCI DSS governs stored card data and the environment around the HSM. See the PCI DSS 4.0 Guide.
• Tokenisation: network tokens reduce where card numbers live. See the Network Tokenisation for Payments Guide.

Practitioner checklist

• Confirm every payment HSM model and firmware version appears on the PCI Approved PTS Devices listing.
• Hold every encrypted symmetric key as a TR-31 or equivalent key block, and track any exceptions with a date.
• Set keys non-exportable by default and restrict mode of use to the minimum.
• Prefer TR-34 or ECDH over RSA wrap or paper components for KEK exchange where partners support it.
• Run key ceremonies under dual control and split knowledge with recorded custodians, witnesses and KCV checks.
• Scope the applications, service accounts and cloud roles that can call payment cryptography, per key and per operation.
• Monitor command errors, administrative events and tamper alerts, and feed them to the SOC.
• For cloud services, map your responsibilities against the provider's attestations before the next PCI PIN assessment.

Standards and references

• PCI Security Standards Council: PIN Security Standard
• PCI Security Standards Council: PIN Transaction Security (PTS) standards
• PCI Security Standards Council: Guidance for PIN Security Requirement 18-3 Key Blocks
• PCI Security Standards Council: Key Block Implementation Bulletin (P2PE), August 2020
• Visa: Security bulletin, PCI extends key block dates
• AWS: What is AWS Payment Cryptography
• AWS: Export keys (TR-31, TR-34 and ECDH)
• Microsoft Learn: What is Azure Payment HSM

Related NHI Mgmt Group resources: Encryption Guide · HSM Deployment and Operations Guide · Cryptographic Key Management Guide · PCI DSS 4.0 Guide