If you have ever switched to Linux and discovered that a game you paid for will no longer let you into an online lobby, you have run into one of the most stubborn technical and political disputes in PC gaming on Linux. The culprit, in nearly every case, is kernel-level anti-cheat software -- a class of tool that was built from the ground up to exploit features of the Windows operating system that Linux deliberately does not replicate and, in many cases, actively resists.
This is not a simple bug. It is not an oversight that a patch will fix over a weekend. The incompatibility runs through the entire architecture of how these two operating systems think about trust, access, and the relationship between software and the hardware underneath it. Understanding why requires understanding what kernel-level anti-cheat does, what Linux does differently, and why the gaming industry has largely decided the cost of bridging that gap is not worth paying -- at least for now.
What Kernel-Level Anti-Cheat Actually Does
To grasp the problem, you first need a clear picture of what these tools are actually doing. The kernel is the core of an operating system -- the layer that manages hardware resources, memory, and every process running on the machine. Code running in the kernel operates at what is called ring 0, the highest privilege level a CPU supports. Everything else -- your web browser, your game, your file manager -- runs in user space (ring 3), where it has restricted access and cannot directly touch memory belonging to another process or to the kernel itself.
Traditional anti-cheat software ran entirely in user space. The problem is that cheat developers figured out they could follow the same route into the kernel that legitimate drivers take, loading their own kernel-mode code to manipulate game memory in ways a user-space anti-cheat had no visibility into. A user-space watchdog can only see what it is permitted to see -- and a kernel-mode cheat simply lies to it, or operates below the layer it can inspect at all.
The response from anti-cheat vendors was to go into the kernel themselves. Riot Games' Vanguard, used in Valorant and League of Legends, is the most prominent example. Phillip Koskinas, Riot's head of anti-cheat, has spoken at length about the architecture in interviews with The Verge and TechCrunch between 2024 and 2025: the premise of Vanguard is that by occupying the same privilege layer as potential cheats, it can observe everything those cheats could observe and block them before they can act.
Vanguard loads a kernel-mode driver -- vgk.sys -- at system boot rather than only when the game launches. This allows it to monitor the entire boot sequence and detect any kernel-level software that loaded before it, preventing cheats from establishing themselves before the game's defenses are in position. Koskinas has been unusually public about Riot's philosophy: the company uses every security feature Microsoft and hardware manufacturers have built to protect Windows -- TPM, Secure Boot, driver signing -- and enforces that those protections are active before the game is allowed to run. From that vantage point, Vanguard can register callbacks on handle creation (blocking other processes from opening the game's memory), monitor module loading, check hardware driver integrity, enforce Secure Boot and TPM 2.0 requirements, and use hardware identifiers to impose persistent bans that survive account deletions.
The reason a system reboot is required after installing Vanguard is not a user experience decision -- it is architectural. vgk.sys is registered in the Windows service registry with a start type of SERVICE_BOOT_START, which instructs the Windows kernel loader to initialize it before the rest of the system has finished starting. At this stage, Vanguard can observe every driver that loads after it. A cheat driver that loads at the normal driver initialization phase is already entering a system that Vanguard has eyes on from the moment the kernel began executing. This boot-time positioning cannot be replicated by loading the driver after the fact -- it must be in place before the rest of the system initializes, which is why Valve's runtime Proton layer cannot bridge it.
There is significant online debate about whether Vanguard constitutes surveillance software because its driver loads at boot. This conflates two separate facts. The driver does load at boot -- that part is accurate and is the source of the reboot requirement. However, Riot's public statement, confirmed by their engineer RiotArkem in a widely-cited forum post, is that the driver does not scan system activity and does not communicate to Riot's servers unless the game client is actively running. The boot-time load is about establishing a trusted measurement baseline before other drivers can load, not about monitoring a user's non-gaming activity. That distinction does not settle the privacy debate -- a driver at ring 0 that could theoretically do anything is a legitimate concern regardless of stated intent -- but the frequent claim that Vanguard is actively spying on users 24/7 is not supported by Riot's own technical disclosure or by independent driver analysis. This article reports the architectural fact (boot-time SERVICE_BOOT_START load) accurately; the surrounding controversy is a separate question about trust in Riot's stated intentions.
Before any OS code runs, UEFI firmware measures the bootloader and verifies its cryptographic signature. Vanguard requires Secure Boot to be enabled and unmodified. A system with custom or user-added Secure Boot signing keys fails this check. On Linux, Secure Boot is frequently disabled on gaming distributions, and Valve's Steam Deck ships with Secure Boot disabled by default to allow user kernel module loading.
The Trusted Platform Module (TPM 2.0) records cryptographic measurements of every component in the boot chain -- bootloader, kernel, and early drivers. Vanguard uses this to verify the system booted without tampering. TPM 2.0 is required to run Vanguard. Linux can use TPM and IMA (Integrity Measurement Architecture) for similar measurements, but gaming distributions do not configure sealed measurement policies because doing so would prevent users from loading custom kernel modules.
The Windows kernel loader reads the service registry and finds vgk.sys registered with start type SERVICE_BOOT_START -- the earliest possible initialization phase, before most other drivers. The loader places vgk.sys first in the driver initialization queue. This positioning is the key to Vanguard's effectiveness: it is already running when everything else loads. Proton cannot replicate this because it only translates Windows user-space APIs -- the Windows kernel loader itself is not part of Proton.
At driver initialization, Vanguard reads the system's Boot GUID and SMBIOS data to build a hardware fingerprint. This fingerprint is used for hardware bans that survive account deletion and Windows reinstallation. It also reads BIOS version strings and hard disk serial numbers via IoCreateFileEx. This all happens before the desktop has loaded. There is no Linux equivalent entry point where a trusted third-party could perform this measurement with the same guarantees.
When a game launches, Vanguard sets function pointer hooks inside the HalPrivateDispatchTable -- a Windows Hardware Abstraction Layer structure stored in a writable .data section that PatchGuard does not monitor. Hooks at offsets 0x248 and 0x400 intercept every CPU context switch and system call while the game runs. This gives Vanguard visibility into all threads executing on the CPU. The hooks are removed on game exit. There is no equivalent PatchGuard-compliant hook mechanism in the Linux kernel that a third-party could use with the same scope.
Vanguard registers ObRegisterCallbacks to intercept handle creation requests. Any process that attempts to open the game's memory with read or write access rights has that request intercepted and denied. Without this kernel-layer interception, a cheat running in user space can simply call OpenProcess and read game memory. On Linux, a process with root access can access /proc/[pid]/mem to read any other process's memory -- a capability Vanguard cannot block because there is no kernel-level callback mechanism a third party can register to intercept it with verified authority.
When a game using Vanguard runs under Proton, the call to vgk.sys passes through Proton's layer and arrives at the Linux kernel. There is no vgk.sys on Linux. There is no equivalent SERVICE_BOOT_START registration. There is no Windows HAL. The game terminates with an anti-cheat error before it can connect to any server. This is not a missing feature that can be patched in Proton -- it would require reimplementing a significant portion of the Windows kernel, which is a fundamentally different project and would immediately create a new attack surface for cheat developers to exploit.
Security researchers have documented specific and unusual hooking techniques inside vgk.sys that are not widely understood outside the Windows kernel research community. Rather than using inline hooks -- which Windows' Kernel Patch Protection (PatchGuard) would detect and respond to with a forced system crash -- Vanguard hooks function pointers inside the HalPrivateDispatchTable, a structure in the Windows Hardware Abstraction Layer whose entries are stored in a writable .data section and are therefore not monitored by PatchGuard. Security researcher archie-osu documented in April 2025 that vgk.sys places a hook at offset 0x248 (the HalCollectPmcCounters entry) to intercept system calls, and at offset 0x400 (the HalClearLastBranchRecordStack entry) to hook CPU context switches through the SwapContext execution path -- a PatchGuard-compliant technique that gives Vanguard visibility into every context switch on the system while the game is running. The hooks are set when a game launches and reverted on game exit. [26]
Hardware ban enforcement relies on a fingerprint built from BIOS information collected at driver initialization: the system UUID read from SMBIOS fields, hard disk serial numbers, and other hardware identifiers combined into a hardware ID. This fingerprint persists across Windows reinstalls and new account creations, allowing bans to be enforced at the hardware layer rather than the account layer. An analysis of the vgk.sys driver confirmed it reads the Boot GUID and queries IoCreateFileEx to establish logging paths during the earliest phase of driver initialization, before any game process has launched. [27]
Other major systems follow a similar model. BattlEye (used in Rainbow Six Siege, PUBG, DayZ, and others), Easy Anti-Cheat (Fortnite, various EA titles), EA's in-house Javelin (Battlefield, EA Sports FC), and Activision's RICOCHET (Call of Duty) all include kernel-mode driver components. The specific implementation details differ, but the core principle is the same: to detect cheats that operate at the kernel level, the anti-cheat must also operate at that level.
A kernel driver registers callbacks with the OS at handle creation. When any process attempts to open a handle to the game process with permissions that allow memory read or write access, the driver can intercept and deny that request. Without kernel access, a user-space anti-cheat cannot perform this kind of enforcement -- it can only observe from the outside.
Why Linux Operates Differently
Every technical assumption that kernel-level anti-cheat relies on is either absent or fundamentally different on Linux, and most of those differences are intentional features, not gaps waiting to be filled.
Open kernel module loading
On Windows, loading a kernel-mode driver requires a code-signing certificate issued through Microsoft's Hardware Developer Center certification process. Every legitimate kernel component is signed with a Microsoft certificate, making it easy to verify authenticity. Third-party kernel drivers must be signed with an Extended Validation certificate obtainable only by companies, then certified through Microsoft's portal. This creates a meaningful (if imperfect) barrier against cheat developers loading their own kernel code, since the certificate costs money and the process leaves an auditable trail that can be quickly revoked.
Linux has no equivalent centralized gate. The kernel is open source and modifiable by the user who owns the system. Any user with root access can compile and load a kernel module. Secure Boot in Linux can restrict unsigned module loading, but it is frequently disabled -- especially on gaming-focused distributions and the Steam Deck -- and even when enabled, the chain of trust works differently from Windows. Koskinas explained the problem in a widely-cited Verge interview in late 2024: Linux lets users freely manipulate the kernel with "no user mode calls to attest that it's even genuine" -- meaning a purpose-built cheating distribution would be, as he put it, undetectable.
It is worth understanding that Windows' driver signing barrier is also not absolute -- it simply raises the cost of bypassing it. The dominant cheat-loading technique on Windows in 2024 and 2025 is Bring Your Own Vulnerable Driver (BYOVD): the attacker loads a legitimate, signed driver that contains a known vulnerability, then exploits that driver's flaw to gain arbitrary kernel memory read and write access, which is used to disable Driver Signature Enforcement or load an unsigned cheat driver directly. Common BYOVD targets have included RTCore64.sys from MSI Afterburner, which carries CVE-2019-16098 (a flaw allowing any authenticated user to read and write arbitrary kernel memory via its IOCTL interface), and mhyprot2.sys, the anti-cheat driver for Genshin Impact, which was weaponized by ransomware operators in 2022 to terminate security processes. The key point for the Linux comparison is this: BYOVD is the Windows workaround for what Linux provides openly to any root user. The attack surface exists on both platforms; it simply has different friction.
A common counterargument found in Linux gaming forums is that because BYOVD exists, Windows kernel security is just as weak as Linux and anti-cheat vendors are therefore being hypocritical in blocking Linux. This argument is technically informed but misses the point of why publishers make the decisions they do. The relevant question is not whether Windows is perfectly secure -- it is not -- but whether it provides a meaningfully higher barrier to unsigned kernel code execution that raises the cost of cheating to a level publishers find acceptable. BYOVD requires finding and exploiting a specific signed vulnerable driver, which creates a detectable pattern that anti-cheat vendors respond to with blocklists of known-vulnerable drivers (Vanguard maintains one). Loading a custom kernel module on Linux requires only root access -- a default condition on any Linux machine the user owns. The friction is different, and that friction difference is exactly what publishers are weighing. This article describes that distinction correctly; treating BYOVD and Linux root access as equivalent ignores the cost asymmetry that shapes publisher decisions.
This is the crux of the issue from a game developer's perspective. The entire value proposition of a kernel-level anti-cheat rests on the operating system providing an attestation -- a trustworthy assertion that the kernel itself has not been tampered with. Windows, for all its flaws, provides that mechanism. Linux, by design, does not make the same promise, because the Linux philosophy treats the system owner as fully authorized to modify everything about their own machine.
| Requirement | Windows | Linux |
|---|---|---|
| Kernel driver signing | Yes -- mandatory, Microsoft-issued EV certificate; revocable centrally | No -- root user can compile and load any module; Secure Boot can restrict but is not enforced on gaming distros |
| TPM 2.0 boot attestation | Yes -- required for Windows 11; Vanguard enforces it; seals measurements to hardware | Partial -- TPM hardware present on modern systems; IMA can measure; but gaming distros do not enforce sealed measurement policies |
| Secure Boot chain | Yes -- Microsoft controls root signing keys; user cannot add custom keys without disabling Secure Boot | Varies -- Secure Boot supported but user can add own MOK (Machine Owner Key); Steam Deck ships with Secure Boot off |
| SERVICE_BOOT_START hook point | Yes -- driver loads before other user processes; Windows kernel loader enforces ordering | No -- Proton does not implement the Windows kernel loader; no equivalent loading stage exists |
| Handle callback interception | Yes -- ObRegisterCallbacks; kernel enforces cross-process memory access controls | No -- root user can access /proc/[pid]/mem; no callback mechanism for third-party drivers to block it |
| Hypervisor-based integrity (VBS/HVCI) | Yes -- Windows 11 enforces all kernel code is signed at hypervisor layer; basis of Windows endpoint security platform | Partial -- KVM hypervisor mature; no equivalent centralized attestation chain; gaming distros not configured with HVCI constraints |
| IOMMU enforcement for DMA | Yes -- FACEIT mandates IOMMU since 2025; enforced via Windows platform; blocks FPGA DMA attacks | No -- IOMMU available in kernel; gaming distros do not enforce PCIe device isolation; VFIO passthrough mode actively disables it |
| VM detection | Yes -- Vanguard blocks virtual machine environments; requires bare metal hardware | Harder -- KVM can be configured to hide guest status; VM detection is an ongoing arms race with hypervisor developers |
No Proton kernel shim for drivers
For Windows games that do not use kernel-level anti-cheat, Valve's Proton compatibility layer -- built on top of Wine -- provides a translation layer between Windows API calls and the Linux kernel. This is why thousands of Windows-only games run on Linux and the Steam Deck without any developer involvement. Proton intercepts calls to Windows user-space APIs and libraries and redirects them to their Linux equivalents.
The problem is that Proton only implements the Windows user-space environment. It does not implement the Windows kernel. When a game makes a call to a kernel-mode driver -- as games using kernel-level anti-cheat inevitably do -- that call passes straight through Proton's layer and arrives at the Linux kernel, which has no idea what it is being asked. The Windows kernel driver the anti-cheat expects to be present simply does not exist in that environment. As a widely cited technical analysis of the problem summarized it, the anti-cheat client will be making calls to "a kernel driver that doesn't exist" -- Proton provides a matching user-space API but never implements the Windows kernel itself.
This is not a solvable problem within Proton's current architecture. Providing a shim for a Windows kernel driver would require implementing a significant portion of the Windows kernel inside Linux -- a different project by several orders of magnitude, and one that would immediately create a new surface area for both security researchers and cheat developers to exploit.
The macOS comparison -- and why it matters for Linux
The architectural difference between Linux and Windows regarding kernel access is best illustrated by what Riot itself did with macOS. In January 2025 (patch 25.S1.2), Riot deployed an "Embedded Vanguard" build for macOS League of Legends that functions without a standalone kernel-mode driver. Instead, it operates within the application bundle, leveraging macOS's layered security model -- specifically the system's deeply restricted kernel extension policy, which Apple controls centrally. Riot's own head of anti-cheat acknowledged that macOS's ecosystem is "substantially different" and that implementing a standalone kernel driver simply is not possible there the way it is on Windows.
This is the precise argument Linux users have made for years: that a platform's security model can support anti-cheat integrity without a ring-0 driver if the OS itself provides meaningful constraints. The difference is that macOS enforces those constraints through Apple's control over the entire hardware and software stack, while Linux's constraints are chosen by the system owner. From a game developer's perspective, macOS attestation is trustworthy because Apple controls it; Linux attestation is not, because the user controls it. The macOS precedent proves that kernel drivers are not technically required to ship Vanguard -- but it does not change the Linux equation, because the trust model that makes the macOS approach viable does not exist on Linux.
Virtual machine detection
Another path Linux users might try -- running Windows inside a virtual machine with GPU passthrough to play games that require kernel anti-cheat -- is also blocked by tools like Vanguard. VM detection is a standard feature of kernel-level anti-cheat, since a virtual machine provides an attacker with the ability to inspect the entire guest's memory from the host layer without the guest OS being able to detect it. Vanguard in particular blocks virtual machine environments and requires direct access to the bare metal hardware, which means cloud gaming services and most VM setups fail at launch.
Why eBPF and seccomp are not a substitute
A question that comes up in technical discussions is whether Linux's own kernel-level introspection tools -- specifically eBPF (extended Berkeley Packet Filter) and seccomp (secure computing mode) -- could serve as the foundation for a Linux-native anti-cheat implementation that satisfies the requirements of vendors like Riot. The short answer is: not in any form that currently exists, and not without solving the attestation problem first.
eBPF allows unprivileged programs to attach instrumentation probes throughout the kernel, inspecting system calls, network packets, and memory maps in real time without modifying kernel source code. From a technical capabilities standpoint, a well-written eBPF-based anti-cheat could in theory perform many of the same observations as a Windows kernel driver: watching for suspicious handle creation, monitoring ptrace calls, detecting /proc/[pid]/mem access attempts, inspecting loaded kernel modules. Several researchers have prototyped eBPF-based rootkit detectors that demonstrate this is feasible at the visibility level.
The problem is that eBPF's access model is the inverse of what an anti-cheat vendor requires. eBPF programs run with the permission of the system owner, not with Microsoft-style attestation. A cheat developer on Linux can load their own eBPF program that interferes with or spoofs the output of the anti-cheat's eBPF probes. They can disable the probes entirely if they have root. They can write a custom kernel module that bypasses the hook points eBPF uses. The tooling works, but the trust model is absent. seccomp has the same limitation from the opposite direction: it restricts what a process can do, not what external observers can see. Applying seccomp to a game process could theoretically limit certain cheat behaviors, but a kernel-mode cheat operates above the seccomp layer and is invisible to it.
The only Linux kernel feature that could theoretically provide the attestation layer anti-cheat vendors require is Integrity Measurement Architecture (IMA) combined with a properly configured Secure Boot chain where the user cannot add their own signing keys. IMA allows the kernel to measure and attest to the integrity of files before they execute. If a distribution were configured with IMA in strict mode, a locked-down Secure Boot implementation that the user cannot override, and a TPM-sealed measurement policy -- conditions that describe a consumer appliance, not a general-purpose Linux system -- it would theoretically be possible to build an attestation model anti-cheat vendors could trust. The Steam Deck in its locked mode approaches this configuration, but Valve chose not to lock it down, and the Linux community would reject a distribution that did. The capability exists technically; the ecosystem will not accept the configuration required to use it for this purpose.
The Casualty List: Games Lost and Blocked
The practical effect of this incompatibility has grown dramatically since 2022, as more publishers deployed or upgraded to kernel-level systems. The shift from user-space anti-cheat to kernel-mode anti-cheat often happens mid-life for a game, meaning players who purchased titles years earlier and played them on Linux without issue found themselves suddenly locked out after a routine update.
Valorant was never available on Linux. Vanguard's kernel-mode vgk.sys driver is baked into the game's launch requirements, and Riot has stated repeatedly there are no plans for a Linux build. The situation worsened in 2024 when Riot expanded Vanguard to League of Legends, ending years of unofficial Linux play through Wine and Proton. According to a Rioter who posted internal data in a 2020 forum thread, roughly 700 Wine users were playing League daily at that time, generating approximately 6,000 game sessions per day. By the 2024 rollout the figure had shifted, with Riot internally citing around 800 daily Linux players -- a small number against a global player base in the tens of millions, but a community that had existed and functioned for years entirely through unofficial workarounds.
Grand Theft Auto V Online suffered a high-profile casualty event in September 2024 when Rockstar Games integrated BattlEye into the game's online component -- nine years after the original release. Steam Deck users who had been playing GTA Online for years found themselves locked out overnight. The Rockstar support page framed the situation oddly, stating that "Steam Deck does not support BattlEye for GTA Online," placing responsibility on Valve rather than on Rockstar's own configuration. BattlEye does in fact support Linux natively -- the vendor has published that support for Steam Deck is opt-in for developers. Rockstar had simply chosen not to enable it.
Apex Legends went further in October 2024. Electronic Arts and Respawn announced that players on Linux and the Steam Deck would be entirely removed from the game, not merely blocked from certain modes. EA had previously allowed Easy Anti-Cheat to run under Proton for Apex Legends in user-space mode. Rather than enabling EAC's kernel-mode enforcement, EA chose to block Linux at the OS identification level. In the official blog post, community manager EA_Mako wrote that "the openness of the Linux operating systems makes it an attractive one for cheaters and cheat developers" and stated that "there is currently no reliable way for us to differentiate a legitimate Steam Deck from a malicious cheat claiming to be a Steam Deck (via Linux)." That inability to distinguish hardware -- not a kernel driver rollout -- is what ended Linux access. EA had previously allowed Easy Anti-Cheat to run under Proton in user-space mode; the user-space implementation that had maintained Linux compatibility was simply abandoned in favor of an outright OS ban.
Many community discussions frame the Apex Legends block as EA requiring a kernel-level anti-cheat that Linux cannot run. That is not what happened. EA did not upgrade Apex to a kernel-mode EAC deployment. EA revoked access entirely at the OS identification layer -- meaning the game checks what operating system is running and refuses to connect if it detects Linux, regardless of whether EAC is running or not. The reason given in EA's own public statement was the inability to distinguish a legitimate Steam Deck from a cheat that spoofs Linux OS identification. The block therefore reflects a trust and attestation problem, not a kernel driver technical requirement. This matters for how readers interpret the broader article: Apex Legends is an example of the attestation failure mode, not an example of the kernel driver incompatibility mode. Both categories exist; Apex belongs in the first one.
Earlier in 2024, Battlefield 1 underwent a similar transition when EA deployed its Javelin anti-cheat, retroactively breaking Linux and Steam Deck access to a game released in 2016. This pattern -- a retroactive kernel-mode upgrade locking out players who had previously been able to play -- is one of the most disruptive aspects of the compatibility problem. Players cannot make an informed decision at time of purchase about a game's future anti-cheat posture.
According to Are We Anti-Cheat Yet, a community-maintained database tracking game anti-cheat status on Linux, over 680 games do not function on Linux for anti-cheat-related reasons as of late 2025. The list includes some of the highest-concurrent-player games on Steam: PUBG (BattlEye), Call of Duty: Warzone, Black Ops 6, and Black Ops 7 (RICOCHET), Rainbow Six Siege (BattlEye), and EA Sports FC (Javelin). Destiny 2 dropped Linux support entirely when it migrated to BattlEye in 2022.
Valorant and League of Legends (Vanguard, ring-0, boot-time driver) -- GTA Online (BattlEye, Linux support not enabled by Rockstar) -- Call of Duty: Warzone, Black Ops 6, and Black Ops 7 (RICOCHET, no Linux support) -- Rainbow Six Siege (BattlEye, no Linux support) -- Apex Legends (EAC, Linux access revoked October 2024) -- Destiny 2 (BattlEye, Linux support dropped 2022) -- EA Sports FC series and Battlefield titles (Javelin, no Linux support).
Where It Does Work -- and Why
Not every anti-cheat on Linux is a wall. The reason some games work and others do not comes down to a specific architectural decision: whether to run the anti-cheat's Linux presence in user space or to require kernel-mode access.
BattlEye and Easy Anti-Cheat both have Linux-compatible user-space implementations that can be enabled by developers on a per-title basis. Valve worked directly with both vendors ahead of the Steam Deck launch in 2022 to make this technically feasible. For EAC, Valve coordinated with Epic Games; for BattlEye, the integration was built so that a developer only needs to contact BattlEye and toggle a setting -- no additional development work is required on the game's side. Operators running DayZ servers on Linux have additional server-side anti-cheat tooling available that works independently of the client-side BattlEye decision.
The result is that games like Elden Ring, Deep Rock Galactic, MONSTER HUNTER: WORLD, and a growing list of others using EAC or BattlEye in user-space mode work on Linux through Proton. Valve's own anti-cheat, VAC, operates in user space and is fully supported, which is why Counter-Strike 2 and Dota 2 are playable on the Steam Deck without issues.
The critical distinction is that these user-space implementations do not have the same enforcement capabilities as their kernel-mode counterparts. From the anti-cheat industry's perspective, running without a kernel driver means accepting a weaker posture against sophisticated cheaters who do operate at the kernel level. The games that choose to enable Linux compatibility via user-space anti-cheat are accepting that trade-off, either because their player base priorities it, or because the cheat ecosystem targeting their game does not yet justify escalating to kernel enforcement.
Some community sources argue that EAC and BattlEye in user-space mode are "good enough" and that publishers blocking Linux are making a political rather than a technical decision. This contains a grain of truth but overstates the case. User-space anti-cheat is effective against the broad population of cheats targeting casual or semi-competitive games -- which is why it works acceptably for Elden Ring and Deep Rock Galactic. For the highest-stakes competitive titles, where financial incentives for cheating are substantial (account boosting, esports cheating, black-market in-game economy manipulation), the additional hardening that a kernel driver provides against sophisticated kernel-mode cheats is the specific thing developers are paying for. Whether a given publisher is making that trade-off calculation correctly is a legitimate debate. What is not accurate is the claim that user-space and kernel-mode implementations offer equivalent security posture -- the entire reason the industry moved to kernel-mode anti-cheat in the first place was that user-space was losing that arms race.
For Riot, EA, and Activision -- whose games are large-scale competitive titles with substantial financial incentives for cheating -- that trade-off is not acceptable. This creates the disparity where a small indie game using EAC works fine on Linux while one of the largest competitive shooters in the world does not.
The CrowdStrike Angle and Microsoft's Response
The kernel-level access problem is not unique to gaming. In July 2024, a faulty content update to CrowdStrike's Falcon security sensor -- a kernel-mode driver used in enterprise security -- triggered a global IT outage that crashed millions of Windows machines with the blue screen of death. Airlines grounded flights. Hospitals canceled procedures. The incident threw into sharp relief exactly what can happen when third-party code runs at ring 0.
Microsoft's response was significant and developed through late 2024 and into 2025. Following the Windows Endpoint Security Ecosystem Summit in September 2024, Microsoft VP David Weston outlined the company's intent to build new platform capabilities allowing security vendors to operate outside of kernel mode. In November 2024, Microsoft formalized this as the Windows Resiliency Initiative, which included a commitment that endpoint security software could run in user mode just as regular applications do. That commitment became concrete: in June 2025 Microsoft announced a new Windows endpoint security platform and a private preview launched for Microsoft Virus Initiative (MVI) partners in July 2025, on the one-year anniversary of the CrowdStrike incident. Participating vendors include Bitdefender, CrowdStrike, ESET, SentinelOne, Sophos, Trellix, Trend Micro, and WithSecure. The initiative also introduced MVI 3.0, requiring all participant vendors to follow Safe Deployment Practices, use gradual rollouts with deployment rings, and conduct additional testing per Windows update -- directly addressing the failure modes that caused the CrowdStrike outage.
For the gaming world, this development carries potential structural implications. If Microsoft successfully moves endpoint security tools out of the kernel by providing robust user-space hooks with kernel-level visibility, the technical argument for requiring kernel drivers in anti-cheat could weaken. Anti-cheat vendors could theoretically use the same mechanisms and achieve comparable protection without needing a ring-0 driver at all.
Koskinas acknowledged this direction in comments reported by The Verge in late 2024: if Windows broadly requires virtualization-based security or hypervisor code integrity features, Riot could leverage those to enforce protection without a ring-0 driver -- effectively allowing Vanguard to "recede from the kernel space." Vanguard has since announced changes that allow its driver to start only when the game launches (rather than at system boot) for users running full Windows 11 security features -- reflecting that even Riot's approach is not architecturally fixed. The July 2025 Windows endpoint security platform preview is the first concrete step toward that architectural shift, and security vendors are now actively building products designed to run outside kernel mode.
Whether any of this helps Linux is a separate question. The post-CrowdStrike architectural shift is happening within Windows. Linux is not part of that ecosystem, and developers moving away from Windows kernel drivers would still have no incentive to build equivalent Linux-compatible tools unless the platform's market share and cheat threat profile justified the investment.
Windows 11 introduced Virtualization-Based Security (VBS) and Hypervisor-Protected Code Integrity (HVCI) as default-on features on compatible hardware. VBS isolates a trusted execution environment from the main OS using the CPU hypervisor -- the same layer that runs virtual machines. HVCI enforces that kernel-mode code must be signed and unmodified at the hypervisor level, making it significantly harder to load unsigned or tampered kernel modules even with admin access. Vanguard's boot-time driver and its enforcement of Secure Boot and TPM 2.0 are, in part, checking that this security stack is active and intact. The Windows endpoint security platform extends this: if VBS and HVCI are active and the hypervisor can provide tamper-evident attestation, a security product no longer needs its own ring-0 driver to make integrity guarantees -- it can ask the hypervisor. This is the architectural shift that could eventually make kernel drivers unnecessary for effective anti-cheat on Windows. Linux has an equivalent technology stack -- KVM, the Linux hypervisor, is mature and widely deployed -- but there is no equivalent of Microsoft's centralized attestation chain, and gaming distributions are not configured with HVCI-equivalent constraints by default. The capability gap is institutional, not technical.
The Market Share Trap
The business argument developers and publishers use to justify not supporting Linux follows a circular logic that has proven remarkably durable. Linux has grown substantially as a Steam platform: the November 2025 Steam Hardware Survey recorded Linux at an all-time high of 3.20%, with December 2025 revised figures placing it at 3.58% -- up from below 1% before the Steam Deck launched in 2022. The March 2026 Steam Hardware and Software Survey recorded Linux at 5.33%, crossing the 5% mark for the first time in the platform's history, according to reporting from KitGuru, Phoronix, and WCCFtech. As analysts and community observers have noted, the March figure likely reflects a survey sampling anomaly tied to Windows 10's end-of-life transition driving a spike in SteamOS adoption, and some correction is expected in subsequent months -- but even on a normalized basis, Linux is now approaching or above 3.5% of Steam's active base on a sustained trend. In absolute terms at Steam's scale of over 130 million monthly active users, that represents between 4 and 7 million active Linux players depending on which month's data is used. Yet providing Linux support for kernel-level anti-cheat specifically requires either developing a new Linux kernel driver (expensive, technically complex, and subject to continuous cheat-ecosystem counter-development) or accepting a user-space-only posture. For publishers of large competitive free-to-play titles, that calculation has not changed. The financial case still does not compute for them.
Before the Steam Deck launched in February 2022, Linux accounted for below 1% of Steam users. By December 2025, Valve's revised Hardware Survey figures put Linux at 3.58%, surpassing macOS at 2.18%. The March 2026 Steam Hardware and Software Survey recorded Linux at 5.33% -- the first time the platform has crossed 5% -- driven largely by a spike in SteamOS adoption tied to Windows 10's end-of-life. Analysts including Phoronix note the figure is likely a sampling anomaly and expect some correction in subsequent months; the sustained underlying trend puts Linux in the 3--4% range. SteamOS Holo (the Steam Deck OS) accounts for approximately 24-26% of all Linux gaming installations. In absolute terms, applying 3.58% to Steam's 130+ million monthly active users represents roughly 4.6 million players; the March spike extrapolation reaches approximately 7 million. [Sources: 18, 21, 23, 24]
The circularity is that Linux's gaming market share is partly low because games do not support it. Developers who might switch to Linux for daily use often keep a Windows installation solely for gaming. Users who might buy a Steam Deck find significant portions of their library unplayable online. The Steam Machine -- Valve's dedicated Linux gaming hardware initiative -- faces this exact problem as its potential audience: as Engadget noted in November 2025, anti-cheat incompatibility "will remain a thorn in Valve's side" because kernel-level solutions are increasingly prevalent and developers of large free-to-play competitive titles have shown no appetite for moving away from them.
EA's March 2026 job posting for a Senior Anti-Cheat Engineer on its SPEAR (Secure Product Engineering and Anti-Cheat Response) team is more significant than it first appears. The role's primary objective is developing a native ARM64 driver for Javelin -- timed to the anticipated debut of Nvidia's N1/N1X ARM-based laptop chips -- but one listed responsibility names Linux and Proton explicitly as future OS targets for Javelin. The exact phrasing from the job listing was to "chart a path for EA Javelin Anticheat to support additional OS" including Linux and Proton. It is worth noting the precision: Linux knowledge appears in the listing under "bonus skills," not core requirements. The primary technical qualifications are Windows and ARM expertise. This correctly frames the Linux work as a future research trajectory rather than an active current development sprint -- but that distinction does not diminish the significance of the language being there at all.
The direct naming of Linux and Proton in a formal job description represents something no major publisher with a blocked kernel-level anti-cheat has done before: put it on paper. Javelin was launched to protect Battlefield 6 and has blocked over 580,000 cheating attempts by EA's own account, giving the company both a mature system and institutional motivation to expand it rather than replace it. EA's track record -- removing Apex Legends from Linux in October 2024 and breaking earlier Battlefield titles on the Steam Deck -- requires that optimism here be tempered, but the signal is concrete and publicly documented.
The Security and Privacy Dimension
There is another angle to this story that is specific to Linux users: many of them would not want kernel-level anti-cheat running on their machines even if it worked correctly. The Linux community tends to have higher-than-average awareness of system security and privacy, and the concerns around kernel-level anti-cheat are legitimate regardless of platform.
A kernel-mode driver operates at the highest privilege level of the CPU. A vulnerability in that driver -- a buffer overflow, an unchecked pointer, an exposed ioctl interface -- is not just a program crash. It is a potential full system compromise. The CrowdStrike incident demonstrated at scale what a buggy kernel driver can do even without any malicious intent. Vanguard has itself shipped with bugs that caused BSODs and system instability on various hardware configurations during its rollout to League of Legends in 2024.
The concern is not theoretical. Independent security researchers have documented multiple popular kernel drivers present on ordinary gaming PCs -- including those shipped with MSI Afterburner and CPU-Z -- that contain vulnerabilities allowing any user-space process to read and write arbitrary kernel memory. A vulnerable anti-cheat driver provides a different but equally real attack surface. On Linux, the ability to audit the software running on your system, the absence of closed-source binary blobs loaded at boot, and the user's authority over their own kernel are all features. The kernel-level anti-cheat model asks Linux users to surrender those features for the privilege of playing a competitive video game, which for many is simply not a trade they are willing to make even if it were technically possible.
The Hardware Attack Frontier: DMA Cheats, IOMMU, and What Linux Exposes
Kernel-level anti-cheat on Windows is increasingly fighting a threat that software alone cannot solve: Direct Memory Access (DMA) attacks using FPGA hardware. A DMA cheat uses a second computer connected to the gaming PC via PCIe -- or via an M.2 slot with an adapter -- to read the game's physical memory directly over the PCIe bus. Because the operation bypasses the CPU entirely and requires no software running on the target machine, it is invisible to any software-based detection. The cheat runs entirely on the second machine and reads enemy positions, health, and game state out of the gaming PC's RAM without touching a single process or driver on the gaming system itself.
This threat class has been escalating since the PCILeech framework (Ulf Frisk, 2016) made FPGA-based memory acquisition accessible beyond specialized security researchers. By 2024, consumer-grade FPGA boards with modified firmware were widely available to cheat developers, and the anti-cheat industry began responding in kind. Vanguard deployed a PCIe slot scanning update in January 2024, enumerating attached PCIe devices and using randomized A/B functional tests to detect boards that claim to be legitimate hardware (USB controllers, network cards, audio devices) but fail to behave like the hardware they are impersonating. The arms race between FPGA firmware developers spoofing device identifiers and anti-cheat PCIe enumeration has been publicly documented in detail. [28]
The hardware-level defense against DMA attacks is the IOMMU (Input-Output Memory Management Unit) -- Intel calls it VT-d; AMD calls it AMD-Vi. The IOMMU functions as a hardware firewall for system RAM, enforcing that PCIe devices can only access memory regions the operating system has explicitly granted them via device-specific page tables. A DMA attack device that is not associated with any OS driver has no IOMMU mappings and therefore cannot access arbitrary physical memory -- the hardware itself blocks the read at the bus level before it reaches RAM.
The competitive gaming industry crossed a significant threshold in late 2025. FACEIT, the competitive matchmaking platform used for professional and high-level Counter-Strike 2, mandated IOMMU as a universal hardware requirement. Starting in August 2025, IOMMU was enforced for all players above 3,000 Elo. From November 25, 2025, TPM 2.0 and Secure Boot became mandatory for all FACEIT players without exception, alongside continued IOMMU rollout. FACEIT's official documentation described IOMMU as blocking "DMA-card cheats from reading protected game memory" and stated explicitly that IOMMU combined with Virtualization-Based Security (VBS) is their enforcement mechanism for hardware-level integrity. Windows 11 will be required to play FACEIT from October 2026, aligned with Microsoft's end-of-security-updates date for Windows 10. [29]
None of this infrastructure exists on Linux in any form applicable to gaming. IOMMU is available in the Linux kernel and is widely used in enterprise and server environments, but gaming distributions -- including SteamOS -- do not configure or enforce IOMMU for PCIe device isolation by default. The Linux kernel's IOMMU passthrough mode, used in VFIO GPU passthrough setups, deliberately disables device isolation to improve performance. A Linux gaming system with an FPGA DMA board inserted is, from a detection standpoint, exactly as open as it would be without any anti-cheat running at all. The FACEIT IOMMU requirement is a Windows-only enforcement mechanism, and the entire hardware attestation chain it relies on -- TPM measured boot, UEFI Secure Boot with no user-added signing keys, IOMMU enforcement -- is contingent on the OS and platform enforcing it. Linux does not, and in many configurations deliberately cannot without ceasing to be a general-purpose system.
Two contradictory narratives circulate online about DMA cheats: cheat vendors claim their boards are fully undetectable, while some anti-cheat commentary claims Vanguard's PCIe scanning has solved the problem. Neither is the complete picture. Vanguard's January 2024 PCIe scanning update did significantly raise the detection bar for commodity DMA boards using stock FPGA firmware and known-bad device identifiers -- and bans from it have been publicly documented. However, DMA boards with custom firmware that accurately impersonates legitimate hardware at the PCIe level remain an active challenge, and the anti-cheat community describes the current state as an ongoing arms race rather than a solved problem. FACEIT's IOMMU mandate is a different and more fundamental approach: rather than trying to detect a spoofed DMA board after it is installed, IOMMU prevents it from accessing RAM in the first place. This article describes both the Vanguard PCIe scanning and the IOMMU approach accurately as distinct mechanisms with different strengths; the "fully solved" and "completely undetectable" framings both overstate their respective cases.
When IOMMU is active and a PCIe device has no OS driver, it has no IOMMU address mappings and cannot access physical memory. Anti-cheat systems use this to block FPGA DMA boards that impersonate legitimate hardware devices. Without IOMMU enforcement, any PCIe device can request bus-mastered DMA access to arbitrary physical memory addresses, and the CPU has no mechanism to intercept the read. Gaming motherboards have historically shipped with IOMMU disabled by default for performance reasons. FACEIT became the first major competitive platform to make IOMMU a universal player requirement, beginning staged enforcement in April 2025 and completing it progressively through late 2025. [29]
What peer-reviewed research actually says about kernel anti-cheat
The technical security community has produced a small but precise body of academic work on kernel anti-cheat that deserves mention here because it contextualizes both the Windows and Linux questions in ways that gaming coverage typically misses.
A 2024 paper by Christoph Dorner and Lukas Daniel Klausner, presented at the ARES 2024 conference in Vienna (published by ACM, doi:10.1145/3664476.3670433), systematically evaluated BattlEye, Easy Anti-Cheat, FACEIT Anti-Cheat, and Vanguard against a seven-metric taxonomy of rootkit behavior: evasion, virtualization detection, execution time relative to system boot, remote access capabilities, information exfiltration, network manipulation, and removability. The paper found that FACEIT Anti-Cheat and Vanguard both exhibit clear rootkit-like behavior across multiple metrics. BattlEye and Easy Anti-Cheat did not meet the threshold. The paper is explicit that this is a taxonomic finding about technical capability, not about intent -- the authors distinguish between protective and malicious software operating via identical mechanisms at the kernel level. The finding is significant because it provides a peer-reviewed technical basis for the concern that Linux users often articulate: the capabilities required to do effective anti-cheat at the kernel level are structurally identical to the capabilities of malicious rootkits. [30]
Vanguard specifically received high scores on evasion (custom memory management hiding structures from other processes), early boot execution, and what the paper classifies as information exfiltration (continuous hardware identifier collection). The paper notes that Vanguard implements what it calls a "Guarded Region" -- a memory region where the actual game World pointer resides that is invisible to processes outside the game's own address space, enforced by the anti-cheat driver's memory management system. This is not a Windows OS primitive; it is a custom mechanism built into the driver itself. A legal analysis cited in a 2025 follow-up systematic review (Alangari et al., December 2025) argued that scanning beyond a game's own process -- which all kernel anti-cheat systems do -- generally falls outside the "strictly necessary" exception of Article 5(3) of the EU ePrivacy Directive, and that most game EULAs do not disclose the specific scope of kernel-level monitoring to users. [30, 31]
Where Things Stand in 2026
The landscape in 2026 is one of measured entrenchment, with the first concrete publisher signals of possible movement. Valve has done much of what it can at the infrastructure level -- building Proton BattlEye Runtime and Proton EAC Runtime, negotiating with vendors, and pushing the Steam Deck into enough hands that Linux now accounts for at least 3.5% of Steam's active user base on a sustained basis, with the March 2026 Hardware Survey recording a record 5.33% -- though analysts, including Phoronix, attribute that spike primarily to a correction in Valve's Chinese survey sampling rather than a permanent step-change in the underlying user base. What Valve cannot do is force third-party developers to enable Linux support in their anti-cheat configurations or to build native Linux kernel drivers for their anti-cheat systems.
The community database at Are We Anti-Cheat Yet tracks which titles have Linux-compatible anti-cheat enabled, which titles block Linux explicitly, and which are in unknown or partial states. The ratio has improved for smaller titles but remains deeply unfavorable for large competitive multiplayer games. The games that matter most to competitive players -- Valorant, League of Legends, Call of Duty, Rainbow Six Siege -- are all blocked at the kernel level with no announced path to resolution.
For Linux users who want to play those titles, the options are narrow: maintain a Windows dual-boot, use Windows on a separate machine, use a cloud gaming service that hosts a Windows environment on real hardware (bypassing the VM detection issue), or accept that those games are off the table. None of these options is frictionless, and none of them represent Linux gaming working the way its advocates want it to.
Three structural developments give this moment more texture than the years of stasis before it. The first is Microsoft's Windows Resiliency Initiative: the July 2025 private preview of the Windows endpoint security platform delivered the first concrete step toward making kernel drivers unnecessary for effective security on Windows. Named MVI partners -- including Bitdefender, CrowdStrike, ESET, SentinelOne, Sophos, Trellix, Trend Micro, and WithSecure -- are now actively building products designed to run outside kernel mode. If this trajectory holds, the industry's technical case for requiring ring-0 access in anti-cheat collapses, and user-space implementations with parity coverage become viable across all platforms -- including Linux. The second is EA's March 2026 job listing explicitly naming Linux and Proton as future targets for Javelin -- the first time a major publisher with a blocked kernel-level anti-cheat has put that commitment in a public hiring document. The third is the March 2026 Steam survey recording Linux above 5% for the first time: even discounting that figure as a spike, the underlying trend from below 1% in 2022 to 3--4% sustained in 2025--2026 means the platform argument for ignoring Linux is materially weaker than it was when Vanguard shipped. None of these developments means Linux users can play Valorant or Call of Duty tomorrow. But together they represent the first real, documented pressure on an architecture that has been treated as immovable for four years. The current state of affairs may not be permanent -- and for the first time, there are specific, named, and independently verifiable reasons to believe that beyond optimism.
The March 2026 Steam survey result has generated strong disagreement online, with some treating it as confirmation that Linux gaming has permanently crossed the 5% threshold and others dismissing it as a pure statistical artifact. The actual picture, as reported by Phoronix and Videocardz among others, is more precise: the primary driver of the March spike appears to be a correction in Valve's survey sampling methodology for Chinese users -- Simplified Chinese language participation dropped 31.85 points in a single month, with English rising 16.82 points simultaneously, indicating the survey pool changed substantially rather than the underlying user base tripling. Windows 10 end-of-life migration was a secondary contributing factor. This article describes the sustained trend (3--4% across late 2025 into early 2026) as the meaningful underlying figure and treats the 5.33% figure as a likely sampling spike -- which is the assessment of the sources that analyzed the underlying survey data. Both the "permanent milestone" and "pure artifact" interpretations are overstated; the honest position is that the trend is real and growing, but the single March 2026 data point should not be cited as a precise floor.
Before purchasing a multiplayer game on Linux or Steam Deck, check areweanticheatyet.com and the game's ProtonDB entry at protondb.com. A "Borked" rating on ProtonDB in combination with a "Broken" or "Denied" entry on Are We Anti-Cheat Yet is a reliable indicator the game will not function online.
The kernel anti-cheat problem on Linux is a microcosm of a broader tension between the open-systems philosophy that makes Linux what it is and the closed-trust requirements of competitive game integrity. Neither side is entirely wrong. The cheat ecosystem targeting large free-to-play games is real, financially motivated, and technically sophisticated. The Linux community's insistence on user ownership of the kernel is also principled and serves legitimate security interests. The market has not yet found an architecture that satisfies both, and until it does, Linux gamers will keep running into the same wall every time a new title adds a kernel-mode driver to its anti-cheat stack.
How to Check if a Game's Anti-Cheat Works on Linux Before You Buy
3 minutes — run these checks before purchasing any multiplayer title on Linux or Steam Deck
Visit areweanticheatyet.com and search for the game title. Look for a status of Supported, Running, Denied, or Broken. Denied and Broken mean the game will not function in online modes on Linux.
Visit protondb.com and search for the game. A Borked rating combined with a Denied or Broken status on Are We Anti-Cheat Yet is a reliable indicator the game will not function online at all.
Determine whether the game uses Vanguard (Riot titles), RICOCHET (Call of Duty), Javelin (EA titles), BattlEye, or Easy Anti-Cheat. Vanguard and RICOCHET have no Linux compatibility path. BattlEye and EAC have user-space Linux implementations that developers can choose to enable on a per-title basis.
On the Steam store page, look for a Steam Deck Verified or Playable badge. If a game requiring online play is marked Unsupported or carries no badge, kernel-level anti-cheat is the most common reason. An Unsupported badge on a multiplayer game is not always the developer's choice to fix.
Frequently Asked Questions
Sources
- [1] Koskinas, Phillip. Quoted in: How Riot Games Is Fighting the War Against Video Game Hackers. TechCrunch, May 2025.
- [2] Koskinas, Phillip. Quoted in: Valorant Is Winning the War Against PC Gaming Cheaters. The Verge, October 2024.
- [3] EA/Respawn Entertainment. EA Removes Apex Legends from Steam Deck Due to Linux Cheating. Digital Trends, October 2024.
- [4] Dawe, Liam. Grand Theft Auto V Gets BattlEye Anti-Cheat, Breaks Online Play on Steam Deck / Linux. GamingOnLinux, September 2024.
- [5] van der Merwe, Julian. Microsoft Paves the Way for Linux Gaming Success With Plan That Would Kill Kernel-Level Anti-Cheat. NotebookCheck, September 2024.
- [6] Dawe, Liam. Anti-Cheat Will Still Be One of the Biggest Problems for the New Steam Machine. GamingOnLinux, November 2025.
- [7] For the Steam Machine to Change PC Gaming, Valve Must Solve Linux's Anti-Cheat Problem. Engadget, November 2025.
- [8] Tulach, Samuel. The Issue of Anti-Cheat on Linux. tulach.cc.
- [9] sam4k. What's the Deal With Anti-Cheat on Linux? sam4k.com, August 2021.
- [10] Riot Games Talk Vanguard Anti-Cheat for League of Legends and Why It's a No for Linux. GamingOnLinux, April 2024.
- [11] Anti-Cheat: A Thorny Problem for Linux Gamers. It's FOSS, November 2024.
- [12] Good News? EA Is Expanding Its Anti-Cheat to ARM64, and Linux Could Be Next. It's FOSS, March 2026.
- [13] cyber-sushi. Vanguard on League Is a Compatibility and Accessibility Issue. GitHub Gist.
- [14] leagueoflinux.org. Vanguard -- The Hub for Everything Riot Games on Linux.
- [15] Rigney, Ryan K. The Gamers Do Not Understand Anti-Cheat. Push to Talk, February 2024.
- [16] Nasir, Hassam. EA's Javelin Anti-Cheat Is Coming to ARM-Based Systems -- Job Listing Anticipates Nvidia N1/N1X Debut. Tom's Hardware, March 2026.
- [17] Dawe, Liam. EA Javelin Anticheat Job Listing Mentions Future Support for Linux and Proton. GamingOnLinux, March 2026.
- [18] Larabel, Michael. Revised Steam Survey For December 2025 Puts Linux Gaming Marketshare At 3.58%. Phoronix, January 2026. (Valve's initial December 2025 release showed 3.19%; the revised figures, published January 6 2026, put Linux at 3.58% and macOS at 2.18%.)
- [19] Microsoft. Microsoft Launches Windows Resiliency Initiative, November 2024.
- [20] Riot Games. Riot Vanguard -- League of Legends Wiki. (Documents January 2025 macOS Embedded Vanguard rollout, patch 25.S1.2.)
- [21] Silva, Joao. SteamOS Propels Linux to Record 5.33% Share in Latest Steam Survey. KitGuru, April 2026. (Reporting on Valve's March 2026 Steam Hardware and Software Survey results.)
- [22] Weston, David. The Windows Resiliency Initiative: Building Resilience for a Future-Ready Enterprise. Windows Experience Blog, June 2025. (Announces July 2025 private preview of Windows endpoint security platform for MVI partners, enabling out-of-kernel security product development.)
- [23] Larabel, Michael. Steam Survey Results Published for February 2026. Phoronix, March 2026.
- [24] Dawe, Liam. Steam Survey for January 2026 Shows a Small Drop for Linux and macOS. GamingOnLinux, February 2026.
- [25] Schwartz, Mathew J. Brave New Kernel: Microsoft Previews Safer Windows Ecosystem. BankInfoSecurity, June 2025. (Confirms July 2025 launch of Windows endpoint security platform private preview for MVI partners.)
- [26] archie-osu. Inside Riot Vanguard's Dispatch Table Hooks. archie-osu.github.io, April 2025. (Documents HalPrivateDispatchTable hooks at offsets 0x248 and 0x400 inside vgk.sys; PatchGuard-compliant context switch and syscall interception.)
- [27] rhaym-tech. A Well Detailed Riot Vanguard Kernel AntiCheat (vgk.sys) Analysis. GitHub Gist. (Documents SERVICE_BOOT_START registration, PatchGuard active-trigger test via int20, SMBIOS/Boot GUID hardware fingerprint collection, IAT hooks, and callback registrations during DriverEntry.)
- [28] isdmadead.com. DMA Anticheat Evolution Timeline Since PCILeech (2016). (Community-documented timeline of anti-cheat PCIe detection milestones: VGK Bus Master Enable enforcement, A/B functional tests against spoofed XHCI/NIC/audio/capture-card firmware, IOMMU prevention and detection.)
- [29] FACEIT. FACEIT Finalises Windows Security Rollout: TPM 2.0, Secure Boot, IOMMU & VBS, October 2025. Also: Windows Security Requirements FAQ. FACEIT Support. (TPM 2.0 and Secure Boot mandatory from November 25, 2025; IOMMU required for all players above 3,000 Elo since August 2025; Windows 11 required from October 2026.)
- [30] Dorner, Christoph and Klausner, Lukas Daniel. If It Looks Like a Rootkit and Deceives Like a Rootkit: A Critical Examination of Kernel-Level Anti-Cheat Systems. ARES 2024, Vienna. ACM. doi:10.1145/3664476.3670433. (Peer-reviewed evaluation of BattlEye, EAC, FACEIT AC, and Vanguard against seven rootkit behavior metrics; FACEIT AC and Vanguard classified as rootkit-like; BattlEye and EAC not classified as rootkit-like.)
- [31] Alangari, Adwa et al. A Systematic Review of Technical Defenses Against Software-Based Cheating in Online Multiplayer Games. arXiv:2512.21377, December 2025. (Cites Dorner & Klausner; cites Greidanus legal analysis arguing kernel anti-cheat cross-process scanning falls outside the EU ePrivacy Directive Article 5(3) "strictly necessary" exception.)