Microsoft is taking a hardware component that has always lived behind a vendor’s locked door and handing the blueprint to the public. On October 13, 2026, the company detailed plans to open-source the firmware, driver, and software stack behind Azure Integrated HSM, the server-local hardware security module it now builds into every new Azure server. Microsoft announced the effort as Project Tessera, the evolution of Azure Integrated HSM, developed with Marvell, Oracle, and the Open Compute Project. The move, described in an announcement authored by Microsoft Azure CTO Mark Russinovich under the headline “Advancing hardware security with open-source Integrated HSM technology,” marks one of the more unusual bets a major cloud provider has placed on transparency as a security strategy rather than a liability.
For an industry built on the assumption that cryptographic hardware stays proprietary precisely because obscurity is treated as a layer of defense, Microsoft’s announcement inverts that logic. The company is betting that letting outside researchers inspect the code that protects encryption keys will build more trust than keeping it sealed. It is also a bid to steer the next generation of data center hardware security standards before rivals or standards bodies do it without Microsoft at the table.
Don't miss new tech stories on Google
Add Tech Insider once in the Google app and our stories appear in your news suggestions.
What Azure Integrated HSM Actually Does
Azure Integrated HSM is a server-local hardware security module, a physical chip embedded directly into the server motherboard rather than a separate network-attached appliance. Microsoft says the component is now integrated into every new Azure server, which means the security boundary for cryptographic operations is moving from the data center rack to the individual machine. That is a meaningful architectural shift. Traditional HSMs sit in a shared pool and talk to servers over a network connection, adding latency and a shared blast radius if the appliance itself is compromised. A server-local design puts the trust anchor physically next to the workload it protects.
According to Microsoft’s announcement, keys are generated, stored, and used entirely within hardened hardware. The company states that keys are designed not to appear in host memory, guest memory, or software processes at any point during cryptographic operations. In practice, that means even a fully compromised operating system or hypervisor should not be able to lift a raw key out of memory, because the key material never leaves the chip’s isolated boundary in the first place.
This is the same threat model that has driven years of investment in confidential computing, an area where Azure Integrated HSM overlaps conceptually with the kind of workload-isolation work covered in reporting on cloud-native security gateways for Kubernetes teams. The difference is that this protection lives in silicon rather than in a software policy layer.
Inside the Open-Source Plan: Firmware, Driver, and Software Stack
The headline of the announcement is not the chip itself but what Microsoft is doing with the code that runs on it. The company says it plans to release the Azure Integrated HSM firmware, driver, and software stack as open source through the Open Compute Project, the hardware consortium that already governs open designs for servers, racks, and data center infrastructure used across the hyperscale industry. Microsoft states that the firmware is already available through a dedicated Azure Integrated HSM GitHub repository, giving outside developers and security researchers a way to read the exact code that handles key generation and cryptographic operations on Azure’s newest servers. Under the Project Tessera banner, Microsoft says the architecture, specifications, protocols, drivers, software, firmware, and reproducible build environments are being made available to the community, with a future path toward open-source silicon.
What is not yet confirmed, and what Microsoft has been careful not to claim, is that the complete hardware design itself, not just the firmware, driver, and software layers, has been open-sourced. That distinction matters. Open-sourcing the code that runs on a chip is a very different commitment than open-sourcing the chip’s physical design. Readers should treat the hardware-design question as unresolved until Microsoft or the OCP working group states otherwise.
Alongside the firmware release, Microsoft announced a new OCP workgroup specifically focused on Integrated HSM technology. The company describes the group’s scope as covering architectural design, protocol specifications, firmware, and hardware, suggesting Microsoft wants the standard-setting conversation to happen in the open rather than inside a single vendor’s product roadmap.
Why FIPS 140-3 Level 3 Is the Number That Matters
Azure Integrated HSM is designed to meet FIPS 140-3 Level 3, a federal cryptographic module standard maintained by the National Institute of Standards and Technology. FIPS 140-3 compliance is the baseline many governments, banks, and regulated industries require before they will trust a vendor with key management at all, and Level 3 specifically requires physical tamper-evidence and tamper-response, not just logical access controls. A module certified at that level has to detect physical intrusion attempts and respond by actively protecting or destroying key material, rather than simply logging the event. Microsoft describes the Tessera design as intended to enforce FIPS 140-3 Level 3 key protection throughout the key lifecycle, but the announcement frames that as a design and certification objective, and it does not establish that the open-source implementation already holds a completed certificate.
Targeting FIPS 140-3 Level 3 on a chip embedded in every new server, rather than in a handful of centralized appliances, is a harder engineering problem than it sounds. Every unit shipped has to meet the same physical tamper-resistance bar, at server scale, which is a very different manufacturing and certification challenge than hardening a small number of dedicated HSM boxes. It is also the kind of credential that security and compliance teams, the same audience evaluating tools covered in comparisons of secrets management platforms like HashiCorp Vault, AWS Secrets Manager, and Doppler, will scrutinize closely before trusting a new hardware root of trust with production keys.
The Open Compute Project Workgroup and Its Members
Microsoft is not pursuing this alone. A separate announcement reported by Yahoo Finance confirmed that Marvell, Microsoft, and Oracle have established a joint Open Compute Project working group aimed at standardizing data center hardware security, and Microsoft’s own announcement names Marvell, Oracle, and the Open Compute Project as collaborators on Project Tessera. That three-way alignment is notable because Marvell and Oracle both have their own stakes in server silicon and cloud infrastructure, and a shared OCP standard reduces the risk that each cloud provider ends up with an incompatible, proprietary approach to server-local key protection.
For an industry that has spent the last several years converging on shared infrastructure specifications, this fits a pattern already visible elsewhere in the sector, including the kind of cross-vendor coordination described in coverage of Nvidia, AMD, Google, and Meta’s joint data center specification work. Hardware security appears to be the next domain where competitors are choosing to standardize jointly rather than compete on incompatible proprietary designs, at least at the firmware and protocol layer.
Caliptra and the Silicon Root of Trust Connection
Microsoft’s announcement also name-checks Caliptra, which the company describes as a fully open-source silicon root of trust developed jointly with Microsoft, AMD, Google, and NVIDIA. A silicon root of trust is the foundational hardware component that a system checks first when it boots, before loading any firmware or operating system code, to verify nothing has been tampered with. Caliptra’s existence signals that Azure Integrated HSM is not an isolated Microsoft project but one piece of a broader, multi-vendor push toward open, auditable hardware security building blocks that multiple cloud and chip companies can adopt without re-engineering their own closed equivalents.
Pairing an open silicon root of trust with an open HSM firmware stack gives Microsoft a story that spans from first boot to runtime key management, with outside eyes able to inspect both layers. That is a different posture than the historical approach, where each layer of the security stack from a different vendor meant a different trust boundary to audit separately.
Why Vendors Almost Never Open-Source HSM Firmware
Hardware security modules occupy a strange corner of the security industry. Their entire value proposition rests on the claim that an attacker cannot extract or manipulate the keys inside them, and for decades the dominant strategy for proving that claim was to keep the internals secret and let government certification labs do the verification instead of the public. Opening the firmware source code flips that model, inviting independent researchers, academics, and competitors to look for flaws rather than relying solely on a paid certification process.
The risk calculation is real: publishing firmware source code means any undiscovered vulnerability becomes visible to attackers at the same moment it becomes visible to defenders. Microsoft’s bet is that the security community’s track record with open cryptographic standards, where widely scrutinized designs like modern TLS protocols have generally proven more resilient over time than closed ones, applies here too. It is the same logic that has driven adoption of open source scanning and policy tools covered in setup guides for products like Kyverno’s Kubernetes policy engine, where transparency of the rule logic is treated as a feature rather than a weakness.
Market Impact: Pressure on the Traditional HSM Business
The commercial HSM market has long been dominated by a small number of specialized vendors selling dedicated, network-attached appliances at a significant per-unit premium, precisely because certified hardware security hardware is expensive to design, manufacture, and certify. If Microsoft normalizes a server-local HSM built into every machine at no visible line-item cost to the customer, and simultaneously open-sources the software stack that runs on it, that undercuts two pillars of the traditional HSM sales pitch at once: the idea that dedicated hardware is a premium add-on, and the idea that the firmware inside it must remain a trade secret to be trustworthy.
That does not mean standalone HSM appliances disappear. Highly regulated workloads, multi-cloud deployments, and on-premises data centers will likely keep buying dedicated hardware for years, the same way enterprises still run on-prem identity systems alongside cloud identity platforms discussed in comparisons of Okta and Microsoft Entra ID. But Microsoft setting a new default, embedded, open-source baseline inside its own cloud puts pressure on rival hyperscalers to either match the move or explain why their key-management hardware remains closed.
Azure Integrated HSM Compared With Established HSM Approaches
The table below lays out how Microsoft’s approach differs structurally from the network-attached HSM model that has defined the market for the past two decades. Figures describing Azure Integrated HSM reflect Microsoft’s own announcement; competitor characteristics reflect long-established, publicly documented industry norms rather than Microsoft’s claims.
| Characteristic | Azure Integrated HSM | Traditional Network-Attached HSM |
|---|---|---|
| Physical placement | Embedded directly in the server | Separate appliance connected over a network |
| Deployment scope | Built into every new Azure server, per Microsoft | Shared across many servers from a central pool |
| Target certification | FIPS 140-3 Level 3 | Typically certified to FIPS 140-2 or FIPS 140-3 standards, depending on vendor and model |
| Firmware transparency | Firmware, driver, and software stack planned as open source via OCP | Firmware is proprietary and closed to outside review |
| Key exposure design | Keys designed not to appear in host or guest memory, per Microsoft | Keys isolated within the appliance; access mediated over the network link |
| Standards governance | Guided by a dedicated OCP Integrated HSM workgroup | Governed by individual vendor roadmaps and industry certification bodies |
What’s Actually Open Right Now, and What Isn’t
Announcements like this one tend to get flattened into a single headline claim, “Microsoft open-sources hardware security,” when the reality is more layered. The table below separates what Microsoft has stated as confirmed from what remains unconfirmed, based strictly on the company’s own announcement.
| Component | Status |
|---|---|
| HSM firmware | Available via the Tessera Integrated HSM GitHub presence, per Microsoft |
| HSM driver | Available as open source through the Tessera GitHub presence, per Microsoft |
| Software stack | Available as open source through the Tessera GitHub presence, per Microsoft |
| OCP standards workgroup | Announced, covering architectural design, protocol specs, firmware, and hardware |
| Full physical hardware design | Not confirmed as open-sourced; unconfirmed in Microsoft’s announcement |
| Commercial availability and pricing | Not stated in the announcement |
| Certification completion date | Not stated in the announcement |
Historical Context: From Sealed Black Boxes to Open Silicon
Hardware security modules trace back to banking and government cryptography programs of the 1970s and 1980s, where the entire design philosophy was built around physical secrecy and tamper response, verified by government labs rather than the public. That model held for decades. Even as cloud computing moved most infrastructure toward open, inspectable software, the HSM layer stayed closed, treated as the one component too sensitive for outside eyes.
The shift started cracking open gradually, through open silicon root-of-trust projects, open firmware initiatives for server baseboard management, and growing pressure from security researchers who argued that closed cryptographic hardware was harder, not easier, to trust. Caliptra, developed with Microsoft, AMD, Google, and NVIDIA, is part of that earlier wave. Azure Integrated HSM’s open-source plan extends the same philosophy one layer up the stack, from the root-of-trust chip that verifies boot integrity to the HSM firmware that manages live cryptographic keys. Seen in that light, this announcement is less a sudden reversal and more the next predictable step in a multi-year industry trend toward treating hardware transparency as a competitive security advantage rather than a liability, a trend also visible in the open-source policy and scanning tooling covered in guides to Cloudflare WAF setup and comparable open security infrastructure.
Five Predictions for Hardware Security After This Announcement
- Expect at least one other hyperscaler to announce its own open-source HSM firmware initiative within the next year, rather than cede the standards conversation entirely to Microsoft, Marvell, and Oracle’s OCP workgroup.
- Expect security researchers to begin publishing independent audits of the Azure Integrated HSM GitHub repository within months of its wider availability, since open firmware invites exactly that kind of scrutiny.
- Expect regulated industries, banking and government contractors in particular, to treat FIPS 140-3 Level 3 certification completion as the real milestone that matters, not the open-source announcement itself, since certification timing was not disclosed.
- Expect traditional HSM vendors to respond by emphasizing multi-cloud and on-premises use cases where a server-embedded, single-cloud-vendor HSM cannot compete, rather than attempting to match the open-source move directly.
- Expect the OCP Integrated HSM workgroup’s scope, covering hardware as well as firmware, to eventually produce questions about whether the physical chip design itself will ever be opened, given that Microsoft’s current announcement stops short of that commitment.
What It Means for Developers and Security Teams
For engineers building on Azure, the immediate practical change is limited: Azure Integrated HSM is already built into new Azure server hardware, so most workloads will benefit from the added key protection without any configuration change. The more interesting shift is for security teams doing vendor risk assessments. An open firmware repository gives compliance and security engineering teams a way to actually read the code protecting their keys, rather than relying entirely on a vendor’s certification paperwork and marketing claims, a capability that fits into the broader shift toward verifiable infrastructure also seen in tooling like EDR platforms from CrowdStrike, SentinelOne, and Microsoft Defender, where transparency into detection logic has become a selling point in its own right.
A simplified illustration of the design principle Microsoft describes, where key material never crosses into host-visible memory, looks conceptually like this:
// Conceptual illustration only -- not actual Azure Integrated HSM source
function signWithHsm(payload) {
// Key never leaves the HSM boundary
const handle = hsm.getKeyHandle("server-local-key");
// Signing happens inside hardened hardware
const signature = hsm.sign(handle, payload);
// Only the signature, never the key, returns to host memory
return signature;
}For teams evaluating secrets and key-management strategy more broadly, this announcement is a reminder that the key-management conversation is expanding beyond software vaults into the hardware layer itself, a shift worth factoring into any roadmap built around tools profiled in comparisons of cloud security posture platforms like Wiz, Orca, and Prisma Cloud.
The Open Questions Microsoft Hasn’t Answered Yet
Several details that would normally accompany a launch of this size are missing from the public record so far. Microsoft has not stated a completion date for FIPS 140-3 Level 3 certification, has not disclosed commercial pricing or whether Azure Integrated HSM carries any separate cost to customers, and has not published a deployment count describing how many servers currently carry the chip. The announcement also stops short of confirming whether the full physical hardware design, as opposed to firmware, drivers, and software, will ever be released under an open license through the OCP workgroup.
Those gaps matter more for enterprise buyers than the headline claim does. A security team deciding whether to lean on Azure Integrated HSM for regulated workloads will want the certification date and audit trail before the open-source narrative changes any procurement decision.
Frequently Asked Questions
What is Azure Integrated HSM?
It is a server-local hardware security module that Microsoft now builds into every new Azure server, designed to generate, store, and use cryptographic keys entirely within hardened hardware.
What is Microsoft open-sourcing exactly?
Microsoft says it plans to release the Azure Integrated HSM firmware, driver, and software stack as open source through the Open Compute Project. The firmware is already available through a dedicated GitHub repository, according to the company.
Is the physical HSM hardware design also open source?
That is not confirmed. Microsoft’s announcement covers firmware, driver, and software, but does not state that the complete hardware design has been open-sourced.
What certification level is Azure Integrated HSM targeting?
Microsoft says the module is designed to meet FIPS 140-3 Level 3, a federal standard that requires physical tamper-evidence and tamper-response, not just software-based access controls.
Who else is involved in the Open Compute Project workgroup?
Microsoft announced an OCP workgroup covering architectural design, protocol specifications, firmware, and hardware. A separate announcement reported by Yahoo Finance confirmed that Marvell, Microsoft, and Oracle established a joint OCP working group aimed at standardizing data center hardware security.
What is Caliptra, and how does it relate to Azure Integrated HSM?
Caliptra is a fully open-source silicon root of trust that Microsoft describes as developed jointly with Microsoft, AMD, Google, and NVIDIA. It represents an earlier, related push toward open hardware security that Azure Integrated HSM’s firmware release extends further up the stack.
Does this mean traditional network-attached HSMs are obsolete?
No. Dedicated HSM appliances remain relevant for multi-cloud, on-premises, and highly regulated deployments. Azure Integrated HSM changes the default inside Azure specifically, rather than replacing the standalone HSM market outright.
When will Azure Integrated HSM be fully certified and commercially available?
Microsoft’s announcement does not state a certification completion date, pricing, or a specific availability timeline, so those details remain unconfirmed as of this report.
