News.Az first carried the partners’ announcement, which Marvell detailed in its own release. Reuters and MarketScreener also reported the launch. The initial preview is limited to two regions, and the companies have not published a price, throughput tiers, service-level agreement, migration guide, or the certification record customers will need before moving live PIN and card-processing workloads. For financial IT teams, those omissions matter more than the phrase “cloud-native.”
A new service beside Azure’s existing Payment HSM
Microsoft’s existing Azure Payment HSM is a bare-metal offering based on Thales payShield 10K appliances. Customers provision hardware directly into their virtual network, retain sole administrative control of the devices, use Thales management tooling, and are responsible for their own high-availability and disaster-recovery arrangements. Microsoft’s documentation says that service has no specific uptime guarantee; users are expected to deploy an in-region pair and add another-region capacity for disaster recovery.
Azure Payment HSM v2 is presented as the successor in name but differs substantially in architecture. Marvell says the new service combines its LiquidSecurity 2 HSM hardware with Utimaco’s Atalla Payments Module and Azure operations into a fully managed service. Its companion technical blog says existing applications using the Atalla API should be able to point to the Azure offering without an application rewrite, while Azure handles scaling, high availability, backup and restore.
That potential API continuity is the practical attraction. Payment systems are often built around proprietary command sets and key-block formats that have survived several generations of hardware. Replacing a payment HSM is rarely a simple infrastructure refresh: it can involve PIN translation validation, issuer and acquirer integrations, terminal key-loading workflows, audit evidence, separation-of-duties controls, rollback planning, and coordinated testing with payment-network partners. A managed service that preserves the existing Atalla application interface could reduce one of the most expensive parts of moving these systems.
But compatibility should not be mistaken for a completed migration plan. The announcement does not say which Atalla command sets, firmware equivalents, key-import formats, management functions, cryptographic modes, or integrations are supported during preview. It also does not say whether a customer can transfer existing keys and security domains into v2, or whether production deployment requires a parallel key ceremony and re-enrollment of payment endpoints.
The “high availability” claim needs customer-side detail
The companies call the platform highly available, while also describing it as multi-tenant, cloud-scale hardware. That is a major departure from the dedicated-HSM model, where a customer can see the appliances, define their pair topology, own the operational procedures, and take direct responsibility for recovery.
Marvell’s description makes clear that LiquidSecurity hardware is designed for dense, multi-tenant environments. In broad terms, that allows a cloud provider to pool physical cryptographic capacity while preserving logical isolation between customers. The value proposition is elastic scale and reduced appliance management, but the assurance case is different from having named, dedicated payment-HSM devices in a customer virtual network.
The preview announcement does not publish the boundary between Microsoft’s responsibilities and the customer’s. That unanswered question includes who controls key-loading ceremonies, what form of administrative separation is available, how tenant isolation is validated, how backup material is handled, whether restore operations cross regions, and what happens during a regional capacity event. Those are operational questions rather than marketing details when the service protects PIN keys and cryptographic material tied to card authorization.
Microsoft’s published documentation for the older Azure Payment HSM also shows why readers should not assume the same controls carry over. The legacy service uses Thales payShield hardware and Thales payShield Manager; the v2 announcement names Utimaco’s Atalla module on Marvell hardware. The underlying payment software interface may be familiar to some institutions, but the physical hardware, control plane and service model are different. Existing Azure Payment HSM customers should therefore treat v2 as a new platform qualification, not as an ordinary version upgrade.
PCI language is not the same as a production approval
Marvell, Microsoft and Utimaco say v2 is designed to meet PCI security, audit and operational requirements, including PCI PIN Security and PCI HSM expectations. That is a reasonable design target for a payment HSM service, but the public materials do not identify a v2-specific PCI assessment, listing, report on compliance, or shared-responsibility matrix.
That distinction has real consequences. PCI requirements attach to the whole payment environment: hardware, firmware, cryptographic configuration, key ceremonies, administration, network segmentation, monitoring, change management and the customer’s applications. A hardware module can carry a recognized security validation while the deployed service still needs a separate assessment of its configuration and operational controls.
The established Azure Payment HSM documentation includes named compliance materials for its Thales payShield implementation, including references to PCI PIN, PCI DSS and PCI 3DS packages. The v2 materials issued Thursday do not yet provide comparable public documentation for the Marvell-Utimaco platform. That does not establish a compliance failure; it establishes that a buyer cannot yet independently match the preview service to the evidence typically requested by an assessor, internal risk committee or payment-network compliance program.
Financial institutions considering the preview should insist on written answers before routing any production transaction flow through it:
- The provider should identify the exact hardware and software versions, their cryptographic validations, and the payment functions available in the preview.
- The provider should provide a shared-responsibility model covering key custody, quorum controls, audit logs, backup, restoration and incident response.
- The provider should explain how high availability works within West US or West Europe and what supported disaster-recovery design exists between regions.
- The provider should document migration procedures for Atalla-managed keys, including rollback steps and the handling of old HSMs after cutover.
- The provider should state whether the preview is covered by a service-level agreement and whether preview use is eligible for a customer’s PCI production scope.
“Industry first” is narrower than it sounds
Utimaco CEO Stefan Auerbach called the implementation an industry first, and the release calls the platform the first of its kind. The claim appears to rest on the particular combination of Utimaco payment software, Marvell’s cloud-oriented HSM hardware and Microsoft’s managed Azure service.
It should not be read as meaning that payment HSMs have never been available in public cloud facilities. Microsoft has offered Azure Payment HSM for years using Thales devices, and Utimaco itself recently described payment HSM as a service in an IBM cloud context. The more defensible claim is that this is a new managed implementation of established payment-HSM functions using this particular multi-vendor stack.
That narrower reading is still significant. Traditional payment HSM deployments force banks and processors to buy capacity for peaks, manage device lifecycle and coordinate expansions around physical infrastructure. If Azure Payment HSM v2 actually delivers predictable low latency, acceptable throughput and operational controls that stand up to PCI review, it could give payment teams a way to scale specialized cryptography more like other Azure services.
The current release, however, offers no performance figures for the managed service. Marvell quotes broad LiquidSecurity 2 hardware capacity in its blog, but adapter-level cryptographic operations are not the same as measured end-to-end payment performance. A production payment path includes network latency, API translation, authorization applications, regional topology and failure behavior. Banks should demand workload-specific benchmarks—PIN translation, EMV cryptogram processing, card issuance and remote key loading—rather than extrapolating from maximum hardware operations per second.
Public preview is the beginning of due diligence
Azure Payment HSM v2 is available in public preview only in West US and West Europe as of September 17. That leaves out many of the regions supported by the older Azure Payment HSM service, including East US, Central US, South Central US, North Europe and Australia East. It also means there is no stated cross-region pair for a customer that must keep all operations inside a particular jurisdiction while retaining a tested recovery site.
Microsoft, Marvell and Utimaco have announced a potentially important new path for organizations whose payment applications already speak Atalla. They have not yet published enough operational, compliance or commercial detail for a regulated institution to treat the preview as a production replacement for a dedicated payment-HSM estate.
For now, the sensible deployment is a controlled evaluation using non-production keys and representative transaction workloads. The decisive documents will be the eventual regional expansion plan, pricing, SLA, migration runbook and v2-specific compliance evidence—not the announcement’s promise to remove the hassle of running hardware.