Skip to main content
CybersecurityHacking

Microsoft Abruptly Bans Top Open-Source Developers

Diverse group of open-source developers blocked by a faceless figure at a locked gate.

What happens when the people who sign critical open-source updates can no longer access their developer accounts? For two widely used projects, the answer was sudden, silent interruption: no emails, no warnings, and no human contact—only automated blocks and a long appeal wait.

What happened

Two leading open-source figures — developers of VeraCrypt and WireGuard — were suddenly locked out of their Microsoft developer accounts, leaving them unable to sign updates for their projects. The Register reported that the deactivations occurred without prior notice, with affected developers encountering automated systems rather than human reviewers. The article summarized the situation as “No emails, no warnings, no humans – just bots, catch-22s, and a 60-day appeals queue.”

Microsoft acknowledged the incident and told reporters it would work on how it communicates with developers after the account deactivations prevented the two maintainers from signing updates.

Why this matters

At a basic level, the event interrupted the normal maintenance and update process for two widely used open-source projects by preventing their maintainers from signing releases. For project maintainers, being unable to sign updates can halt distribution of bug fixes and security patches until account access is restored. For users, delayed or unsigned updates raise practical and security concerns.

More broadly, the episode highlights risks that can arise when account-management and verification processes are highly automated and lack timely human oversight. The reported 60-day appeals queue underscores how long remediation can take when a developer’s ability to publish is tied to a single vendor-controlled account and an automated review path.

Different perspectives

  • Technologists: The incident raises questions about resilience and fallback mechanisms for open-source maintainers who rely on third-party platforms for signing and distribution. Automated verification can reduce fraud, but the reported lack of human review created a procedural dead end for legitimate developers.
  • Policymakers and platform operators: The situation suggests a need to examine how verification systems communicate with developers and how appeals and recovery processes are staffed and timed. Microsoft told reporters it would “work on how it communicates with developers,” indicating awareness of a communications shortfall.
  • Users: End users depend on timely updates; interruptions in maintainers’ ability to sign releases can slow distribution of fixes. The reported deactivations therefore have downstream effects on software hygiene and trust.
  • Adversaries: Any delay in the routine signing and distribution of legitimate updates can create windows of opportunity for malicious actors to exploit confusion or attempt supply-chain attacks, particularly if users seek unofficial alternatives. The Register’s account emphasises the risk created by automated, non-transparent blockages.

Looking ahead

The immediate remedy for the affected projects is restoration of account access and the ability to sign updates. Microsoft has said it will improve communication with developers, but the reported 60-day appeals timeline points to a structural issue: when verification processes are opaque and automated, even brief interruptions can cascade.

How platforms balance automation against the need for speedy human intervention will shape whether this remains a one-off disruption or a recurring vulnerability for open-source ecosystems. If the systems that gatekeep signing and distribution are concentrated and slow to respond, the next takedown — accidental or malicious — could be far more consequential.

https://go.theregister.com/feed/www.theregister.com/2026/04/09/microsoft_dev_account_deactivations/