Marvell’s announcement that Microsoft has expanded Azure’s use of Marvell LiquidSecurity hardware security modules (HSMs) into new European use cases marks a meaningful inflection point for cloud-native cryptography: certified HSM hardware that is explicitly validated for eIDAS and Common Criteria EAL4+ is now part of Azure’s key-management stack in Europe, unlocking qualified-signature, identity and cross‑border trust services at cloud scale while raising fresh questions about scope, governance and vendor lock‑in.
Background / Overview
Marvell and Microsoft have been working together for several years to embed cloud-optimized HSM adapters into Azure Key Vault and Managed HSM offerings. The latest public disclosures indicate Microsoft is extending Azure’s Marvell‑backed services in Europe—specifically enabling workflows that rely on qualified electronic signatures, identity verification and cross‑border contract certification. Those announcements follow recent certifications attained by Marvell’s LiquidSecurity family under the European eIDAS regime and Common Criteria EAL4+. This development sits on top of prior milestones: Marvell’s LiquidSecurity products have been validated for FIPS 140‑3 Level 3, and Microsoft previously integrated Marvell HSMs into Azure Key Vault Managed HSM and other Azure key services. The net effect is that Azure now has a set of cloud HSM offerings whose hardware substrate is explicitly certified for the legal and technical claims Microsoft and its European customers are making. Why this matters: eIDAS-qualified signature creation and Common Criteria validations are necessary prerequisites for many regulated electronic trust functions in the EU. By aligning certified HSM hardware with Azure’s service portfolio, Microsoft positions Azure as a viable platform for trust services that historically required on‑premise Qualified Signature Creation Devices (QSCDs).
What Marvell and Microsoft actually announced
The core announcement, in plain terms
- Microsoft expanded Azure’s cloud-based security use cases in Europe to rely more broadly on Marvell LiquidSecurity HSMs for operations such as certifying cross‑border electronic contracts, verifying identity documents and delivering other trust services at scale.
- Marvell confirmed LiquidSecurity HSMs achieved European certifications under the eIDAS framework and Common Criteria EAL4+, and reiterated prior FIPS 140‑3 Level 3 validations used by Azure elsewhere.
- Microsoft stated the collaboration enables Azure customers—particularly those in identity, passport, timestamping and trust-service sectors—to leverage compliant key-management services in public, sovereign and government cloud configurations.
Third‑party commentary and analyst context
Market analysts cited in the announcements (and in secondary reporting) emphasize the HSM-as-a-service market is growing and that cloud-optimized HSM architectures are now a strategic element for confidential computing, cloud sovereignty and large-scale identity services. These analyst views are echoed across vendor and trade reporting.
Technical snapshot: LiquidSecurity architecture and performance claims
Form factor and design
- LiquidSecurity is a family of PCIe-based HSM adapters optimized for dense, multi-tenant cloud deployments rather than the older 1U/2U appliance model historically used for HSMs. These adapters are designed to be installed in hyper-scale servers and controlled centrally by cloud operators.
Processing and capacity claims
- Marvell’s LiquidSecurity 2 (LS2) is marketed with up to 1,000,000 hardware-secured keys and support for dozens of isolated partitions (45 partitions listed for multi‑tenant isolation in product materials). The LS2 platform advertises high-density key storage and multi-tenant partitioning.
- Performance metrics are expressed in slightly different ways across documents: the LS2 product page cites 100,000 elliptic-curve cryptographic (ECC) operations per second as an illustrative performance number, whereas other Marvell releases tied to Azure claims describe processing more than one million operations per second. Those differences likely reflect different workloads (ECC vs mixed or symmetric ops), platform configurations, or shorthand marketing statements—buyers should treat the numbers as model- and workload-dependent and verify with vendor benchmarks under their expected cryptographic profiles. This is a verifiable-but-contextual specification; treat it as performance guidance, not a single universal metric.
Key management model
- LiquidSecurity supports partitioning (isolated partitions per tenant), standard crypto APIs (PKCS#11, JCE, OpenSSL), and integration points aimed at enabling HSM-as-a-service APIs for cloud providers. That supports scalability and multi‑tenant assurance models when properly implemented by the cloud operator.
Certifications explained: What eIDAS, Common Criteria EAL4+ and FIPS 140‑3 mean here
eIDAS (QSCD) — legal weight in the EU
- eIDAS establishes EU-wide legal frameworks for electronic identification and trust services. A Qualified Signature Creation Device (QSCD) designation under eIDAS is required for certain high‑assurance legal signatures that carry the same probative value as handwritten signatures in the EU.
- Microsoft’s Community Hub and Azure documentation confirm Azure Managed HSM and Azure Key Vault Premium devices—built with Marvell hardware—have received eIDAS certification under a national scheme (A‑SIT/Austrian scheme), enabling qualified signature creation workflows where allowed. This is the practical enabler for cloud-hosted qualified electronic signatures.
Common Criteria EAL4+ — engineering and assurance
- Common Criteria evaluation at EAL4+ provides an internationally recognized assessment of the product’s development lifecycle, security functions and testing. The “+” typically indicates additional protections or augmented assurance elements required by the evaluator.
- Marvell’s product literature and recent announcements state LiquidSecurity achieved Common Criteria EAL4+, a strong commercial-level assurance that helps regulatory and procurement teams justify cloud HSM usage for regulated processes. Procurement teams should, however, obtain the certification artifact (certificate number, exact product/firmware revision, evaluator) to confirm scope.
FIPS 140‑3 Level 3 — U.S./North American technical standard
- Marvell publicly announced FIPS 140‑3 Level 3 validation for LiquidSecurity hardware previously, and Microsoft has integrated FIPS‑validated LiquidSecurity devices into Azure Key Vault services in other geographies. FIPS 140‑3 Level 3 implies tamper-detection and physical security protections that many enterprise and government buyers require. Exporting that assurance to cloud services provides parity with many on‑premise HSM requirements.
What this enables for Azure customers in Europe
- Qualified electronic signatures as a cloud service: Trust service providers and enterprises can now build qualified-signature flows on Azure where the HSM backend meets eIDAS QSCD requirements—assuming the specific Azure service instance and configuration falls within the certified scope.
- Identity and passport workflows at scale: High-throughput signing and verification workloads, such as national ID issuance, passport services, and mass document attestation, become feasible without per-customer on‑prem HSM appliances, lowering operational overhead for governments and large enterprises.
- Cross-border contract and timestamping services: eIDAS QSCD validation underpins legal recognition across member states; cloud HSMs that meet the standard simplify multinational deployments of trust services.
Benefits include reduced rack space, lower power consumption and faster time-to-market for trust services because cloud-native HSM adapters are denser and centrally managed compared with traditional 1U/2U HSM appliances. Marvell and Microsoft emphasize these efficiency gains as key business drivers.
Critical analysis: strengths, practical benefits and immediate limitations
Strengths and opportunities
- Performance and density: PCIe-attached, DPU-accelerated HSM adapters deliver far higher key density and per-rack throughput than legacy appliances, which matters when operators need to scale HSM services across millions of transactions per month. This reduces cost-per-operation and TCO.
- Regulatory alignment for EU trust services: The combination of eIDAS QSCD recognition, Common Criteria EAL4+ and FIPS 140‑3 Level 3 creates a trifecta of certifications that align with many of the legal and technical constraints for identity and signature services in regulated industries. Microsoft’s public confirmation of eIDAS compliance under the Austrian scheme is a significant independent corroboration of the claim.
- Cloud-native consumption model: By exposing HSM functions through managed cloud services, Microsoft enables customers to avoid the life‑cycle overhead of on‑prem HSM clustering, while still meeting many high-assurance requirements—provided the certified configuration is used.
Immediate limitations and caveats
- Scope-limited certifications: Certifications are almost always scope-bound to specific hardware SKUs, firmware versions and deployment models. Marketing summaries can blur that detail. Organizations requiring certified QSCD behavior must request the certificate PDFs, scope statements, firmware bindings and evaluator reports to confirm that the exact Azure service they plan to consume is covered. This is not a legal nicety—it’s procurement reality. Do not assume every Azure HSM instance in every region is automatically in scope.
- Specification inconsistencies require scrutiny: Marvell’s public materials and joint announcements use different numeric claims (for example, some documents reference “up to 1,000,000 keys” while specific collaboration press materials reference “100,000 pairs of encryption keys”). Performance metrics (e.g., 100,000 ECC ops/s vs more than one million operations/sec) are expressed with differing units and workload assumptions. These are plausible when interpreted as different measurement points, but buyers must request clear, workload-specific benchmarks (ECC vs RSA vs AES, single-threaded vs parallel, latency vs throughput).
- Visibility and attestation trade-offs: Managed HSM models centralize firmware updates, lifecycle control, and some telemetry in the cloud operator’s hands. That reduces operational overhead but also shifts control away from tenants. For the highest-assurance legal or sovereign use cases, organizations may need contractual attestation, audit rights, or hybrid models (e.g., BYOK or split-key techniques) to maintain required governance and evidentiary chain-of-custody.
- Potential vendor/hardware lock-in: Standardization on a specific cloud provider plus a specific HSM substrate can increase migration friction. If a regulator or customer later requires a different HSM architecture, the cost and complexity of migrating keys, signatures and audit trails can be material. Plan exit and contingency strategies up front.
Procurement checklist: what enterprise and government buyers should demand
When evaluating Azure HSM services that rely on Marvell LiquidSecurity, procurement and security teams should insist on the following before accepting claims made in vendor marketing:
- Obtain the official certification artifacts:
- FIPS 140‑3 certificate number and scope statement (hardware SKU + firmware version).
- Common Criteria EAL4+ certificate and evaluator report showing exactly what was assessed.
- eIDAS QSCD certificate (national scheme identification—e.g., A‑SIT/Austrian scheme) and the binding to Azure service configurations.
- Request a mapping matrix:
- A document mapping Azure service components (Managed HSM, Key Vault Premium, Cloud HSM) to the certified Marvell hardware SKU and firmware versions, plus operational constraints and supported signature profiles for qualified signatures.
- Confirm performance for your workload:
- Vendor-signed benchmarks that reflect your expected cryptographic mix (ECC vs RSA vs symmetric), payload sizes and latency/throughput needs. If performance consistency matters, require Service Level Objectives (SLOs) in the contract.
- Verify attestation and auditability:
- Ability to obtain cryptographic attestation of HSM instances (e.g., attestations proving firmware version, hardware identity and partition bindings), plus contractual rights to audit or to receive independent third-party attestation reports on the cloud operator’s HSM fleet.
- Preserve key sovereignty options:
- Support for Bring Your Own Key (BYOK), Customer‑Managed Keys (CMEK), split-key or key‑escrow models if legal or policy frameworks require customer control of signing keys. Specify key rotation and revocation processes and test them.
- Clarify incident response and lawful access posture:
- Explicit contractual language about the cloud operator’s obligations, notification windows, local data residency commitments, and how law‑enforcement or government demands will be handled in your jurisdiction.
Operational recommendations and mitigations
- Use hybrid patterns for the highest-assurance use cases: combine cloud HSMs for scale with on‑prem QSCD devices for legal or political risk mitigation where the law requires exclusive local control.
- Require cryptographic attestation and per‑tenant partition identifiers in the service response so you can bind signatures and audit events to specific certified partitions or HSM instances.
- Automate key rotation and use split-key or threshold signing where possible to reduce single‑point‑of-control risks.
- Test full end-to-end legal workflows (including signature validation and non‑repudiation evidence) under the exact Azure service configuration with the cloud provider’s compliance and legal teams present.
- Build contractual exit clauses and key export plans to prevent entanglement if future migration becomes necessary.
Unverifiable or vendor-claim items flagged for caution
- Vendor statements about broad adoption—such as the claim that LiquidSecurity is used by “six of the ten largest cloud service providers”—appear in Marvell materials and repeated trade reports but require independent confirmation from the named cloud operators or third‑party analyst reports for procurement-grade validation. Treat such market-share claims as useful indicators but not procurement evidence.
- Vendor-supplied throughput and key-capacity numbers are real product design targets, but their practical realization depends on firmware version, configuration, multi-tenant multiplexing, and the cloud operator’s orchestration. Always verify with benchmarks that mirror your real-world workload.
Strategic implications for WindowsForum readers and enterprise architects
- For organizations building identity, signing, time-stamping and PKI services: this is a practical enabler to move qualified-signature workloads to the cloud, provided the certified configuration is used and documented. The cost and operational benefits can be compelling, particularly for cross‑border deployments.
- For regulated industries (finance, government, healthcare): this reduces the friction of managing distributed QSCD hardware but introduces new governance responsibilities around attestation, audit rights and contractual controls. Those responsibilities must be encoded and tested.
- For cloud‑native product teams: plan for HSM-partition observability, robust SRE runbooks for key lifecycle operations, and dependency plans to handle firmware patches or certificate revalidations tied to the certified SKU/firmware.
Conclusion
The Marvell–Microsoft collaboration to extend LiquidSecurity‑backed HSM services across Azure’s European footprint—and to do so under the eIDAS and Common Criteria EAL4+ umbrellas—represents a decisive step toward making
certified, cloud‑native qualified-signature and identity services practical at scale. The technical architecture (PCIe-attached, DPU-accelerated HSM adapters) and the layered certifications (FIPS 140‑3, eIDAS QSCD, Common Criteria) together address the core technical and legal requirements that previously forced many trust services to remain on prem.
That said, the announcement is not a turnkey guarantee: certifications are scope‑bound, performance claims vary by metric, and cloud-managed models shift meaningful operational control to the provider. Organizations that plan to rely on these services should proceed with a checklist mindset—obtain certificate artifacts, demand mapping matrices and attestation, run workload‑specific benchmarks, and bake governance and exit strategies into procurement. When those steps are taken, the result is a powerful, scalable platform for modern trust services; taken naively, the same marketing claims can create compliance and operational surprises.
The net: certified cloud HSMs are now mature enough to be central to regulated trust services, but real assurance comes from documentation, testable configuration and contractual rights—not from headlines.
Source: Communications Today
Marvell extends collaboration with Microsoft | Communications Today