Microsoft’s cloud security architects have fundamentally reimagined how to protect data and workloads in Azure, moving from software firewalls and centralized appliances to hardware-anchored isolation baked into every new server. At the annual Hot Chips conference on Monday, Bryan Kelly, a partner security architect at Microsoft, unveiled a trio of silicon-level innovations that are now standard in Azure’s 2025 fleet: a per-server Integrated Hardware Security Module (HSM), an open-source root-of-trust called Caliptra 2.0 with a built-in post-quantum cryptography accelerator (dubbed Adams Bridge), and a layered NVMe key management specification known as LOCK. These chips don’t just encrypt data—they redefine the trust boundaries inside a cloud server, making it vastly harder for attackers to exfiltrate keys or tamper with firmware.

Why Hyperscalers Are Baking Security into Silicon

The shift to hardware-enforced security has been brewing for years. Hyperscalers like Microsoft have long relied on a stack of software controls and discrete appliances—network firewalls, virtualized key services, appliance HSMs—to secure tenant data. But the arrival of large AI workloads, brittle supply chains, and hardware-level threat models has forced a rethink. Software-only controls add attack surface and latency; centralized HSM appliances can bottleneck and create complex operational and trust relationships; and confidential computing pushes requirements for in-use protection that only hardware can fully enforce.

A forum deep-dive into the architecture identifies four guiding principles: isolate early and often by making hardware elements self-contained security domains; minimize remote trust by reducing reliance on network-attached appliances; adopt an open and auditable root of trust so device identities and attestations can be inspected by third parties; and future-proof cryptography by integrating post-quantum acceleration into silicon to avoid a painful whole‑fleet transition later. These principles crystallize in Microsoft’s new silicon triad.

The Per-Server HSM: Putting a Vault Inside Every Box

Traditional HSMs are robust cryptographic vaults used to generate and protect keys and perform cryptographic operations. In cloud datacenters they have historically been deployed as centralized or clustered appliances, but that architecture has practical drawbacks: remote access introduces latency for workloads that require frequent cryptographic operations, shared HSM clusters create scaling and tenancy headaches as AI and confidential compute workloads demand more keys, and network-attached HSMs increase the number of network trust boundaries.

Kelly explained the alternative: “They’re specialized hardware that are deployed separately in separate clusters, and this can create some challenges with scaling them as the compute and AI infrastructure is deployed.” Instead, Microsoft disaggregated HSM functionality into its latest servers, effectively making each box its own HSM. “It wouldn’t be practical to take one of those large central HSMs and try to nest it in a server, it would be like a server in a server,” he said.

The key engineering outcomes are local, in‑situ key operations that slash round‑trip latency; hardware acceleration for AES and private‑key encryption to speed encryption/decryption and signing; hardened interfaces like the TEE Device Interface Security Protocol (TDISP) that reduce the attack surface when device drivers or hypervisors interact with the module; and physical tamper resistance with fully sealed packaging that prevents exfiltration or side‑channel extraction attempts, as Kelly noted: “One of the challenges with this anti-tamper packaging is you can’t have slits or ways for probes to get in there, it has to be fully sealed.”

In practice, per-server HSMs benefit latency‑sensitive workloads such as real‑time inference and secure enclaves doing many short‑lived cryptographic operations, improve multi‑tenant isolation because keys never leave an HSM boundary cryptographically isolated from other tenants and the host OS, and simplify fleet scaling by bringing HSM capacity with each new server rather than consuming a carefully partitioned centralized pool.

Caliptra 2.0: An Open‑Source Root of Trust with Post‑Quantum Bite

A root of trust (RoT) is the immutable foundation that lets a system‑on‑chip assert its identity, attest measured boot state, and anchor firmware and platform identity. Historically, RoTs are proprietary and closed, making independent verification difficult. Microsoft, together with AMD, Google, and Nvidia, first released the open‑source Caliptra RoT in 2022. Now in its second generation, it is integrated into every new Azure server.

Caliptra 2.0 provides a unique cryptographic identity for each device, enabling attestation of boot measurements. It measures subsequent firmware components, providing cryptographic assurance that what boots is what it should be, and uses hardware barriers to protect RoT assets even from privileged host software. The open‑source nature allows security researchers and vendors to scrutinize the RTL and firmware, a practical concession to trust in an industry where black‑box roots of trust breed suspicion. Kelly argued that in standardized spaces like cryptography, openness is a strength: “Cryptography has been heavily standardized. There’s not a whole lot of room for differentiation. You want to do standard cryptography because… the first rule of cryptography, don’t write your own cryptography.”

The standout addition in version 2.0 is the Adams Bridge post‑quantum cryptography (PQC) accelerator, a hardware IP block that accelerates NIST‑selected algorithms such as Kyber and Dilithium. This enables attestation and signatures that are resilient to large‑scale quantum adversaries. Integrating PQC primitives into the RoT today means device identities remain useful as quantum capabilities evolve, avoiding expensive retrofits later.

Open‑sourcing a root of trust is a double‑edged sword. Transparency enables independent audits and collaborative hardening, but it also makes the attack surface visible. Vulnerabilities become public quickly—though defenders argue that visibility accelerates detection and fixes. Implementation subtleties like timing and side‑channel mitigations remain critical and require careful hardware validation beyond what RTL transparency can offer.

LOCK for NVMe: Key Management Anchored to Silicon

NVMe storage has evolved capabilities for host‑side key management such as Key Per I/O and encryption offload. The next step is a layered, auditable key management block for storage devices, so that device‑level keys can be controlled via higher‑level attestation and device identity. The Caliptra 2.0 module integrates the Open Compute Platform’s Layered Open‑source Cryptographic Key management (LOCK) specification for NVMe.

This enables drive‑level cryptographic isolation so that a stolen or decommissioned drive cannot reveal tenant keys; host‑to‑device key flows that are provably anchored to a device identity controlled by a verified RoT; and simpler tenant data erasure through key lifecycle operations rather than physical device sanitization. Industry coordination around LOCK is underway with major storage and cloud vendors aligning to connect RoT identity to storage‑level key flows. This is especially important for multi‑tenant hyperscale environments where physical devices may be moved, reused, or sent for failure analysis.

How the Pieces Fit Together: Isolation Across Every Plane

The architecture treats several traditionally separate planes as security surfaces: the compute plane with CPU/GPU TEEs providing memory and execution isolation between tenants; the control plane with management functions offloaded to hardened DPUs and smartNICs to reduce trust in the host kernel and hypervisor; the data plane encrypted at rest and in motion with keys bound to local HSMs; and the storage plane where NVMe drives adopt layered key management so that drive contents are worthless without keys bound to a verified RoT.

This layered isolation and separation of duties reduce the blast radius from a compromised hypervisor or management service. Even if a host OS is compromised, keys and attestation anchors remain protected inside hardware modules.

Strengths: What This Approach Gets Right

The new silicon delivers several tangible improvements. Cryptographic latency drops sharply because HSM functionality is colocated with the compute node, removing network hops for frequent crypto operations. Stronger tenancy isolation makes it much harder for co‑tenants or malicious host software to extract tenant secrets. An auditable root of trust creates an opportunity for independent verification and collaborative hardening. Early PQC support is a forward‑looking move to avoid a massive retrofit when quantum‑safe algorithms become mandatory. And the model is composable with modern hardware, recognizing that CPUs, GPUs, DPUs, and SSDs all must participate in an end‑to‑end trust story. For customers running confidential workloads, regulated data, or latency‑sensitive cryptographic operations, these are practical, not theoretical, benefits.

Risks and Gaps: Where Caution Is Warranted

The community analysis emphasizes that these advances do not erase all risks. Operational assumptions and timelines matter: shipping a chip does not instantly change the threat model for every region or instance type. Adoption across the full Azure fleet will be phased by region, SKU, and hardware refresh cycles, so enterprises must validate availability and understand fallback behaviors.

Certification and compliance details need scrutiny. Public messaging claims FIPS‑style conformity for the HSM modules, but customers should verify the specific validation levels, certificate numbers, and scope against independent records before assuming regulatory compliance. Supply chain and fabrication concerns persist because integrating logic into open‑source RTL and shipping physical silicon still relies on foundries, external IP blocks, and production test flows; adversaries at manufacturing stages or at firmware suppliers can still inject faults if provenance is not tightly controlled.

Side‑channel and physical attack vectors remain. Packaging and anti‑tamper measures are necessary but not sufficient. Side‑channel leakage (power, EM, timing) is notoriously difficult to eliminate, particularly for PQC primitives not originally designed for silicon acceleration. Publicizing the PQC accelerator RTL helps defenders and attackers alike, so careful side‑channel countermeasures and validation are critical.

Complexity of secure updates and recovery is another worry. A RoT that anchors boot and firmware must also provide safe update and recovery flows. If update paths are brittle or poorly authenticated, a locked‑down RoT can make legitimate recovery impossible or become an attack target. The balance between recoverability and tamper resistance is delicate.

Open source transparency versus exploitability requires an organized disclosure program, rapid patching, and transparent operational responses. The security story depends on the cloud provider and ecosystem vendors exercising disciplined vulnerability management. Quantum transition complexity means that while PQC acceleration lowers the cost for device identities, full ecosystem readiness—client support, certificate chains, key management tooling—remains a multi‑year project; early rollouts can create interoperability challenges.

Finally, trust and vendor control are not eliminated by per‑server HSMs. Customers trading cloud‑managed keys for on‑server HSMs must understand who controls administration and attestation. The devil is in the role‑based access controls and key‑escrow policies.

Practical Guidance for Enterprise Customers

The forum analysis offers concrete steps for organizations planning to adopt these capabilities. Validate availability and zone coverage by confirming which regions and VM SKUs include the Integrated HSM and Caliptra 2.0 features; rollout schedules vary. Ask for certification evidence: if you rely on FIPS or Common Criteria compliance, request the actual validation certificates and their scope, not just marketing claims. Incorporate attestation into deployment workflows by using measured boot checks to verify device boot state before provisioning keys or secrets, especially for ephemeral or preemptible nodes.

Plan for PQC hybridization by experimenting with PQC attestation and signing workflows while maintaining hybrid approaches for interoperability. Test client libraries and enterprise key management systems with PQC‑enabled attestations. Audit firmware and supply chain policies: seek clarity on who signs firmware, how updates are distributed, what mechanisms exist for emergency rollback, and how third parties can verify provenance. Re‑evaluate incident response playbooks, as hardware‑anchored keys change the blast radius and recovery options; update IR plans to account for hardware revocation, device‑level key rotation, and coordinated vendor disclosures. Benchmark workloads for cryptographic latency to measure real‑world impact—in many cases, you’ll see substantial latency reductions for crypto‑heavy workloads such as TLS offload, model signing, and confidential computing primitives.

The Competitive Landscape and Industry Implications

Hyperscalers have converged on the idea that hardware roots of trust and per‑server security primitives are necessary to reassure customers running high‑value workloads. What distinguishes vendors is openness, integration, and the scope of what silicon protects. Microsoft’s open‑source RoT model offers potential ecosystem interoperability: if multiple CPU, GPU, and storage vendors adopt a shared RoT design, customers can more easily verify device identity and build cross‑cloud attestations. Proprietary implementations, while perhaps more performant in the short term, risk vendor lock‑in and opaque security claims.

For chip designers and server OEMs, the move signals demand for integrated cryptographic accelerators and secure interface protocols across the board. For enterprises, the arrival of per‑server HSMs and PQC‑capable RoTs makes confidential computing a practical option rather than a niche product.

Meaningful Progress, Not a Magic Bullet

Microsoft’s per‑server HSM and open, auditable RoT with integrated PQC acceleration represent a substantive advance in cloud hardware security. The architecture reduces key exposure, lowers crypto latency, and provides a more verifiable path for attestation and device identity. The industry effort to standardize layered NVMe key management extends that protection into storage, completing more of the confidentiality stack.

However, these gains shift the attack surface: hardware fabrication, firmware provenance, side‑channel resilience, and update mechanisms become higher‑value targets. Open‑source RoTs invite more scrutiny but also accelerate vulnerability discovery. Enterprises must therefore treat these new primitives as powerful tools that must be integrated with rigorous operational controls—certificate validation, firmware monitoring, well‑drilled recovery processes, and supply‑chain verification. Organizations that understand the benefits and the residual risks, and that plan migration and verification carefully, will get tangible security and performance improvements. Those that rely on vendor messaging alone without independent validation will discover that hardware promises require an equally disciplined set of operational controls to deliver on the security they promise.