Payment HSMs: Meeting DORA, PCI DSS and FIPS 140-3

Few sectors carry as much cryptographic weight as financial services. Every card transaction, every real-time payment, every API call between a bank and a fintech depends on keys being generated, stored and used in a way that no attacker, and no insider, can compromise.

The foundation for that is the hardware security module — but not just any HSM. Payments has its own category of device, its own certification regime and its own set of operations, and the distinction between a general purpose HSM and a payment HSM is the first thing worth getting right.

This article covers what makes a payment HSM different, what the frameworks now expect, and how to bring them into your estate without creating new operational risk.

Payment HSM or general purpose HSM?

This is the question that most often gets answered wrongly, usually by assuming an HSM is an HSM.

A general purpose HSM protects keys and performs cryptographic operations for applications: signing, encryption, key wrapping, certificate authority operations. It exposes standard interfaces such as PKCS#11, JCE or CNG, and the application decides what to do with the results. Thales Luna, Entrust nShield and Fortanix DSM sit in this category.

A payment HSM does something different. It implements payment-specific functions natively, inside the security boundary, and it refuses to do anything else. PIN block translation, PIN verification, card verification value generation, EMV cryptogram processing and key exchange under payment scheme rules are all built in as commands rather than assembled by the calling application.

That constraint is the point. In a payment HSM, a PIN never exists in the clear outside the device, and the device will not perform an operation that would allow it to. The restricted command set is a security property, not a limitation.

Why the distinction matters commercially

• Certification differs. Payment HSMs are certified under PCI PTS HSM. General purpose HSMs are typically validated to FIPS 140-3 and Common Criteria. These are different schemes assessing different things, and one does not substitute for the other.
• Scheme compliance depends on it. Card scheme and PCI PIN requirements assume the payment HSM command set. Attempting to build equivalent functions on a general purpose device creates an assurance gap that is difficult to close in front of an assessor.
• Cost and throughput differ substantially. Payment HSMs are typically more expensive per unit and are sized around transaction throughput rather than general cryptographic operations.
• Most institutions need both. Payment HSMs for the payment estate, general purpose HSMs for PKI, code signing, database encryption and everything else. Treating them as one procurement is a common and expensive mistake.

What payment HSMs actually do

The command set reflects the operations the payment ecosystem depends on.

• PIN translation. A PIN entered at a terminal is encrypted under one key and must reach the issuer encrypted under another. The HSM decrypts and re-encrypts inside the boundary, so the PIN never appears in the clear on any host.
• PIN verification. Validating a PIN against a stored offset or verification value without exposing either.
• Card verification. Generating and validating CVV, CVC and equivalent values.
• EMV processing. Application cryptogram generation and verification, script generation for post-issuance card updates, and the key derivation the EMV specifications require.
• Card and credential personalisation. Deriving the card-unique keys written to chips during manufacture, and the equivalent for tokenised and mobile credentials.
• Key exchange and management. Generating, wrapping and exchanging the zone and terminal keys shared between acquirers, issuers, processors and schemes, under the formats the schemes mandate.

Every one of these operations concentrates risk in a small number of keys. Compromise a zone master key or an issuer master key and the damage is not limited to one transaction — it undermines trust across a scheme.

What the frameworks expect

PCI PTS HSM requirements

The PCI Security Standards Council maintains a dedicated approval programme for payment HSMs. The PCI HSM security requirements cover physical security, logical security, device management and the security of the manufacturing and delivery chain, and approved devices are listed publicly.

For any organisation handling PINs, deploying a device that meets the PCI PTS HSM requirements is the baseline expectation rather than a differentiator. A PCI PIN assessment will ask, and the approval list is public.

Version currency matters here. A device approved under an earlier version of the requirements is not automatically compliant with the current one, and this is a common finding in estates that have run without change for several years.

PCI PIN and key blocks

PCI PIN Security Requirement 18-3 mandates that encrypted symmetric keys are managed in key blocks, with the key's permitted usage cryptographically bound to the key itself. The practical effect is that a key cannot be substituted or repurposed without detection — which is exactly the attack the requirement exists to prevent.

The reference implementation is the ANSI X9 TR-31 key block format, with TR-34 covering remote key distribution to terminals and ATMs. TR-31 key blocks come in several version identifiers; version A is deprecated and should not be used in new implementations.

The requirement was introduced in phases: internal connections and service provider environments first, then external connections to schemes and networks, then extension to merchant hosts, POS devices and ATMs. All three phases are now in force.

If your estate still exchanges keys as bare cryptograms rather than key blocks, that is a live PCI PIN audit finding. Remediation usually means both HSM firmware currency and application changes, because applications that construct or parse key cryptograms directly have to be re-architected to handle key blocks.

FIPS 140-3 and PCI DSS

FIPS 140-3 has become the reference point for the assurance level of a cryptographic module generally. Where an institution can point to a FIPS 140-3 validated HSM at the appropriate level, it shortens the distance between a control claim and the evidence an auditor wants.

PCI DSS HSM requirements operate alongside this. DSS treats dedicated cryptographic hardware as the expected control for protecting cardholder data and the keys securing it, particularly around key generation, storage and the prevention of clear-text key exposure.

For payments, FIPS validation and PCI PTS HSM approval answer different questions and most serious deployments hold both. FIPS speaks to the cryptographic module; PCI speaks to its suitability for PIN and payment operations specifically. Neither substitutes for the other in an assessment.

DORA and operational resilience

The Digital Operational Resilience Act places cryptographic key management squarely within the resilience conversation. Institutions are expected to understand where their keys live, how they are protected, and how quickly they could recover if a cryptographic component failed.

That last point is the one payment teams most often underestimate. An HSM that cannot be recovered, or whose recovery depends on a key ceremony nobody has rehearsed, is a resilience finding regardless of how well it protects keys day to day. DORA also brings third-party dependency into scope, which matters for HSM-as-a-service arrangements.

Why software-only key handling struggles

Software libraries are flexible and convenient, which is precisely why they are difficult to assure at the level regulated payments demand.

Keys held in memory can be exposed through application flaws, misconfiguration or privileged access. Separation of duties is harder to enforce when an administrator with sufficient access can read process memory. And when an assessor asks for proof that a key has never existed in plaintext outside a protected boundary, a software-only architecture rarely has a clean answer.

An HSM changes the shape of that conversation. Keys are generated and used inside the device, access is controlled and recorded, and the assurance posture is backed by independent certification rather than internal assertion. For PIN operations specifically, it is not really an architectural choice — the scheme rules assume it.

The payment HSM market

The payment HSM market is considerably more concentrated than the general purpose one.

• Thales payShield is the most widely deployed platform, particularly among established acquirers and issuers. The payShield 10K is the current generation; payShield 9000 estates are now well past end of sale and migration off them is a recurring piece of work.
• Futurex Excrypt covers payment and general purpose operations across a single architecture, with VirtuCrypt providing the cloud-delivered equivalent.
• Utimaco Atalla continues the Atalla HSM line, long established in PIN and key management.
• Cloud payment HSM services including Azure Payment HSM and vendor-operated equivalents now offer PCI-compliant capacity without the data centre footprint. The compliance boundary, key custody, single-tenancy arrangements and exit provisions all warrant close examination before committing, and DORA brings third-party dependency explicitly into scope.

A note on migration. Moving between payment HSM platforms is more involved than a like-for-like hardware swap, because key hierarchies, host command sets and key block formats differ between vendors. Where an estate is coming off end-of-life hardware, the migration design matters more than the device selection.

We work with the leading vendors across both categories and hold no reseller allegiance. See our hardware security modules service for how we approach selection and integration.

Bringing payment HSMs into your estate without adding risk

Introducing HSMs is an architectural exercise, not a procurement one. The common failure mode is to buy capable hardware and then under-design how it is integrated, leaving keys protected in theory but operationally fragile in practice.

A measured approach addresses several questions in order.

Where do your most sensitive keys live today, and what protects them?

An estate-wide view is the prerequisite for any sensible design. In payments this extends beyond the obvious: zone keys shared with schemes, terminal master keys, issuer master keys, personalisation keys and the working keys derived from all of them. A cryptographic bill of materials is how that picture gets built and maintained.

Which keys genuinely require payment HSM protection, and at what level?

Not every key warrants the same treatment. PIN-related keys are non-negotiable. Others may be appropriately served by general purpose hardware at lower cost. Over-engineering wastes budget that would be better spent on resilience.

How will applications consume the HSM, and what happens if it is unavailable?

Payment HSMs are usually deployed in pairs or clusters for a reason. Resilience and recovery have to be designed in, including what happens during firmware upgrade, how failover behaves mid-transaction, and whether your throughput headroom survives losing a device at peak.

How are the HSMs operated?

Key ceremonies, dual control, split knowledge, access control and audit. The strongest device is only as good as the procedures around it, and PCI PIN is explicit about dual control and split knowledge as mandatory practices rather than good ones.

What is your firmware and certification currency position?

Devices approved under older PCI PTS HSM versions do not necessarily meet current requirements, and firmware that has fallen behind can quietly invalidate an assurance claim. This is one of the more common findings in payment estates that have been stable for several years.

Looking ahead: post-quantum in payments

Payments has an unusual exposure profile. Cards issued today remain in circulation for several years, terminals and ATMs stay in service considerably longer, and the key hierarchies underpinning them were designed to be stable.

The good news is that the bulk of payment cryptography is symmetric — 3DES and AES for PIN and key management — and symmetric algorithms are far less affected by quantum computing. The exposure sits in the asymmetric components: RSA in EMV offline data authentication, certificate-based scheme interfaces, and remote key distribution under TR-34.

The practical implication is that payment HSM procurement decisions made now should include questions about post-quantum algorithm support and firmware upgradability, in the same way that crypto-agility belongs in every other cryptographic procurement. Devices bought today will still be in service when those algorithms need to change.

How Unsung helps

We approach HSM work as a vendor-neutral exercise. We help institutions design and integrate hardware security modules as part of a coherent trust architecture, rather than treating the device as a standalone purchase.

That covers estate assessment, device selection against actual requirements, integration design, key ceremony procedure, migration from legacy or end-of-life platforms, and the operational model that keeps the assurance position current.

Our consultants hold SC and DV clearance and work across financial services, government, defence and critical national infrastructure. Our hardware security modules service and PKI consultancy align cryptographic controls to the obligations you actually carry.

Talk to our team about your payment HSM estate.