On September 17, Azure Updates marked Azure Payment HSM v2 as available in public preview. It's a new single-tenant payment HSM cluster, built on Utimaco's Atalla Payment Module rather than the Thales payShield hardware behind the existing Azure Payment HSM, and Microsoft's own overview page states the customer keeps "exclusive administrative control of an isolated, single-tenant payment HSM cluster" while the service "helps you protect sensitive payment assets, maintain key sovereignty, and meet the stringent security, compliance, audit, performance, and operational requirements of the Payment Card Industry." That's a notable phrase to see in a product overview rather than a sovereignty pitch deck. It's also, on inspection, ahead of where the service's own compliance documentation currently sits.
What shipped
Azure Payment HSM v2 provisions a highly available HSM cluster into your Azure virtual network over private endpoints, with two separate interfaces — a management port and an application port — each authenticated independently over mutual TLS. Payment applications talk to it through the Utimaco Atalla command set: PIN processing, EMV transaction support (ARQC validation, EMV MAC generation), key management using Atalla Key Blocks and TR-31 key blocks, and DUKPT. Microsoft manages the underlying infrastructure, availability, and lifecycle; the customer manages the keys, and per the FAQ, "Microsoft doesn't have access to the keys stored in customer-allocated HSMs."
The security posture on paper is solid: infrastructure certified to FIPS 140-3 Level 3, PCI DSS, PCI 3DS, and PCI PIN, running in PCI-compliant Azure datacenters, with signed audit logs shipped through Azure Monitor diagnostic settings into a dedicated PaymentHsmHardwareOperationAuditLogs table. During preview it's free, gated, and available in exactly two regions: West US and West Europe. For a service explicitly marketed on sovereignty language, having West Europe in the initial pair rather than added later is the right signal to send European customers.
The compliance page that didn't ship with it
Here's where the story gets more interesting than the release note. Azure Payment HSM — the existing Thales-based service that v2 sits alongside, not replaces — has its own dedicated Certification and compliance page. It lists fourteen separate standards: PCI DSS, PCI PIN, PCI 3DS, CSA STAR Certification, CSA STAR Attestation, ISO 20000-1:2018, ISO 22301:2019, ISO 27001:2013, ISO 27017:2015, ISO 27018:2019, ISO 27701:2019, ISO 9001:2015, SOC 1/2/3, and — the one that matters most for a German or EU-regulated financial customer — Germany C5, the BSI's Cloud Computing Compliance Criteria Catalogue. The page links straight to the Service Trust Portal for downloadable PCI DSS, PCI PIN, and PCI 3DS attestation packages.
Go looking for the equivalent page for Azure Payment HSM v2 and, as of this preview, it isn't published. The v2 FAQ's "Security and compliance" section covers exactly four items — FIPS 140-3 Level 3, PCI DSS, PCI 3DS, PCI PIN — and stops there. No CSA STAR, no ISO 27001, no Germany C5, no Service Trust Portal link, no NIST certificate reference for the FIPS claim (Azure Cloud HSM's own overview, by contrast, links its actual NIST validation certificate). None of this means v2 fails those standards — a preview service commonly launches ahead of its full attestation package, and the underlying Azure datacenter certifications (PCI DSS, PCI 3DS compliant facilities) already cover part of the picture. But "the infrastructure is certified" and "here is the downloadable attestation report scoped to this specific service" are two different claims, and for now only the first one is published for v2.
That gap is exactly the kind of thing a DORA or NIS2 documentation exercise surfaces the moment someone tries to file it. If Payment HSM v2 is going into a PCI or DORA ICT third-party risk assessment this year, the honest note in that file is "certification inherited from Azure platform-level attestations; service-specific compliance page and Service Trust Portal package not yet published" — not a checked box.
A second vendor is now inside the trust boundary
The other detail worth flagging: onboarding doesn't run through Microsoft alone. Alongside your Azure account, you need a separate, registered Utimaco Support Portal account — created with your corporate email and business delivery address — because Utimaco ships the actual onboarding kit: the Secure Configuration Assistant application, a C3 Key Loading Device, and smart cards, sent to your physical address before you can complete setup. Support is explicitly split down the middle: Microsoft handles gated onboarding, provisioning, configuration, and network access; Utimaco handles the Atalla Payment Module, the SCA application, the KLD, and the smart cards through its own support portal.
None of this contradicts "Microsoft has no access to your keys" — it doesn't. But a service that's fully abstracted from physical hardware ("no procuring, deploying, or scaling physical HSM hardware," per the overview's own pitch) still has physical key-loading devices shipped by a third party, and that party now sits inside the trust and support chain in a way the FAQ documents but the marketing copy doesn't dwell on. For anyone doing DORA's look-through subcontractor mapping, Utimaco is now a named entity in that chain, not an abstraction.
What's not answered yet
- No dedicated compliance/certification page for v2. Nothing published yet matches the scope of the v1 page — no Germany C5, no ISO 27001, no Service Trust Portal attestation package specific to Payment HSM v2.
- Single LMK domain only. Azure Payment HSM v2 "currently supports a single LMK domain" per the operations glossary — a real constraint for a payment service provider acting on behalf of multiple financial institutions from one cluster, with no stated timeline for multi-domain support.
- No intermediate CA support. Mutual TLS trust requires a self-signed root CA on the NIST P-256 curve specifically — enterprises with an existing internal PKI can't hang this service off their normal certificate hierarchy.
- No documented migration path from Azure Payment HSM (v1). The two services "coexist" per Microsoft's own note — there's no stated guidance for an existing Thales payShield customer wanting to move to the Utimaco-based v2.
- One EU region only, during preview. West Europe alone means no intra-EU failover or data-residency choice yet for customers who need it inside the EU boundary specifically.
Who should care
If you're a payment service provider or financial institution already scoping cloud-native HSM options, this preview is worth a lab evaluation now — the architecture, the audit logging, and the FIPS 140-3 Level 3 / PCI baseline are real and usable today. What it isn't yet is something you can drop into a customer-facing compliance narrative or a DORA third-party risk file as a like-for-like replacement for the existing service's attestation package. That gap will very likely close before GA — Microsoft has every reason to publish it — but "will very likely close" and "is published" are different states, and the difference is exactly what an auditor asks about first.
Microsoft's own docs used the words "key sovereignty" before they shipped the paperwork that lets you prove it to someone else. That's not unusual for a preview — it's just worth knowing which claim you're allowed to make to your own auditor today, and which one you're borrowing in advance.
I'm tracking whether the v2 certification page lands before GA, and whether Germany C5 makes the cut — that's the detail that tells you whether this service is actually built for the EU regulated-finance customer the "key sovereignty" language is aimed at. If you want that update when it lands, subscribe to Sovereign Cloud Watch or find me on LinkedIn.