The editorial argues that the core problem is architectural: Microsoft's mandatory kernel-mode driver signing, introduced in Windows 10 version 1607, means one company can effectively block any security tool from functioning on Windows. This creates a single point of failure for critical open-source infrastructure like VeraCrypt.
By submitting the 404 Media article to Hacker News where it received 365 points, donohoe amplified the concern that Microsoft's unilateral termination of VeraCrypt's developer account — with no public explanation — effectively kills the tool's ability to ship updates, patches, or new releases on Windows.
404 Media's reporting emphasizes that VeraCrypt is not a niche project but the primary open-source disk encryption solution for Windows, used by journalists, security researchers, and activists who need encryption capabilities beyond what BitLocker offers. The abrupt termination with no warning or explanation puts these users at risk by halting security updates.
The editorial stresses VeraCrypt's lineage from TrueCrypt, noting its independently audited cryptographic core is among the most scrutinized encryption implementations in existence. Without signed drivers, users cannot receive security patches, leaving them exposed to vulnerabilities on a tool they depend on for plausible deniability and full-disk encryption.
The editorial highlights that Microsoft provided little or no advance warning to VeraCrypt's maintainers and has not publicly detailed its reasoning. This is described as consistent with Microsoft's pattern of opaque enforcement decisions with minimal recourse, raising concerns about platform governance and developer rights.
Microsoft abruptly terminated the developer account used by the VeraCrypt project, the most widely used open-source full-disk encryption tool and the de facto successor to TrueCrypt. The termination was reported by 404 Media and quickly shot to the top of Hacker News with a score of 365, reflecting the severity of the situation.
Without an active Microsoft Hardware Developer account, VeraCrypt cannot digitally sign its Windows kernel-mode drivers — and unsigned drivers simply will not load on modern Windows installations. This isn't a minor inconvenience. VeraCrypt's core functionality on Windows depends on a kernel driver that intercepts disk I/O to perform real-time encryption and decryption. No signed driver means no updates, no security patches, and no new releases for the Windows platform.
The termination appears to have been sudden, with VeraCrypt's maintainers receiving little or no advance warning. Microsoft has not publicly detailed its reasoning, which is consistent with how the company handles most developer account enforcement actions — opaque decisions with minimal recourse.
VeraCrypt isn't a niche hobby project. It is the primary open-source disk encryption solution for Windows, used by journalists, security researchers, activists, enterprises, and anyone who needs plausible deniability or full-disk encryption beyond what BitLocker provides. Its lineage traces back to TrueCrypt, which was independently audited and whose cryptographic core remains one of the most scrutinized encryption implementations in existence.
The core problem is architectural: Microsoft's driver signing requirement gives a single company effective veto power over which security tools can run on Windows. Starting with Windows 10 version 1607, Microsoft required all new kernel-mode drivers to be signed through its Hardware Developer Center portal. This was a defensible security decision — unsigned kernel drivers are the bread and butter of rootkits. But the enforcement mechanism is an account relationship with Microsoft, and that relationship can be terminated unilaterally.
This creates a profound tension. On one hand, driver signing has measurably reduced the attack surface of Windows systems. On the other hand, it means that the world's most-used open-source encryption tool can be effectively bricked on Windows by a single account action from its primary competitor in the encryption space (BitLocker ships with Windows Pro and Enterprise).
The conflict-of-interest angle is hard to ignore, even if there's no evidence Microsoft acted with competitive intent. BitLocker is deeply integrated into Windows and is Microsoft's preferred encryption solution for enterprise customers. VeraCrypt represents an alternative that Microsoft cannot control, audit, or monetize. Whether intentional or not, the termination removes the primary open-source competitor to a Microsoft product, using a mechanism that only Microsoft controls.
The Hacker News discussion (365 points signals strong community engagement) reflects widespread concern not just about VeraCrypt specifically, but about the broader pattern of platform gatekeeping over security-critical open-source tools. We've seen analogous situations with Apple's notarization requirements blocking open-source macOS tools, and Google Play's repeated account terminations affecting open-source Android apps.
This incident fits a pattern that every developer shipping software through platform gatekeepers should understand. The modern software supply chain has several single points of failure that are controlled by the platform, not the developer:
- Driver signing (Microsoft) — required for any kernel-mode Windows software - App notarization (Apple) — required for macOS distribution outside the App Store - Code signing certificates (various CAs) — can be revoked, often with limited appeal - Package registry accounts (npm, PyPI, crates.io) — termination kills distribution
In each case, the gatekeeping mechanism exists for legitimate security reasons. And in each case, the enforcement is opaque, the appeals process is inadequate, and the collateral damage of a false positive is catastrophic for the affected project.
Open-source security tools are particularly vulnerable because they rarely have the legal resources or corporate relationships to navigate platform disputes. A company like CrowdStrike or Symantec getting its driver signing account terminated would trigger executive phone calls within hours. VeraCrypt, maintained by a small team, has no such leverage.
If you or your organization uses VeraCrypt on Windows, here's the practical situation:
Your current installation still works. Existing signed drivers remain valid. The encryption on your disks is not compromised. Do not panic-decrypt anything.
You cannot update. Any future VeraCrypt release will not have a signed Windows driver unless the account situation is resolved or the project finds an alternative signing path. This means no security patches. If a vulnerability is discovered in VeraCrypt's Windows driver, there is currently no mechanism to ship a fix to users.
Audit your recovery keys now. If you've been putting off backing up your VeraCrypt rescue disk or volume headers, do it today. A frozen project with no update path is a risk multiplier for any existing bugs.
Consider your threat model. If you chose VeraCrypt specifically because you need features BitLocker doesn't offer — hidden volumes, plausible deniability, cross-platform containers — there is no direct replacement. If you were using VeraCrypt simply as "free BitLocker," this might be the push to evaluate whether BitLocker meets your actual requirements.
For organizations with compliance requirements around encryption tool maintenance and patching, a VeraCrypt deployment with no update path may now be a compliance finding. Document the situation and your mitigation plan.
The VeraCrypt team will likely pursue reinstatement or find an alternative path to driver signing — possibly through a different organizational account or a partner willing to sponsor the signing. The open-source community has navigated similar platform disputes before, though rarely quickly. The more important question is structural: as long as security-critical open-source tools depend on platform accounts that can be terminated without meaningful due process, this will keep happening. The VeraCrypt incident should be a forcing function for the industry to demand transparent, appealable processes for developer account enforcement — especially when the platform vendor competes directly with the affected software.
This is precisely why we can't allow platform-owners to be the arbiters of what software is allowed to run on our devices. Any software signing that is deemed to be crucial for ensuring grandma-safety needs to be delegated to independent third parties without perverse incentives.This is what th
It is not just VeraCrypt that has been affected by this. There is a bunch of Windows driver developers that have been suddenly kicked out of the "Partner Center" without explanation.https://community.osr.com/t/locked-out-of-microsoft-partner-...
We are seeing the dark side of "Security as a Service". When Microsoft simplifies the signing pipeline (like with Trusted Signing), they also centralize the point of failure. The fact that a FOSS pillar like VeraCrypt can be sidelined due to what looks like an automated account flagging is
Windscribe is now the third one to be terminated by Microsoft as well...https://nitter.net/windscribecom/status/2041929519628443943
Top 10 dev stories every morning at 8am UTC. AI-curated. Retro terminal HTML email.
A year ago I used Azure Trusted Signing to codesign FOSS software that I distribute for Windows. It was the cheapest way to give away free software on that platform.A couple of months ago I needed to renew the certificate because it expired, and I ran into the same issue as the author here - verific