PIN Processing in the Cloud - AWS vs Azure vs Google Cloud

Can you process cardholder PINs in the cloud? Yes – provided that certified payment HSMs perform the cryptographic operations on PIN blocks, and the responsibility split between the cloud provider and the customer covers every PCI PIN Security requirement. AWS offers the managed Payment Cryptography service, Azure offers dedicated payShield 10K modules, and Google Cloud requires a third-party payment HSM.

Canonical definition: PIN processing in the cloud is the execution of cryptographic operations on PIN blocks (translation, verification, generation) within payment HSMs delivered as a cloud service, while preserving the requirements of the PCI PIN Security standard.

For acquirers, processors and fintechs building a transaction switch, this is one of the last barriers to a full cloud migration – and a decision worth making on evidence rather than marketing material.

PIN in the cloud – key takeaways:

AWS Payment Cryptography is a fully managed API service running on PCI PTS HSM-certified modules; it holds its own PCI PIN attestation (AOC) plus P2PE component attestations of the DMCP, KMCP and KLCP types (AWS Security Blog).
AWS is listed on the Visa Global Service Provider Registry as an ESO and PIN-Acquiring TPS, allowing a customer’s QPA to rely on the service’s compliance without re-assessing its internals (AWS documentation).
Azure Payment HSM is a bare-metal service with dedicated, single-tenant Thales payShield 10K modules (FIPS 140-2 Level 3, PCI HSM v3) under the customer’s sole administrative control; the service holds PCI PIN, PCI DSS and PCI 3DS certifications (Microsoft Azure Blog).
Google Cloud offers no first-party payment HSM – Cloud HSM is general-purpose with no payment functions; PIN processing on GCP requires a third-party payment HSM (for example Thales’s subscription-based payShield Cloud HSM, which integrates with AWS, Azure and GCP – Thales press release).
Whichever provider you choose, the customer owns its share of PCI PIN requirements: access configuration, key policies, and – in the Azure model – the full set of key management operations and ceremonies.
Patronusec, an accredited QSA, verifies cloud PIN architectures against PCI PIN – from mapping the responsibility split to QPA assessment readiness.

Is processing PINs in the cloud compliant with PCI PIN?

Yes – the PCI PIN standard does not prohibit the cloud; it requires that PIN operations run inside certified SCDs and that every requirement has an owner. Cloud providers close their share with their own AOC attestations and shared responsibility guides, while the customer owns configuration and processes on its side.

The formal mechanism mirrors PCI DSS: the provider undergoes its own QPA assessment and publishes an AOC with a Shared Responsibility Guide, and the customer’s QPA treats the provider’s compliance as satisfying the requirements the provider covers. AWS documentation states plainly that customer assessors have adopted the model established with PCI DSS: the provider’s AOC plus the responsibility guide close out the service-side requirements.

The second pillar is payment network registration. AWS Payment Cryptography is listed on the Visa Global Service Provider Registry as an ESO (Encryption and Support Organization) and a PIN-Acquiring TPS – which, per AWS documentation, allows programme participants to use the service without their QPA re-assessing its internals.

In the cloud, PCI PIN compliance is not a platform feature but the sum of two halves: the provider’s attestation covering the hardware and HSM operations, and the customer’s controls covering access, key policies and integration with the rest of the environment.

The fix: the question is not “can the cloud do it” but “where exactly does the responsibility boundary run in the chosen model” – and that boundary sits in entirely different places on AWS and on Azure.

How does AWS Payment Cryptography work and what does its attestation cover?

AWS Payment Cryptography is a fully managed API service: the customer calls payment operations (PIN translation, PVV verification, key generation) while AWS operates PCI PTS HSM-certified modules behind the scenes, with PCI PIN-compliant key management. The customer administers no device at all.

The functional scope, per AWS documentation, includes:

PIN translation between ISO 9564 block formats (0, 1, 3, 4) and between PEK and DUKPT keys, entirely within the HSM boundary – the PIN block never leaves the service in the clear, and translation between different PANs is blocked in line with PCI,
PIN generation and verification plus PVV values (issuer functions), with a least-privilege recommendation to separate them from acquiring functions,
key exchange in TR-31 key blocks (including dynamic keys passed per transaction), TR-34 distribution, ECDH exchange, and physical key exchange for key injection use cases.

The attestation scope: the service carries its own PCI PIN compliance package (an AOC closed, per the AWS Security Blog, with zero findings) plus P2PE component attestations for decryption (DMCP), key management (KMCP) and key loading (KLCP); the packages include a Shared Responsibility Guide available in AWS Artifact. AWS also publishes a separate “PIN Compliance Planning” guide describing the evidence a customer must prepare for its own assessment.

Limitations to accept knowingly: the interface is AWS-native (applications written against classic payShield host commands need their integration layer rewritten), and regional availability grows gradually – AWS has announced expansions including the São Paulo and Sydney Regions. Beware of service confusion too: AWS CloudHSM carries its own PCI PIN attestation, but it is a general-purpose module – AWS itself points to Payment Cryptography as the right tool for payment operations such as PIN translation.

Patronusec Insight: In our project experience, teams choosing a managed API most underestimate one artefact: a PCI PIN requirements map with “AWS / customer / shared” ownership, produced before any building starts. The provider’s responsibility guide describes its half, but it will not design your IAM access controls for key operations, your issuer/acquirer role separation, or your key compromise response process. Those are the elements the QPA will assess at your end – and they are where first-time cloud assessments most often stumble.

How does Azure Payment HSM work and how does the responsibility model differ?

Azure Payment HSM is a bare-metal service: the customer receives dedicated, single-tenant Thales payShield 10K modules connected directly to its virtual network, with sole administrative control on the customer’s side. Microsoft maintains the infrastructure and data centres but has no access to the devices or the customer’s data.

The characteristics, per the Microsoft Azure Blog and Microsoft Learn documentation:

payShield 10K modules certified to FIPS 140-2 Level 3 and PCI HSM v3, provisioned in pairs for high availability,
remote administration via payShield Manager (smart cards, remote ceremonies) – the customer manages LMKs, configuration and firmware exactly as in its own machine room,
a service certified for PCI PIN, PCI DSS and PCI 3DS; customers leverage the shared responsibility matrix from Azure’s AOC,
full compatibility with existing payShield host software – migrations from on-premises often require no changes at the command layer.

The responsibility model is the mirror image of AWS: Microsoft covers the data centre’s physical security, power and network, while key management operations – ceremonies, custodians, LMK components, policies, rotations – remain entirely with the customer. That is an asset for organisations with a mature crypto-operations team and existing procedures; for a company building the capability from scratch, it means the HSM comes bundled with the whole of the PCI PIN key administration requirements to satisfy on its own.

Choosing between a managed API and a dedicated payShield in the cloud is, in essence, choosing who runs the key ceremonies: the provider within its attestation, or your custodian team within your own QPA assessment.

Chosen your model (managed API or dedicated HSM) and want to know whether the architecture will survive a QPA?

Patronusec performs a cloud PIN architecture review: we map every PCI PIN requirement to a responsible party (provider / your organisation / shared) and flag the missing controls. Within 10 working days you receive a written responsibility matrix and a gap list to close before the assessment.

Order a PIN architecture review

What does Google Cloud offer for PIN processing?

Google Cloud has no native payment HSM service – Cloud HSM provides general-purpose modules (FIPS 140-2 Level 3) without payment functions such as PIN block translation or zone key management. PIN processing in a GCP-based architecture requires a payment HSM delivered by a third party.

The realistic options for GCP-committed organisations:

Payment HSM as a third-party service. Thales offers payShield Cloud HSM – a subscription service built on payShield 10K, hosted in Thales data centres compliant with PCI PIN requirements and integrating with AWS, Azure and GCP (Thales press release). The application runs in GCP while a remote payShield performs PIN operations over a private link.
A hybrid model. The application layer and data in GCP, with payment HSMs in the organisation’s own machine room or a colocation facility, connected via Interconnect/VPN. This is the most common transitional set-up in migrations.
A multi-cloud architecture. PIN operations delegated to AWS Payment Cryptography or Azure Payment HSM, called from applications in GCP – technically feasible, but it adds inter-cloud latency and a second provider to the assessment.

The compliance consequence: in every variant the chain of responsible parties grows (GCP for the application infrastructure, the HSM provider for payment operations, the link operator for transmission), and the QPA will assess each junction. The absence of a first-party service does not disqualify GCP – it raises the architecture and documentation cost relative to single-cloud scenarios.

How do the three approaches compare in practice?

The three platforms represent three different operating models: a managed API (AWS), dedicated hardware in the cloud (Azure), and integration with a third-party HSM (GCP). A meaningful comparison happens at the level of responsibility models, compatibility and compliance evidence – not raw cryptographic features.

Criterion	AWS Payment Cryptography	Azure Payment HSM	Google Cloud + third-party HSM
Service model	Fully managed API (serverless)	Bare-metal, dedicated payShield 10K in an HA pair	Application in GCP + payment HSM at a third party
Hardware certification	AWS-managed HSMs, PCI PTS HSM certified	FIPS 140-2 Level 3, PCI HSM v3	Provider-dependent (payShield Cloud HSM: payShield 10K)
Service compliance evidence	PCI PIN AOC + P2PE component attestations (DMCP, KMCP, KLCP), responsibility guide in AWS Artifact	Service certified for PCI PIN, PCI DSS and PCI 3DS; responsibility matrix from Azure’s AOC	HSM provider’s AOC + GCP’s responsibility for the application layer (separately)
Key management and ceremonies	On AWS’s side (within the service attestation); customer manages policies and access	Entirely on the customer’s side (LMKs, custodians, payShield Manager)	Depends on the HSM provider agreement
Compatibility with legacy payShield hosts	Requires rewriting the integration to the AWS API	Native – the same host commands	Native with payShield Cloud HSM
Visa registry status	ESO + PIN-Acquiring TPS (Visa Global Service Provider Registry)	Customer registers its own service per its role	Depends on the HSM provider
Billing model	Pay per use (keys and API calls)	Subscription for dedicated devices	Third-party subscription + GCP and connectivity costs
Best fit	New cloud-native platforms, minimal HSM operations	Migrating an existing payShield switch, full key control	Organisations strategically committed to GCP

Patronusec Insight: In migration projects, one technical detail most often settles the choice: the host command format. An organisation with a decade of logic built on payShield commands usually picks Azure or payShield Cloud HSM, because rewriting the switch to a new API is a project measured in years, not months. An organisation building from scratch carries no such baggage and more often picks the managed API, shifting the whole HSM operations chapter to the provider. We recommend starting the analysis not from the price list but from an inventory of host command dependencies.

What must a company planning cloud PIN processing pay attention to?

The eight questions below reflect a QPA’s perspective – they determine whether the architecture will survive an assessment. Walk the checklist before signing with a provider, because some answers determine the platform choice itself, not just the configuration.

Assessor’s checklist – PIN in the cloud:

Does the provider hold a current PCI PIN AOC covering exactly the services and regions you plan to use?
Is there a shared responsibility guide, and does every PCI PIN requirement have an unambiguous owner (provider / customer / shared)?
Who acts as key custodians and how do ceremonies run – remotely (payShield Manager smart cards), on the provider’s side within its attestation, or hybrid?
Does key exchange happen exclusively in key blocks (TR-31, TR-34), and does the platform support AES and the ISO format 4 PIN block on the TDEA migration path?
What is the network path to payment networks and acquirers – private links, latency, redundancy – and who owns its compliance?
Do data residency and HSM location meet your jurisdiction’s regulatory requirements (in the EU, supervisory expectations on outsourcing, including DORA for financial entities)?
What is the exit strategy: can keys be exported in key blocks to another environment, or must you plan regeneration and re-exchange with partners?
Are HSM operation logs and key event logs available to your team and sufficient as evidence in a QPA assessment?

For organisations simultaneously subject to sector rules, we help tie these answers into the wider compliance programme – from PCI DSS certification of the application environment to DORA requirements for financial institutions outsourcing critical functions.

Planning a PIN processing migration to the cloud and unsure where to start?

Patronusec runs a PIN migration scope-assessment: in a free 30-minute call we classify your role (processor, ESO, TPS), walk the 8 control questions for your chosen platform, and identify the PCI PIN requirements remaining on your side. After the call you receive a written summary with a recommended route.

Book a free scope-assessment

FAQ

Will a QPA accept a cloud provider’s AOC?

Yes – it is an established model: the customer’s QPA relies on the provider’s AOC for the requirements the provider covers, analogous to PCI DSS assessments. AWS documentation describes this practice directly, and the ESO/TPS status on the Visa registry additionally formalises use of the service by programme participants.

How does AWS Payment Cryptography differ from AWS CloudHSM?

Payment Cryptography is a managed payment service with PIN functions (translation, PVV, DUKPT, TR-31/TR-34) on PCI PTS HSM-certified modules. CloudHSM provides general-purpose modules with no payment commands – AWS itself recommends Payment Cryptography for operations such as PIN translation.

Can compliant PIN processing be built on Google Cloud?

Yes, but with a third-party payment HSM: a service such as Thales’s payShield Cloud HSM, an HSM in colocation connected via Interconnect, or calls to a payment service in another cloud. Google Cloud HSM offers no payment functions, so on its own it cannot perform PIN translation.

Who runs key ceremonies in Azure Payment HSM?

The customer – the payShield 10K modules stay under its sole administrative control, and ceremonies run remotely through payShield Manager with smart cards. Microsoft has no access to the devices or key material. Custodian, dual control and ceremony documentation requirements remain entirely with the customer.

Does migrating PIN processing to the cloud require a new QPA assessment?

Yes. Relocating a processing facility and materially changing the environment (new HSMs, a new operating model) are classic triggers for reassessment, indicated among others in Visa’s programme documentation. Plan the migration so that the QPA assessment closes the project rather than discovers its gaps.

How much does Patronusec support for a cloud PIN migration cost?

The price depends on your role (processor, ESO, TPS), the chosen platform, and whether we build the responsibility matrix from scratch or verify an existing architecture. After a free scope-assessment call we present a fixed-price quote covering the architecture review, gap analysis and QPA assessment readiness.

How do we start working with Patronusec in this area?

The first step is a free 30-minute scope-assessment call: we classify your role, platform and state of readiness, then propose a route – from the responsibility matrix, through the gap analysis, to assessment support. You will find the contact form on the PCI PIN Security service page.

Blog space

PIN Processing in the Cloud – AWS vs Azure vs Google Cloud Compared, Plus 8 Questions to Ask First

In this article you will read:

Table of Contents