Back to Home

Account blocking VeraCrypt WireGuard Microsoft

Microsoft has blocked developers' accounts of VeraCrypt, WireGuard and others in Windows Hardware Program due to unverified profiles. This has paralyzed driver updates, especially critical for system encryption VeraCrypt before CA-2011 revocation. Analysis of risks, trade-offs and recommendations for developers.

Microsoft has frozen VeraCrypt and WireGuard: what awaits Windows
Advertisement 728x90

Microsoft Blocks Open-Source Developers: VeraCrypt and WireGuard at Risk on Windows

Microsoft abruptly suspended developer accounts for key open-source tools—VeraCrypt, WireGuard, MemTest86, and Windscribe—within the Windows Hardware Program. Without a valid digital signature, driver updates for Windows cannot be released, endangering the security of millions. VeraCrypt is especially vulnerable due to the upcoming revocation of its 2011 root certificate.

Timeline of the Incident

On March 30, 2026, VeraCrypt creator Munir Idrassi discovered his account was blocked in the Microsoft Partner Center. The appeal was rejected without explanation. Similarly, WireGuard maintainer Jason Donenfeld couldn’t publish an update—his account was locked, triggering a 60-day appeal process.

Developers stress there were no prior warnings. Microsoft introduced mandatory partner verification starting October 16, 2025—30 days to comply, followed by automatic suspension. Emails were allegedly sent, but recipients never saw them.

Google AdInline article slot

Microsoft VP Scott Hanselman reached out after media coverage, promising resolution. As of now, affected accounts remain inactive.

Technical Fallout for Projects

VeraCrypt: Version 1.26.24 currently uses the Microsoft Root Certificate Authority 2011 certificate, which will be revoked in 2026. Without a new signed bootloader, full disk encryption (FDE) will fail under SecureBoot. Non-system volumes (containers, partitions) are less impacted.

WireGuard and Windscribe: The block prevents Windows patches—where most users run these tools. A critical RCE vulnerability requires 60 days to fix; Linux and macOS updates are already available.

Google AdInline article slot

MemTest86: RAM diagnostics are at risk—unsigned tools won’t launch on SecureBoot systems.

  • Key Risks:

- Security patch delays exceeding 60 days

- Failure of VeraCrypt system encryption

Google AdInline article slot

- Overreliance on Microsoft’s driver signing monopoly

- Lack of notifications about verification requirements

Why SecureBoot and Signing Matter

The Windows Hardware Program issues EV Code Signing Certificates for drivers and bootloaders. Without one, software fails SecureBoot checks—the standard on all modern PCs. Microsoft controls the root keys, making open-source projects susceptible to administrative failures.

Trade-off: SecureBoot convenience vs. flexibility. Developers must depend on a vendor whose processes are fully automated with no human oversight. This creates a tension between supply chain security and timely updates.

For senior developers: this underscores the need for multi-platform strategies. Test drivers on WSL2 or virtual machines; monitor CA revocations via Microsoft Docs.

Recommendations for Users and DevOps Teams

  • Check Status: For VeraCrypt, run veracrypt --version. If it shows 1.26.24, it’s the last signed version.
  • Monitor Updates: Watch SourceForge and GitHub repositories for official announcements.
  • Alternatives: Use BitLocker (native) for system encryption on Windows. For VPNs, consider OpenVPN with self-signed certs—but understand the risks.
  • Dev Strategy: Implement CI/CD pipelines with fallback to unsigned drivers for testing; migrate critical workloads to Linux.
  • Long-Term Plan: Consider hardware without SecureBoot or custom UEFI firmware for production environments.

Current versions still function, but unpatched vulnerabilities increase risk. For VeraCrypt users relying on system encryption, active monitoring is essential.

What Matters Most

  • Automatic account suspensions without warnings disrupted update chains for four+ projects.
  • VeraCrypt is under serious threat: revoking the CA-2011 certificate will break SecureBoot encryption without a rapid fix.
  • Open-source dependency on Microsoft’s signing process poses systemic risk across the Windows ecosystem.
  • Media pressure prompted action, but verification workflows need urgent improvement.
  • Best practice: diversify platforms and actively track CA revocations.

Broader Lessons for the IT Industry

This incident reveals the trade-offs of monopolistic code signing: security versus accessibility. Open-source projects with millions of users (VeraCrypt has over 10M downloads) shouldn’t rely on opaque processes controlled by a single vendor. Similar risks exist in Apple’s notarization and Google Play policies.

For mid-to-senior developers: implement alerts for certificate revocation lists (CRL/OCSP). In production, use dual-boot setups or containerized alternatives.

— Editorial Team

Advertisement 728x90

Read Next