Is this the same thing as Managed HSM?
No. This is the part that will get muddled in every Slack channel by Thursday, so get it straight now. Azure Integrated HSM is the dedicated cryptographic module that Microsoft started fitting into its server fleet—a chip that lives next to the compute, holds keys locally, and does crypto operations without a network round-trip to a vault. Managed HSM is a single-tenant service you provision, with its own FIPS 140-3 Level 3 validation. Key Vault Premium is the multi-tenant, HSM-backed vault most people actually use.
Different layers. Integrated HSM is platform plumbing you don’t provision and can’t see in the portal. The other two are products you buy. Open-sourcing the first says nothing about the SKUs of the second two.
What actually got open-sourced—the silicon or a press release?
Per Microsoft’s own framing: hardware design, firmware, and the integration specifications. The useful word is specifications. You’re getting the design and interface contract so the module can be independently examined and reasoned about—not a bill of materials you can take to a fab and clone by Friday. Treat it as a reference and a verification target, not a build kit.
That distinction decides everything downstream. Transparency of a design is not the same as portability of a certified product.
When can I actually read the code?
That’s the catch. Microsoft announced the intent to open-source Integrated HSM but has not, as of this writing, published a specific date or a public repository URL for the hardware design, firmware, and integration specs. So the honest answer is: not yet, and there’s no committed timeline. Don’t build a review deadline around it. Watch the Azure infrastructure blog and Microsoft’s GitHub organisation for the drop, and treat any “coming soon” as exactly that until a repo with a licence and commit history actually exists.
Which of my workloads touch Integrated HSM today?
If you run anything on recent Azure hardware generations, you already do—indirectly. The module backs local key handling for the host. You don’t address it, configure it, or see it in resource inventory. There is no Microsoft.IntegratedHsm resource provider to go hunting for. So the honest answer to “which of my subscriptions depend on it” is: the ones running on servers that have the chip, which is not a knob you control.
What you can inventory is the HSM surface you do own:
Does my FIPS 140-3 or Common Criteria posture change?
No. A certification validates a specific module boundary and a specific firmware build—not the secrecy of the design around it. Publishing the design does not revoke the validation, and it does not force a re-evaluation of your deployment. Your Managed HSM stays Level 3. Your Premium vault stays whatever it was certified at. Auditors who understand FIPS already know secrecy was never the control; the validated boundary was.
If anything, this helps you in the audit room. “Trust us” becomes “read it.” That is a stronger answer to a regulator than it was last month.
Do I need to rotate keys or reconfigure anything?
No. Nothing. No key rotation, no vault setting, no opt-in, no re-enrolment. This is a transparency event, not a product change. If a vendor tells you an open-source announcement requires you to rotate keys, ask them which control changed—they won’t have an answer. Carry on with your existing rotation policy, which you should be enforcing anyway:
Does this let me run an HSM on-prem under Arc or in a sovereign build?
Not yet, and probably not the way the headline implies. A published design is a prerequisite for sovereign operators and hardware partners to verify what they’re deploying, and it lowers the trust cost of Arc-connected and sovereign topologies. It does not hand you a certified module you can rack in your own datacentre tomorrow. Certification is tied to manufacturing, firmware signing, and an evaluation lab—none of which a GitHub repo gives you. Useful for the people building sovereign stacks. Not a self-service on-prem HSM—and with no published repo yet, not even a verification exercise you can start this quarter.
Doesn’t publishing the design just hand attackers a map?
It cuts both ways. More eyes find more bugs—and some of those eyes belong to people you’d rather not have reading firmware. The counter is that a cryptographic module’s security is supposed to survive a published design; if it only held up because nobody could see it, it was never secure. Expect a wave of researcher scrutiny, expect at least one uncomfortable finding, and expect that to be healthier than the quiet alternative.
So what do I actually do about this?
Short term, nothing operational. Medium term, update your supply-chain and audit narrative to say the root-of-trust design is now inspectable, and let that do work in your next regulated-workload review. In procurement, stop accepting “proprietary, trust us” as a complete answer from any HSM vendor—the bar for transparency just moved, and you can point at it. Keep an eye on the Azure infrastructure blog and Microsoft’s GitHub org for the repository itself; until it lands, this is a promissory note, not an artefact. That’s the real blast radius: not your config, your conversations.