On a quiet Thursday morning, some of the most widely used open-source projects on the planet discovered they’d been locked out of their own distribution channels. No warning. No explanation. Just a terse notification that their Microsoft developer accounts had been suspended, their code signing certificates revoked, and their applications flagged as malware by Microsoft Defender.
The fallout was immediate. Projects including FreeDNS client Duck DNS, the privacy-focused email app FairEmail, Rustdesk remote desktop software, and the open-source Android management tool Shelter all found themselves cut off from the Microsoft Store and, in some cases, from the ability to distribute signed Windows executables entirely. For developers who had spent years building trust with their user bases, the experience was jarring — and for the broader open-source community, it raised uncomfortable questions about how much power a single platform holder wields over independent software distribution.
BleepingComputer first reported the suspensions, documenting how multiple developers received near-identical suspension notices from Microsoft citing violations of the Microsoft Store Policies. The notices were vague. Developers were told their accounts had been “identified for engagement in activities that are deceptive or harmful to Store customers, or are otherwise in violation of the Store agreement,” but specifics were scarce. Appeals were denied with boilerplate responses, and in several cases, developers reported that Microsoft’s automated systems began flagging their previously trusted applications as threats within Windows Defender SmartScreen — the security layer that warns users when they attempt to run unrecognized or potentially dangerous software.
The timing and breadth of the suspensions suggest this wasn’t a series of isolated enforcement actions. It was a coordinated sweep.
Marcel Bokhorst, the solo developer behind FairEmail — a privacy-oriented email client for Android with over a million downloads on the Google Play Store — was among the first to go public with his suspension. Bokhorst had been distributing a Windows companion tool through the Microsoft Store and using a Microsoft-issued code signing certificate. Both were yanked. His appeals went nowhere. In posts on GitHub and social media, Bokhorst expressed frustration not just at the suspension itself but at the opacity of the process. He couldn’t get a human being on the phone. He couldn’t get a clear explanation of what rule he’d supposedly broken. He was simply out.
Rustdesk, an open-source remote desktop application that has positioned itself as an alternative to proprietary tools like TeamViewer and AnyDesk, faced a similar fate. The project has been gaining traction among enterprise users and IT administrators who want a self-hosted remote access solution. Its suspension from Microsoft’s distribution infrastructure is particularly damaging because remote desktop software already faces heightened scrutiny from security tools — it’s the kind of application that, without proper code signing, gets flagged as suspicious almost by default. Losing its Microsoft-issued certificate means Rustdesk’s Windows builds now trigger SmartScreen warnings on every installation, a significant barrier for adoption in corporate environments where IT policies often block unsigned or untrusted executables outright.
Duck DNS, a free dynamic DNS service used by hundreds of thousands of hobbyists, home lab operators, and small businesses, also saw its developer account suspended. The service provides a simple client that updates DNS records to point to a user’s changing IP address — a basic networking utility. But dynamic DNS services have long been abused by threat actors to maintain persistent access to command-and-control infrastructure, and it’s possible that association was enough to draw Microsoft’s attention.
And then there’s Shelter, an open-source Android utility that uses Android’s work profile feature to isolate applications from each other. It’s a privacy tool, popular among security-conscious users who want to run certain apps in a sandboxed environment. Its connection to the Microsoft Store was minimal, but its developer account was swept up in the same wave.
The pattern here is striking. These aren’t fly-by-night operations distributing cracked software or bundling adware. These are established, widely used open-source projects with active communities, public source code, and transparent development processes. Several of them have been available through the Microsoft Store for years without incident.
So what happened?
Microsoft hasn’t provided a detailed public explanation. The company’s communications with affected developers have been limited to form letters and automated denial notices. But piecing together the available evidence, security researchers and open-source advocates have advanced several theories. One possibility is that Microsoft’s automated abuse detection systems flagged these projects based on behavioral heuristics — characteristics of the software itself (remote access capabilities, DNS manipulation, sandboxing) that overlap with techniques commonly used by malware. Another theory holds that bad actors had been distributing trojanized versions of these open-source tools through the Microsoft Store or other channels, and Microsoft’s response was to nuke the legitimate accounts rather than surgically target the imposters.
This second theory has some supporting evidence. Rustdesk in particular has been heavily impersonated by malware distributors who repackage the legitimate open-source code with added payloads. The Rustdesk team has documented numerous instances of fake Rustdesk installers being distributed through malicious ads, phishing emails, and compromised websites. If Microsoft’s security team detected a surge in malicious activity associated with the Rustdesk name or code signatures, a broad suspension might have seemed like the fastest way to contain the threat — collateral damage notwithstanding.
But that rationale, if accurate, reveals a deeply troubling dynamic. Open-source developers are being punished for the actions of criminals who abuse their software. It’s the equivalent of revoking a locksmith’s business license because burglars used the same brand of lock picks.
The broader implications extend well beyond these specific projects. Microsoft controls several critical chokepoints in the Windows software distribution pipeline. The Microsoft Store is one. Code signing certificates — which Microsoft issues through its Trusted Root Certificate Program and its own certificate authority partnerships — are another. And Windows Defender SmartScreen, which uses reputation-based scoring to determine whether an executable should be trusted, is a third. When Microsoft suspends a developer account, the cascading effects can ripple through all three systems simultaneously. An application that was trusted yesterday becomes untrusted today, not because its code changed, but because its relationship with Microsoft did.
For large commercial software vendors, this kind of disruption would be resolved quickly through dedicated partner channels and account managers. Open-source developers don’t have that luxury. They’re often solo maintainers or small volunteer teams with no commercial relationship with Microsoft beyond a free developer account. When the automated enforcement machinery turns against them, they have almost no recourse. The appeals process, as multiple affected developers have described it, is a black box. You submit your appeal, you receive a denial, and there’s no escalation path that reliably leads to a human decision-maker who can evaluate the specifics of your case.
This asymmetry of power is not new, but it’s becoming more consequential. As operating systems increasingly gate software installation behind platform-controlled trust mechanisms — SmartScreen on Windows, Gatekeeper on macOS, Play Protect on Android — the ability to distribute software independently of platform approval is eroding. For commercial developers, the cost of compliance is a line item. For open-source maintainers, it can be an existential threat.
Discussion on X (formerly Twitter) and across developer forums has been fierce. Many developers expressed solidarity with the affected projects while voicing anxiety about their own vulnerability to similar enforcement actions. “If Microsoft can do this to Rustdesk and FairEmail without explanation, what’s stopping them from doing it to any of us?” one developer wrote in a widely shared post. Others pointed to a longer pattern of Microsoft treating open-source projects as second-class citizens within its platform infrastructure, despite the company’s public embrace of open-source development through GitHub, Visual Studio Code, and its contributions to the Linux kernel.
The irony is hard to miss. Microsoft owns GitHub, the world’s largest host of open-source code. It employs thousands of engineers who contribute to open-source projects. Its CEO, Satya Nadella, has repeatedly positioned the company as a friend and partner of the open-source community. But when it comes to the actual mechanics of distributing open-source software to Windows users, the relationship looks a lot less friendly. The enforcement mechanisms are automated, opaque, and unforgiving. And the appeals process appears designed for volume, not accuracy.
Some affected developers have begun exploring alternatives. Rustdesk, for instance, has been encouraging users to download directly from its GitHub releases page and to verify checksums manually — a process that’s straightforward for technical users but a nonstarter for the average person. Others have looked into obtaining Extended Validation (EV) code signing certificates from third-party certificate authorities, which carry higher trust scores in SmartScreen’s reputation system but cost several hundred dollars per year, a significant expense for unfunded open-source projects.
There are also calls for structural reform. The Free Software Foundation Europe and other advocacy organizations have long argued that operating system vendors should not be able to unilaterally revoke the ability of legitimate software to run on their platforms. The EU’s Digital Markets Act, which imposes interoperability and fairness obligations on designated “gatekeeper” platforms, could theoretically be invoked in cases like this, though enforcement is still in its early stages and the Act’s application to developer account suspensions hasn’t been tested.
Microsoft, for its part, has begun reinstating some of the affected accounts in the days following the initial suspensions, according to updates from several developers. But the reinstatements have been piecemeal and inconsistent. Some developers reported getting their accounts back within 48 hours of the story gaining media attention. Others are still locked out. And even for those who have been reinstated, the damage to their SmartScreen reputation scores may take weeks or months to repair — during which time every user who downloads their software will see a warning screen that says, in effect, “Windows doesn’t trust this application.”
That warning, for many users, is indistinguishable from “this application is malware.” And that’s the real cost here. Not just the temporary inconvenience to developers, but the long-term erosion of trust in the applications themselves. Users who see a SmartScreen warning may never come back. Enterprise IT departments that flag an application as untrusted may never whitelist it again. The reputational damage outlasts the account suspension by orders of magnitude.
The incident also highlights a growing tension between security and openness that runs through the entire software industry. Microsoft’s SmartScreen and Store policies exist for good reason — the Windows platform is a massive target for malware, and users benefit from systems that filter out malicious software before it can do harm. But those same systems, when applied without nuance, can’t distinguish between a legitimate privacy tool and a piece of spyware that mimics one. The challenge is building enforcement mechanisms that are aggressive enough to catch genuine threats while preserving space for the kind of independent, community-driven software development that has produced some of the most important tools in computing history.
That’s a hard problem. But it’s not an unsolvable one. And the first step toward solving it is giving developers a meaningful way to contest enforcement decisions — not through automated form letters, but through a process that involves human review, clear explanations, and timely resolution. The fact that multiple high-profile open-source projects were suspended simultaneously, with no advance notice and no substantive explanation, suggests that Microsoft’s current process falls well short of that standard.
The open-source community is watching. And so, increasingly, are regulators.
WebProNews is an iEntry Publication