Microsoft Killed a VeraCrypt Developer Account Without Warning β€” and Nobody Knows Why

Microsoft abruptly terminated the developer account behind VeraCrypt, the world's most trusted open-source encryption tool, blocking its ability to sign Windows drivers. No explanation was given, raising serious questions about platform power, conflicts of interest, and open-source security infrastructure.
Microsoft Killed a VeraCrypt Developer Account Without Warning β€” and Nobody Knows Why
Written by Dave Ritchie

On a quiet Monday in late June, the developer behind one of the most widely trusted open-source encryption tools in the world woke up to discover that Microsoft had terminated his account. No warning. No explanation. Just a terse notification that his Microsoft account β€” and with it, his ability to sign VeraCrypt’s Windows driver β€” had been shut down.

The account belonged to Mounir Idrassi, the French developer who has maintained VeraCrypt since forking it from the abandoned TrueCrypt project more than a decade ago. VeraCrypt is used by journalists, security researchers, dissidents, corporations, and government agencies around the world to encrypt hard drives and sensitive data. It is, by most informed accounts, the gold standard for full-disk encryption outside of proprietary solutions like Microsoft’s own BitLocker.

And Microsoft just cut off its developer at the knees.

As first reported by 404 Media, the termination of Idrassi’s Microsoft account means he can no longer obtain the digital signatures required for VeraCrypt’s Windows kernel-mode driver to function properly on modern versions of the operating system. Without a valid Microsoft signature, Windows will either block the driver outright or throw alarming security warnings that would send any reasonable user running. This isn’t a minor inconvenience. It’s an existential threat to VeraCrypt’s ability to operate on Windows β€” the platform where the vast majority of its users live.

Idrassi posted about the situation on VeraCrypt’s official forums and on social media, expressing frustration and confusion. He said he had received no prior warning, no specific policy violation notice, and no meaningful avenue for appeal. Microsoft’s communication, according to his account, was generic boilerplate β€” the kind of form letter that could apply to a spammer or a malware distributor, not the maintainer of a globally recognized encryption tool with over a decade of public development history.

The timing is particularly brutal. VeraCrypt had been preparing updates to maintain compatibility with recent Windows changes. Those updates are now frozen. Every day the situation persists, the gap between VeraCrypt’s signed driver and the current state of Windows widens. Security vulnerabilities that might otherwise be patched promptly sit unaddressed β€” not because Idrassi lacks the technical ability to fix them, but because Microsoft won’t let him ship the fix.

This raises uncomfortable questions about the power dynamics at work in modern software distribution. Microsoft controls the Windows kernel-mode signing pipeline. If you write software that operates at the driver level on Windows β€” and full-disk encryption absolutely requires that β€” you need Microsoft’s blessing. There is no alternative signing authority. No workaround. The company that also sells BitLocker, a competing encryption product bundled with Windows Pro and Enterprise editions, holds unilateral veto power over whether rival encryption tools can function on its platform.

To be clear, there’s no evidence that Microsoft terminated Idrassi’s account as a competitive move against VeraCrypt. But the structural conflict of interest is impossible to ignore. Microsoft is simultaneously the platform gatekeeper, the signing authority, and a competitor in the encryption space. That arrangement demands a level of transparency and procedural fairness that, based on the available evidence, was not provided here.

The open-source security community reacted with alarm. Researchers and developers on X (formerly Twitter) pointed out that VeraCrypt has undergone multiple independent security audits, including a notable 2016 audit funded by the Open Source Technology Improvement Fund (OSTIF) and conducted by QuarksLab. That audit found vulnerabilities β€” as all audits do β€” but also confirmed the fundamental soundness of VeraCrypt’s architecture. The tool has been continuously improved since. It is not some fly-by-night project.

So why the termination?

Microsoft hasn’t said. The company did not respond to 404 Media’s request for comment at the time of their reporting. As of this writing, no public statement from Microsoft has appeared explaining the rationale. That silence is itself a problem. When a company with Microsoft’s market power takes an action that effectively disables a security tool used by millions, the burden of explanation should be high. A form letter doesn’t cut it.

There’s a pattern here that extends well beyond VeraCrypt. Platform holders β€” Microsoft, Apple, Google β€” have increasingly consolidated control over what software can and cannot run on their operating systems. Apple’s notarization requirements for macOS, Google’s Play Store policies for Android, and Microsoft’s driver signing mandate for Windows all serve legitimate security purposes. They reduce the attack surface for malware. They protect unsophisticated users from installing dangerous code. These are real benefits.

But the same mechanisms that protect users also create single points of failure β€” and single points of control. When the gatekeeper makes a mistake, or acts capriciously, or simply doesn’t care enough to explain itself, there’s often no recourse. Idrassi can appeal. He can post on forums. He can hope that public pressure forces Microsoft to act. But he cannot sign his driver. And until Microsoft decides to restore his account β€” if it decides to restore his account β€” VeraCrypt on Windows is stuck.

The implications for enterprise users are significant. Many organizations use VeraCrypt specifically because they want encryption that isn’t controlled by an operating system vendor. They want the ability to audit the source code. They want encryption that works across Windows, macOS, and Linux with the same container format. BitLocker doesn’t offer that. BitLocker is Windows-only, closed-source, and tied to Microsoft’s infrastructure. For organizations that need cross-platform encrypted volumes or that operate under compliance frameworks requiring auditable encryption, VeraCrypt fills a gap that nothing else does.

Those organizations now face an uncomfortable reality: their encryption tool’s continued viability on Windows depends entirely on the goodwill of a single company that also happens to sell a competing product. And that company just demonstrated, whether intentionally or not, that it can pull the plug without notice or explanation.

Idrassi, for his part, has explored potential workarounds. One option involves using a different Microsoft account to obtain signing credentials, though this introduces its own complications around code identity and trust chains. Another involves leveraging alternative attestation signing methods that Microsoft introduced in recent years. But none of these are quick fixes, and all of them still ultimately depend on Microsoft’s cooperation.

The VeraCrypt situation also highlights a broader vulnerability in the open-source security tooling supply chain. Many critical security projects are maintained by one person or a very small team. VeraCrypt’s Windows signing capability was tied to a single developer’s account. If that developer gets hit by a bus β€” or gets their account terminated by Microsoft β€” the entire project’s ability to ship on Windows evaporates. This is a structural fragility that the security community has discussed for years but has never adequately addressed.

Some commentators have drawn parallels to the XZ Utils backdoor incident earlier in 2024, where a malicious contributor nearly succeeded in inserting a backdoor into a widely used Linux compression library. The connection isn’t direct β€” that was a supply chain attack, and this is a platform governance issue β€” but both cases expose how thin the threads are that hold critical infrastructure together. One maintainer. One account. One decision by a platform holder. That’s all it takes.

The lack of due process is what stings most. If Microsoft had evidence that Idrassi’s account was compromised, that VeraCrypt’s signed binaries had been tampered with, or that some specific policy had been violated, saying so would be straightforward. The silence suggests either that Microsoft doesn’t have a compelling reason, or that its internal processes are so automated and opaque that no human with context ever reviewed the decision before it was executed. Neither possibility is reassuring.

And this isn’t hypothetical harm. Every user currently running VeraCrypt on Windows is affected in some way. Existing installations continue to function β€” the driver signature doesn’t expire retroactively β€” but users who need to update, reinstall, or deploy VeraCrypt on new machines will hit a wall. In security software, the inability to update is itself a vulnerability. Attackers don’t wait for bureaucratic disputes to resolve.

The open-source community has rallied around Idrassi. Donations to the VeraCrypt project reportedly increased following the news. Developers have offered technical assistance. Security researchers have amplified the story. But solidarity doesn’t sign drivers. Only Microsoft can do that.

For now, the situation remains unresolved. Idrassi continues to seek restoration of his account. The VeraCrypt project continues to develop code it cannot ship. And millions of users continue to rely on encryption software whose future on Windows hangs on the internal deliberations of a company that has said nothing.

Microsoft should fix this. Quickly, and with an explanation. Not because the internet is angry β€” though it is β€” but because the integrity of the Windows platform depends on developers trusting that the rules are clear, consistently applied, and subject to meaningful review. Right now, that trust is eroding. And unlike a terminated account, trust isn’t something Microsoft can restore with the flip of a switch.

Subscribe for Updates

ITManagementNews Newsletter

IT management news, trends and updates.

By signing up for our newsletter you agree to receive content related to ientry.com / webpronews.com and our affiliate partners. For additional information refer to our terms of service.

Notice an error?

Help us improve our content by reporting any issues you find.

Get the WebProNews newsletter delivered to your inbox

Get the free daily newsletter read by decision makers

Subscribe
Advertise with Us

Ready to get started?

Get our media kit

Advertise with Us