Microsoft Expands Azure HSM with Marvell LiquidSecurity for EU eIDAS and Common Criteria

  • Thread Author
Microsoft has quietly widened the security bridge between hyperscale cloud and European regulation by expanding Azure’s use of Marvell’s LiquidSecurity hardware security modules (HSMs), a move that stitches eIDAS and Common Criteria assurances into Azure Key Vault, Managed HSM and Cloud HSM offerings across Europe.

Blue holographic display on a server rack showing eIDAS QSCD, shield, cloud, and Azure branding.Background / Overview​

Cloud HSMs are the hardware roots of trust for modern cryptography: they generate, store and use private keys inside tamper‑resistant boundaries so signing, key custody and sensitive cryptographic operations occur without exposing private material to general-purpose software. Over the last several years, Microsoft has offered multiple HSM-backed services—Azure Key Vault (Premium), Azure Key Vault Managed HSM and Azure Cloud HSM—each targeting different tenancy, audit and sovereignty models. Marvell’s LiquidSecurity adapters are now being positioned as a certified hardware substrate behind a broader set of those services in Europe, unlocking use cases previously constrained to on‑prem QSCD (Qualified Signature Creation Device) appliances.
Marvell’s LiquidSecurity family (notably the LiquidSecurity 2, or LS2, adapters) departs from the classic 1U/2U HSM appliance model: it is a PCIe‑attached, DPU‑accelerated card designed for dense cloud racks and multi‑partition tenancy, promising high key density, lower rack and power footprint and firmware‑driven algorithm agility—attributes cloud operators prize when delivering HSM‑as‑a‑service at scale.

What Microsoft and Marvell announced​

  • Microsoft expanded the scope of Azure HSM-backed services in Europe to rely more broadly on Marvell LiquidSecurity adapters, enabling regulated and identity-sensitive workloads to run inside Azure regions with certified hardware.
  • Marvell reported that LiquidSecurity achieved eIDAS recognition for QSCD-capable signing and Common Criteria EAL4+ evaluation, alongside prior FIPS 140‑3 Level 3 validations that Microsoft has already used in other regions. These certifications were cited as enablers for identity, cross‑border contract signing, timestamping and other trust services in EU contexts.
  • The partnership is described as more than a supplier relationship: it standardizes a cloud‑native HSM hardware baseline across multiple Azure key management products, reducing the configuration friction for customers needing certified, high‑assurance cryptographic services.

Why this matters: practical implications for enterprises and governments​

For organizations that must prove legal or regulatory compliance—national identity programs, passport issuance, trust service providers (TSPs), banks and regulated industries—eIDAS and Common Criteria certifications are often gating requirements before moving sensitive signing and identity issuance to the public cloud. Making a certified HSM substrate available inside a sovereign cloud region materially reduces the operational friction of migration from on‑prem appliances to managed cloud services.
Key, immediate benefits:
  • Regulatory fit: eIDAS (QSCD) and Common Criteria EAL4+ align Azure’s HSM offerings with the legal thresholds many EU member states rely on for qualified electronic signatures.
  • Operational efficiency: moving QSCD-grade signing to Azure avoids appliance procurement, clustering, site redundancy, and complex lifecycle operations tied to on‑prem HSMs.
  • Economics and density: PCIe adapters allow cloud operators to place many HSM instances per rack server, lowering per‑key power and space costs and enabling high throughput at lower total cost of ownership.

Technical snapshot: LiquidSecurity design, claimed specs and caveats​

Architecture and compute substrate​

LiquidSecurity LS2 cards use Marvell’s OCTEON DPUs as the compute substrate for cryptographic offload, pairing programmable DPU cores with dedicated crypto engines. The architecture emphasizes:
  • PCIe form factor for server‑attached deployment.
  • Partitioning (logical tenants) within a single physical adapter.
  • Firmware updateability to support new algorithms and potential post‑quantum migration strategies.

Claimed capacity and performance​

Public technical materials and industry coverage report the following headline claims from Marvell:
  • Up to 1,000,000 hardware‑secured keys per adapter.
  • Symmetric operation ceilings advertised as extremely high (Marvell cites figures into the hundreds of thousands to more than one million operations per second for AES/GCM under certain conditions).
  • High ECC/RSA operation rates that remain competitive with many appliance HSMs but vary significantly by algorithm and key size.
Important caveats: these performance numbers are context‑sensitive. Throughput depends on algorithm mix (symmetric vs. asymmetric), key sizes, concurrency, host system configuration, PCIe topology, driver and firmware versions, and test methodology. Customers should treat vendor figures as indicative and require workload‑aligned benchmarks before capacity planning.

Certifications: what they cover — and what they don’t​

  • FIPS 140‑3 Level 3: focuses on tamper response and physical protections for cryptographic modules; previously publicized for LiquidSecurity in some contexts.
  • Common Criteria EAL4+: signals a methodical development and testing process suitable for many government and enterprise deployments, but the certificate scope, evaluator name and protection profile bindings matter for procurement acceptance.
  • eIDAS (QSCD): eIDAS QSCD designation is mandatory for some qualified electronic signature workflows; Microsoft and Marvell say the certified configurations enable QSCD‑capable services under at least one national scheme in Europe. Procurement teams must confirm the exact national scheme, certificate artifact, and whether the certified configuration matches the deployed firmware and operational processes.
Certifications are framed as necessary enablers, not substitutes for contractual or operational controls. They are configuration‑ and firmware‑specific; certificates reflect a snapshot in time and do not automatically cover future firmware updates or different operational models.

Strengths: what Microsoft’s expansion delivers well​

  • Faster path to compliant cloud services: By standardizing on a certified hardware base, Microsoft can present a ready-made compliance posture for customers that need eIDAS‑grade signing or Common Criteria coverage without building bespoke appliance fleets. This shortens procurement cycles and reduces proof‑of‑concept friction.
  • Hyperscale economics: PCIe HSM adapters reduce rack space and power per HSM instance compared with dedicated appliances, enabling Azure to offer HSM services at lower TCO for large deployments. This is commercially advantageous for both hyperscalers and customers running at transaction scale.
  • Operational consolidation: A single hardware baseline across Key Vault Premium, Managed HSM and Cloud HSM simplifies audit, certification mapping and migration paths between tiers. Customers benefit from consistent cryptographic primitives and clearer upgrade paths.
  • Firmware agility for algorithm evolution: The DPU and firmware model gives Azure and Marvell room to roll out algorithm updates, mitigations and eventual post‑quantum transitions without wholesale hardware replacements when done responsibly.

Risks and unanswered questions​

  • Certification scope and strictness: Public announcements often omit certificate numbers, evaluator names, protection profile references and exact configuration bindings. Procurement teams should demand full certification artifacts and scope statements to ensure the certification matches the intended deployment model. This gap remains a practical verification step.
  • Operational custody and legal exposure: Managed HSM models vary—some preserve customer control (BYOK/CMEK), others leave operational keys under provider custodianship. Legal and jurisdictional obligations (e.g., law‑enforcement requests, cross‑border data access) remain and must be contractually addressed. Certification does not eliminate these legal exposures.
  • Multi‑tenant isolation and side‑channel risk: High‑density, server‑attached HSMs rely on logical partitions and software isolation. While Common Criteria/EAL4+ and lab tests provide assurance, independent partition‑isolation attestations and continuous penetration testing are required because side‑channel and microarchitectural attacks are evolving threats.
  • Firmware and supply‑chain risk: DPUs and firmware‑updatable modules elevate the importance of authenticated update channels, code provenance, and incident disclosure. Organizations should require firmware signing policies, update windows, and supply‑chain attestations.
  • Post‑quantum transition: Certifications for classical algorithms do not automatically cover post‑quantum hybrids. Buyers should insist on a documented PQC roadmap and test evidence for hybrid schemes if long‑term signature validity is a requirement.

Practical verification checklist for procurement and security teams​

Treat the announcement as an enabler, not an automatic green light. At minimum, procurement and security teams should:
  • Request the full certification packages: eIDAS/QSCD artifact, Common Criteria certificate (including evaluator and protection profile), and FIPS 140‑3 certificate identifiers. Confirm firmware versions and the exact hardware model in the certified scope.
  • Confirm custody and key control model: determine which Azure HSM tier provides customer‑held keys (BYOK/Bring Your Own Key) versus provider‑managed keys, and require contract terms for key revocation, export and emergency procedures.
  • Insist on independent partition isolation attestations and recent penetration test results for the specific Azure region and HSM model you will use. Ask for test scope that includes cross‑tenant injection and microarchitectural leakage analyses.
  • Run workload‑aligned performance tests: validate latency, p99, throughput by algorithm and peak concurrency with an Azure HSM pool backed by LiquidSecurity under your real workload profile. Vendor throughput claims vary with test conditions; measure your profile.
  • Require firmware update policies and supply‑chain commitments: ask for signed firmware, rollback protections, and incident disclosure timelines for any firmware vulnerabilities or supply‑chain incidents.
  • Map legal and jurisdictional requirements: validate law enforcement, data residency, and contractual notification provisions with legal counsel for the jurisdictions where keys and operations will be used. Certification alone does not change statutory obligations.

Step‑by‑step pilot plan (recommended)​

  • Identify a non‑production workload representative of your mission‑critical signing or PKI issuance profile (document signing, e‑ID issuance, timestamping).
  • Request temporary access to an Azure HSM pool explicitly backed by Marvell LiquidSecurity in your target EU region.
  • Run end‑to‑end functional tests (signing flow, key lifecycle, revocation) and measure operational telemetry ingestion (key events, logs) and latency/throughput across algorithms.
  • Obtain the certification PDFs and independent test artifacts for the exact firmware/hardware combination you are using.
  • Validate legal and contract terms—BYOK, audit rights, breach notification, supply‑chain commitments—with legal counsel.
  • Conduct a phased migration: begin with low‑risk production workloads, monitor behavior and audits, then expand once audit and legal conditions are satisfied.

Market and strategic context​

This acceleration follows a broader industry shift where hyperscalers standardize on specialized cryptographic silicon and DPU‑powered adapters to deliver HSM‑as‑a‑service at scale. When a major cloud provider like Microsoft endorses a certified hardware baseline in multiple product lines, it creates a multiplier effect: smaller customers can consume high‑assurance services without owning hardware, and vendors that deliver certified, firmware‑managed HSM silicon stand to capture share in regulated markets. Analysts and investors have flagged HSM and HSM‑as‑a‑service as growth areas tied to data‑protection mandates, digital identity programs and confidential computing demand.
Competitors (traditional appliance vendors and other silicon suppliers) are responding with their own certification programs and managed integrations; the space will remain dynamic as governments and large enterprises continue to demand auditable, high‑assurance cryptographic services.

Critical analysis: strengths balanced with realism​

The expansion is a meaningful step forward for making certified cryptographic services practical in the cloud. By pairing eIDAS and Common Criteria assurances with a cloud‑native HSM architecture, Microsoft lowers the bar for governments and regulated enterprises to adopt managed key services. This matters for scaling national e‑ID programs, cross‑border digital signing platforms and large federated trust services that cannot afford per‑customer appliance fleets.
However, certification is only one element of risk management. The devil is in the details: certified firmware versions, protection profile scopes, legal jurisdiction clauses, and partition isolation proofs. The operational model—who controls keys, how firmware updates are handled, what audit rights exist—will determine whether a particular customer can truly rely on Azure HSM for legally binding, sovereign, or extremely sensitive uses. In short: the announcement is an important enabler but not a substitute for due diligence and contractual rigor.

Recommendations for WindowsForum readers (IT architects, security officers, procurement)​

  • Treat the expansion as a practical opportunity to reduce on‑prem appliance complexity, while insisting on formal evidence before migrating legally sensitive services.
  • Use the numbered pilot plan above to validate performance, certification scope and legal protections before large‑scale migration.
  • Require documented PQC roadmaps if your signatures must remain valid decades into the future. Demand hybrid algorithm support and transition testing.
  • Favor contractual clauses that preserve auditability, enforce firmware signing requirements, and protect key sovereignty where legal risk is material (BYOK/CMEK, explicit revocation and export clauses).

Conclusion​

Microsoft’s deeper use of Marvell LiquidSecurity HSMs in Azure Europe marks a consequential step in bringing certified, hardware‑anchored cryptographic services into the public cloud. For regulated industries, governments and trust service providers, the combination of eIDAS, Common Criteria and FIPS‑validated hardware inside Azure creates a practical pathway to cloud‑hosted qualified signatures and identity workflows that were previously locked to on‑prem QSCD appliances.
That said, certifications are configuration‑specific, and operational, legal and supply‑chain controls remain the determiners of real-world risk. Pragmatic adoption will require procurement teams to validate certificate artifacts, confirm firmware and scope, insist on independent isolation testing, and lock firm contractual protections for key custody and firmware management. When those elements are present, Azure’s Marvell‑powered HSM services can deliver scale, cost efficiency and regulatory compliance—making high‑assurance cryptography a first‑class citizen of the cloud.

Source: Investing.com Microsoft expands cloud security offerings in Europe with Marvell HSMs By Investing.com
 

Back
Top