A Practitioner's Guide to AWS Payment Cryptography

Key ceremonies, DUKPT flows, API walkthroughs, PCI compliance, and the real cost model.

Apr 02, 2026

Sometimes AWS will release a service that provides an ability to migrate something thought only to be able to exist in datacenters. Under this category payment HSMs sit firmly. They never really enter the cloud conversation. Normally. Generally, they sit in cages, connected everywhere with proprietary connections, utilize smart-card readers for key ceremonies, and face governance like dual custodian presence. This piece of machinery is one of the main architectural anchors that keeps financial institutions from becoming truly cloud native.

Enter AWS Payment Cryptography (APC). APC isn’t HSM-as-a-service. CloudHSM fits that slot. APC is explicitly for payment cryptography. It supports:

TR-31
TR-34
DUKPT
PIN Translation
CVV/ARQC Generation
PCI PIN and P2PE

All through a RESTful API. No proprietary client libraries, no hardware provisioning, and no key ceremonies required.

In this post we’ll discuss how the service works, the key heirarchy, DUKPT derivation, and API Surfaces for common payment operations. We’ll also discuss PCI compliance posture and honest cost modeling.

What APC is and isn’t:

APC is a managed multi-tenant service hosted on a fleet of PCI PTS HSM V3 and supports FIPS 140-2 Level 3 Certified Hardware. You will never touch this hardware directly, all interactions are performed on 2 API planes:

Control Plane: This handles the key lifecycle management actions (create, import, update, delete, alias, and tag)
Data Plane: This handles the Cryptographic Operations (TranslatePinData, GenerateMac, GenerateCvv, etc.). The service hosts terminate all client connections with TLS cipher suites that enforce perfect forward secrecy. Service hosts connect to the underlying HSM over private non-virtual networks via mTLS. Keys never exist in plaintext outside the HSM boundaries even in the database that backs the service. Keys are stored as ANSI X9 TR-31 key blocks protected by HSM AES-256 main keys.
Important distinction vs. CloudHSM: CloudHSM gives you a dedicated, general-purpose HSM instance with full PKCS#11 / JCE / CNG access. APC gives you no dedicated hardware and no raw key access — but it speaks payment standards natively and handles all the operational complexity for you. These are complementary, not competing.

The Key Hierarchy:

Understanding APC’s key model involves understanding the payment key exchange mechanism in the wild. These 2 relevant standards are TR-31 for symmetric key exchange, and 13-34 for establishing the initial asymmetric trust anchor.

TR-34: establishing the first trust

TR-34 (ANSI X9.24-2) describes a protocol for distributing symmetric keys using RSA asymmetric techniques. It solves the bootstrap problem: how do two parties exchange a Key Encryption Key (KEK) without a pre-existing shared secret?

In TR-34 terminology, the party sending the key is the Key Distribution Host (KDH) (your existing HSM). The receiver is the Key Receiving Device (KRD) (APC). APC issues a temporary asymmetric keypair, returns a certificate for the wrapping key, and your HSM uses that certificate to wrap the KEK being transferred. The import token expires after 30 days.

TR-31: working key import

Once a KEK exists in APC (either via TR-34 or by creating one natively with CreateKey), all working key imports use TR-31. A TR-31 key block ties the key material to its usage attributes in the same data structure. This is the key purpose, mode of use, algorithm, exportability while making key misuse architecturally impossible. APC enforces these attributes at the API layer.

DUKPT: derived unique key per transaction

DUKPT (Derived Unique Key Per Transaction, ANSI X9.24) is the dominant key management scheme for point-of-sale terminals. The core idea: a terminal holds a Base Derivation Key (BDK), from which it derives a unique session key for every transaction using a Key Serial Number (KSN). The network never sees the BDK; only the derived keys, which are mathematically one-way from the BDK.

KSN structure

For 3DES DUKPT (the current production standard), the 10-byte KSN contains a 24-bit Key Set ID (identifies the BDK), a 19-bit terminal ID, and a 21-bit transaction counter. For AES DUKPT (the emerging standard, ANSI X9.24-3-2017), the 12-byte KSN is structured as 32-bit BDK ID, 32-bit derivation identifier, and 32-bit transaction counter.

The terminal increments the transaction counter on every transaction and derives a unique working key from the BDK + KSN. APC replicates this derivation server-side using the BDK stored in its HSM fleet, so it can recover the working key for any valid KSN it receives.

The critical security property:

The PIN in cleartext never exists outside the HSM boundary. APC performs the entire translate operation within the HSM.

PCI compliance posture

APC is designed to satisfy the major PCI payment security standards. Here is what the service covers and what remains your responsibility.

PCI PIN

PIN Security requirements — key management, key blocks, HSM certification

APC covers: HSM certification, TR-31 enforcement, CloudTrail audit logs, key separation. Your scope: IAM access controls, network controls, application-layer logging.

PCI P2PE

Point-to-Point Encryption — POI to decryption environment

APC covers: decryption environment (DUKPT BDK management, PIN translation within HSM). POI certification and key injection remain your responsibility.

PCI DSS

Data Security Standard — applies to cardholder data environment

APC helps scope reduction: PIN data never transits your systems in cleartext. Audit evidence via CloudTrail. Shared responsibility model applies.

PCI 3DS

3-D Secure protocol support

APC supports cryptographic operations needed for 3DS authentication flows (MAC generation, ARQC verification).

Compliance reporting is supported through CloudTrail logs for all key management activities and key metadata accessible via the List Keys and Describe Key APIs. You can export key KCV values for reconciliation with your PCI PIN auditor without exposing key material.

Key ceremony replacement: Traditional HSM deployments require physical key ceremonies — dual-custodian presence, smart card readers, paper key components. APC replaces this with electronic key establishment via TR-34, which is now accepted by PCI PIN. This eliminates the physical ceremony overhead but you must document the electronic key establishment procedure for your QSA.

Cost model: APC vs. on-premises HSM fleet

APC pricing has two components:

API call volume (tiered)
active key count (

$1.00 per active key per month). As of December 2025, AWS reduced API pricing by up to 63% and introduced tiered key pricing.

AWS publishes three reference pricing examples directly. For a small issuer processing 50,000 transactions per month with 2 API calls per transaction and 10 active keys: total is $30/month ($20 API + $10 keys). For a mid-scale processor at 15 million transactions per month with 20 active keys: $4,770/month. For a high-volume processor running 100 million transactions per month across two regions with multi-region keys: ~$20,040/month.

Compared to On-Prem:

A conservative on-premises deployment for a mid-scale processor typically looks like:

4 HSM devices ($240K–$320K over 5 years),
2 colo racks ($3K–6K/month),
HSM vendor support ($25K–60K/year), and the operational overhead of key ceremonies, firmware patching, and HSM engineer time.
A rough 5-year TCO lands between $500K and $900K before staff costs.

At the 15 million transactions per month reference tier, APC costs approximately $57,240 per year. The break-even against a minimal on-premises deployment happens well under 1 year for most organizations, excluding any residual value of existing hardware and the sunk cost of existing colo contracts.

Where APC is not obviously cheaper:

Very high transaction volumes with many active keys, or organizations with existing HSMs under long-term colo contracts with years remaining. At 100M+ transactions per month across two regions, APC costs ~$240K/year. This is still competitive against a HA HSM fleet with DR, but the margin narrows. Model your specific volume and key count before committing.

Give me an oversimplified migration path that is in no way as simple as it seems but might be possible.

You got it!

Migration path: from legacy HSM to APC

The migration pattern from a traditional HSM fleet (Thales Luna, Utimaco, nCipher) or a hosted payment HSM service (like the GCP Virtucrypt/Koard/Mycio model) follows a consistent sequence regardless of starting point.

The proprietary socket API replacement is the heaviest lift. Legacy HSMs typically use vendor-specific APIs — Thales’ PKCS#11/JCA bridge, Utimaco’s cryptographic server protocol, or payment-specific libraries like Koard or Mycio. APC replaces all of these with standard Boto3/AWS SDK calls. Your application integration layer needs to be rewritten, but this is an opportunity to remove vendor lock-in and move to IAM-controlled, CloudTrail-auditable API calls.

Key ceremony elimination is the operational win most teams underestimate. Replacing smart-card key ceremonies with TR-34 electronic key establishment removes a significant operational drag — and means your key rotation schedule is no longer gated on physical availability of two custodians in the same room.

Some Gotchas I’ve found:

Single-region keys by default. APC keys exist in a single AWS region. For multi-region active-active deployments, you need to explicitly import or create keys in each region. AWS does support multi-region key replication, and their pricing examples account for this, but it requires deliberate architecture — do not assume keys are automatically available across regions.
No raw key access. You cannot export key material in cleartext — only as TR-31 key blocks wrapped under a KEK. This is the correct security model, but it means your ability to migrate away from APC in the future depends on having a KEK-capable receiving HSM and a migration plan. Design your key import/export strategy before you need it.

IAM is your access control plane. There are no HSM-native access controls. All authorization runs through IAM policies and condition keys. This is actually an improvement over most legacy HSM ACL models, but it means your IAM posture directly determines your cryptographic security boundary. Use resource-based policies on key ARNs, not wildcards.
CloudTrail is your audit trail. Every key management and cryptographic operation is logged. For PCI PIN compliance, you will want to ensure CloudTrail logs are shipped to an immutable log store (S3 with Object Lock, or CloudWatch Logs with a locked retention policy) and that your log monitoring covers anomalous key usage patterns.

Bottom Line

AWS Payment Cryptography is a serious service designed for organizations that live under PCI PIN, P2PE, and DSS — not a toy. The key management model is sound: TR-31/TR-34 are the right standards, the DUKPT derivation model is correctly implemented, and the HSM certification stack (PCI PTS v3, FIPS 140-2 L3) meets the bar for most financial institution requirements.

The API surface is genuinely better than legacy HSM integration. RESTful calls with Boto3/SDK, IAM-native access control, CloudTrail audit logs, and no proprietary client library dependencies represent a meaningful improvement in operability over socket-based HSM protocols.

The cost model is compelling at most volumes, especially when you fully account for the TCO of dedicated HSM hardware, colocation, vendor support, and operational overhead. The December 2025 pricing reduction makes it more competitive at high transaction volumes than it was at launch.

The migration path is well-defined for organizations willing to invest in the TR-34 trust establishment and application integration rewrite. If you are currently running a legacy HSM fleet or evaluating a cloud payment infrastructure build, APC deserves serious architectural consideration.

Mike Wiseley

Discussion about this post

Ready for more?