Microsoft Killed VeraCrypt's Signing Account, Blocking Windows Updates
The encryption tool's lead developer says Microsoft terminated his account without explanation, blocking all future Windows releases and exposing a fragile dependency at the heart of open-source security software.
On March 30, 2026, Mounir Idrassi, the sole lead developer of VeraCrypt (one of the most widely used open-source disk encryption tools in the world) posted a project update on SourceForge with alarming news. Microsoft had terminated the account he uses to sign Windows drivers and the VeraCrypt bootloader. No prior warning. No explanation. No avenue for appeal. Automated replies and bots were all he could reach.
The practical fallout is immediate: VeraCrypt cannot publish new Windows releases.
Linux and macOS builds are unaffected, but Windows is where the majority of VeraCrypt's users live. The current release, version 1.26.24, is signed with a certificate authority from 2011 that is set to expire soon, raising questions about whether even existing installations will continue to function cleanly on modern Windows systems.
This isn't just a VeraCrypt story. It's a stress test for how open-source security tools survive in an ecosystem where platform gatekeepers hold the keys.
What Happened
As Idrassi described in his SourceForge post, he returned from a period of absence to discover that the Microsoft account he'd relied on for years to digitally sign VeraCrypt's Windows components had been shut down. The termination screen, which he shared a screenshot of, indicated that no appeal was possible. He tried multiple channels to reach Microsoft and received only automated responses.
404 Media noted that the move "highlights the sometimes delicate supply chain involved in the publication of open source software, especially software that relies on big tech companies even tangentially." That framing is apt. VeraCrypt is free, community-driven software with no corporate parent. Its entire Windows distribution pipeline runs through a single developer's relationship with Microsoft's signing infrastructure.
Idrassi noted that the termination impacts his work beyond VeraCrypt and has consequences for his daily job. That detail is easy to gloss over, but it matters: the person responsible for maintaining encryption software used by journalists, activists, businesses, and security-conscious individuals worldwide is also personally affected by this decision in ways that extend beyond the project itself.
Why Code Signing Matters So Much on Windows
To understand why this is more than an administrative headache, you need to understand what code signing does. On Windows, digitally signed drivers and bootloaders tell the operating system and the user, that the software comes from a verified source and hasn't been tampered with. Without a valid signature, Windows will either refuse to load the software or throw up warnings that make it look suspicious.
For encryption software, this is especially critical. VeraCrypt operates at a low level of the system, encrypting entire disks, partitions, and system drives. Its bootloader runs before Windows itself starts. That kind of access requires kernel-mode driver signatures, which Microsoft tightly controls. If the signing certificate expires or is revoked, the software can't function as intended on Windows without users disabling security features — something no responsible security tool should ask people to do.
Idrassi's SourceForge update reveals the current VeraCrypt release (1.26.24) was signed with the legacy 2011 certificate authority. That CA's impending expiration means the clock is ticking even on the existing release. Users won't lose their encrypted data overnight, but the path to receiving security patches and new features on Windows is now blocked.
A Pattern of Fragility in Open-Source Infrastructure
VeraCrypt's situation is a vivid example of a structural problem that has been building for years. Critical open-source projects often depend on infrastructure controlled by companies with no obligation to maintain access. Code signing certificates, app store listings, domain registrations, cloud hosting credits — any of these can become a single point of failure.
VeraCrypt's development history shows a project that has been consistently maintained but operates with thin margins. gHacks documented that the 1.26.18 release in early 2025 patched two security vulnerabilities on Linux, added AES hardware acceleration for ARM64 platforms, and dropped 32-bit Windows support — a pragmatic move to reduce maintenance burden. The VeraCrypt project's own news page shows a steady cadence of releases addressing security fixes, platform compatibility, and performance improvements. This is not an abandoned project. It's an actively maintained one that just had its Windows distribution capability severed.
The fact that VeraCrypt doesn't include built-in auto-update functionality compounds the problem. Users must manually download and install new versions. If the project can't produce signed Windows builds, there's no update to download, and no easy way to communicate urgency to the installed base.
What This Means for Users Right Now
If you're running VeraCrypt on Windows today, your encrypted volumes aren't suddenly at risk. The cryptography doesn't depend on Microsoft's signing infrastructure. But your ability to receive future security patches does. And if the 2011 CA certificate expires before this is resolved, you may encounter warnings or compatibility issues with future Windows updates.
On Linux and macOS, the situation is different. Idrassi confirmed in his post that releases for those platforms can still proceed. But given that Windows represents the largest share of VeraCrypt's user base, this is cold comfort for the majority.
For organizations that deploy VeraCrypt as part of their security stack, the calculus is more complicated. Enterprise environments typically require signed software. An unsigned or expired-signature build of VeraCrypt would likely be flagged or blocked by endpoint protection tools. IT departments relying on VeraCrypt for disk encryption may need contingency plans.
The Bigger Question: Who Guards the Gatekeepers?
Microsoft's decision to terminate Idrassi's account without explanation raises questions that go beyond one project. Platform companies routinely make account-level decisions that are, from the outside, indistinguishable from arbitrary. Automated enforcement systems flag accounts, terminate them, and offer no meaningful path to human review. This is a known problem in app stores, cloud platforms, and developer programs. When it hits a consumer app, it's frustrating. When it hits security infrastructure, the stakes are different.
There's no public indication that VeraCrypt did anything wrong. Idrassi's account on SourceForge, suggests a unilateral decision with no transparency. Microsoft has not, as of this writing, provided a public explanation.
This dynamic creates a chilling effect. If a well-established encryption project can lose its signing capability overnight with no recourse, what does that mean for smaller open-source security tools? Developers already operate under resource constraints. Adding the risk that a platform company can silently cut off distribution makes the calculus even harder.
What Comes Next
The VeraCrypt community is discussing potential paths forward, including obtaining a new signing certificate through a different entity. But the process isn't trivial, and it doesn't address the underlying vulnerability: a single developer's account with a single platform company was the bottleneck for delivering security software to millions of Windows users.
Long-term, this incident may accelerate conversations about alternative signing and distribution models for open-source security tools. Some projects have explored reproducible builds and multi-party signing as ways to reduce single points of failure. Whether VeraCrypt adopts such approaches will depend on resources the project may not have.
For now, the immediate priority is restoring VeraCrypt's ability to ship Windows updates. Every day that passes without that capability is a day the project's Windows users are one unpatched vulnerability away from real risk. The encryption still works. The supply chain around it is what broke.
