The Invisible Wall: How Anti-Cheat Blocks Competitive Games on SteamOS

In the soft glow of innovation, the vision of a true “Steam Machine” — a Linux-based PC gaming future — remains alluring, like a distant lighthouse calling out to ships lost at sea. Yet, one persistent shadow stalks that future: cheating. For Valve’s dream of reshaping PC gaming, Linux’s anti-cheat problem is not just a hurdle — it may be the mountain in front of the lighthouse.

Since the release of the Steam Deck and the maturation of Proton, Valve has made impressive strides. With Proton translating Windows games to run on Linux, many titles once locked away from the Linux world are now playable. And some anti-cheat technologies, like BattlEye, have even been enabled to work in Proton, if developers opt in. Proton 6.3-8, for instance, adds support for BattlEye. These are promising technical breakthroughs, signaling that Valve is not ignoring the problem.

But the issue runs deeper than just support — it’s about trust, architecture, and adoption. Many major anti-cheat systems rely on kernel-level access in Windows. This means they need to operate with deep privileges to monitor behavior, detect cheats, and enforce bans. On Linux, things are different. Proton can translate Windows APIs, but it does not perfectly replicate the Windows kernel. Some anti-cheat systems simply can’t function in the same way, or their Linux implementations are weakened, running in user-space only, which reduces their effectiveness.

The consequences are clear: some of the biggest competitive games — Fortnite, Valorant, and PUBG among them — are not on SteamOS because studios refuse to bring them over, citing cheating risk. In 2024, EA even ended Linux support for Apex Legends, explicitly blaming “impactful exploits and cheats” on Linux platforms. Valve allowed BattlEye to be opt-in, but that relies on developers taking that step. Sometimes they don’t — and the result is exclusion for Linux users.

Worse still, there’s a tension between security and openness. The open nature of Linux, once a strength, becomes a vulnerability in the eyes of anti-cheat designers. As one academic paper points out, kernel-level anti-cheat can resemble rootkits, blurring the lines between protection and intrusion. This makes some anti-cheat companies wary, and some users uncomfortable. For Valve, enforcing a secure kernel model that supports anti-cheat might undermine the freedom and flexibility that are core to Linux’s appeal.

So what can Valve do? First, it could push harder on developers to enable the anti-cheat bridges available today. Many devs simply may not know the path to enabling BattlEye or EAC on Proton. (As some in the community point out, a nudge from Valve could go a long way.) Second, Valve could provide a more secure, sandboxed environment — maybe a signed-kernel or TPM-attested kernel — that gives anti-cheat systems more confidence without sacrificing the openness that defines Linux. Third, Valve could invest in or promote alternative anti-cheat approaches, like consensus-based detection, or less intrusive layers that are more compatible with Linux architecture.

If Valve gets this right, the implications are massive. More competitive online games could run natively (or via Proton) on its machines. The Steam Machine — or devices like the Deck — could become truly viable platforms for esports-style gaming. The idea of a Linux-based gaming ecosystem wouldn’t just be a niche or curiosity, but a real competitor to Windows gaming.

But if it fails to solve the anti-cheat problem, Valve risks leaving a gaping hole in its vision. Without strong anti-cheat support, SteamOS could remain a second-class citizen for online, competitive multiplayer — limiting its appeal and undermining the very future Valve is trying to build.

AI Image Disclaimer “Visuals are created with AI tools and are not real photographs.”

Sources Engadget Ars Technica coverage TechRaptor GoodGamesNews Critical academic