Kernel-Level Anti-Cheat Explained — BattlEye, EAC, Vanguard & Ricochet

Kernel-level anti-cheat runs at Ring 0 with the same access as Windows itself — powerful against injected cheats, structurally blind to the hardware attacks that operate beneath it.

The Driver That Sees Everything

A kernel-level anti-cheat is a signed driver that loads into Windows kernel space (Ring 0) and shares the operating system's own privilege level, which lets it read physical memory, enumerate every process and loaded driver, and intercept low-level system calls that user-mode software can never reach. That single architectural decision — running beside the kernel instead of beside the game — is the entire source of both its detection power and its controversy.

Four systems carry almost the whole competitive market: BattlEye, Epic's Easy Anti-Cheat, Riot's Vanguard, and Activision's Ricochet. They look similar from a launcher, but they diverge sharply on when the driver loads, what they enforce at the hardware level, and how they punish a flagged account. This breakdown walks the mechanics, separates the four systems, and — the part most explainers skip — maps the hardware-layer attacks that a Ring 0 driver cannot observe by design.

Ring 0 vs Ring 3: Why Anti-Cheat Went Into the Kernel

Privilege rings are a CPU-level hierarchy: Ring 3 is user mode, where games, browsers and ordinary anti-cheat run inside a sandbox with no access to other processes' memory or hardware, and Ring 0 is kernel mode, reserved for the operating system and the drivers it trusts. The asymmetry is the whole point — anything enforcing protection purely from Ring 3 can be read or rewritten by code running one ring lower.

The escalation followed predictable logic. Once anti-cheat learned to block user-mode injection, cheat developers wrote their own kernel-mode drivers and read game memory from a level the anti-cheat couldn't inspect, so the only way to observe a Ring 0 cheat was to put the anti-cheat at Ring 0 too. The technical argument is sound; whether the security cost is acceptable is the part players keep fighting over, and that tension runs through the rest of this page.

How Kernel Anti-Cheat Actually Works

A kernel anti-cheat is usually three pieces working together: a Ring 0 driver, a user-mode service, and a component loaded inside the protected game, communicating through controlled channels so the driver does the privileged work while the service handles reporting. The driver's job breaks down into a small set of repeatable techniques.

Memory scanning and integrity checks

The driver walks memory looking for executable regions that map to no file on disk — the signature of manually mapped or injected code — and periodically re-hashes the game's own code sections to confirm nothing has been patched mid-session. Injected cheats fail this because their code lives in private memory the loader can't account for.

Kernel callbacks and handle stripping

Windows lets a driver register callbacks that fire when a process starts, a thread is created, or a driver loads, and anti-cheat uses these to catch injection as it happens. The sharper move is handle stripping: when an external program requests read or write access to the game, the anti-cheat intercepts that handle and removes the memory-access rights before the cheat ever receives it, which is the technique Riot describes for Valorant — the cheat gets a handle, but a worthless one.

Boot-time vs runtime loading

When the driver loads matters as much as what it does. Runtime systems (BattlEye, Easy Anti-Cheat, Ricochet) start the driver at game launch and unload it on exit, which is lighter but leaves a brief startup window before protection is live. Boot-time loading (Vanguard) starts the driver with Windows, ahead of nearly everything else, closing that window and letting it watch every driver that loads afterward — at the cost of running whenever the machine is powered on. Windows also requires any kernel driver to be digitally signed, and these systems refuse to run if signature enforcement is disabled, which is why a machine configured for unsigned drivers simply won't launch the game.

BattlEye vs EAC vs Vanguard vs Ricochet

All four sit at the kernel and all four can issue hardware bans, but they differ in load timing, hardware enforcement, and how they act on a detection. The table is the quick read; the profiles below it explain where each one is genuinely distinct.

BattlEye pairs its BEDaisy.sys driver with a user-mode agent, but its defining trait is that detection logic is controlled from BattlEye's backend and changes on the fly, so the checks running today are not the checks a cheat was tested against last week. It leans on delayed global ban waves rather than instant kicks, which is why titles like Rainbow Six Siege and Escape from Tarkov see flagged accounts disappear in batches instead of one at a time.

Epic's Easy Anti-Cheat protects the widest catalog of any system, and its distinctive mechanic is the shared hardware ban — a hardware-level ban earned cheating in one EAC title can follow the machine into others, which raises the stakes across games like Rust, Apex Legends and Dead by Daylight rather than isolating consequences to one account. Its Linux behavior is a separate case covered further down.

Vanguard is the most aggressive of the four. The vgk.sys driver loads at boot and Riot enforces TPM 2.0 and Secure Boot as hard requirements, so a non-compliant configuration blocks the game outright rather than degrading quietly. That boot-time persistence gives Valorant's system the widest visibility of any consumer anti-cheat, which is exactly why it draws the loudest privacy objections.

Ricochet, Activision's in-house system for the Call of Duty line, runs its kernel driver only while a protected title is open and leans hard on server-side machine learning plus creative in-game mitigations — instead of only banning, it can strip a flagged player's weapons or render "hallucination" decoys that only the cheater can see, gathering evidence before enforcement. It also pushes verification outward with cloud-based attestation, asking an external service to confirm a machine's boot integrity rather than trusting the machine to report on itself.

What Kernel Anti-Cheat Can't Stop

This is the section that separates an informed reader from a casual one. Kernel anti-cheat is excellent against one class of threat and structurally blind to another, and the boundary sits exactly where the attack stops touching the operating system.

It reliably shuts down cheap public cheats — the kind of aimbots and ESP/wallhacks most players run — that inject from user mode, Ring 3 memory editing, most kernel-mode cheats that try to load their own driver, and basic virtual-machine or spoofing tricks. What it struggles with is the set of techniques that operate at or below its own level:

• DMA (Direct Memory Access). A separate physical device — usually an FPGA card on the PCIe bus — reads the gaming PC's memory directly through hardware and ships it to a second machine, never touching the protected OS. From the anti-cheat's point of view the gaming machine looks completely clean, which is why hardware DMA setups sit at the frontier and are only partly answered by IOMMU, Secure Boot and TPM attestation. The defensive side of that fight lives in DMA firmware against VGK, BE and EAC. For the full breakdown, see what a DMA cheat is.
• Hypervisor cheats that run beneath the kernel by virtualizing the whole OS, which forced anti-cheats to add hypervisor detection and kept the cycle moving.
• BYOVD (Bring Your Own Vulnerable Driver). Attackers load a legitimate, signed-but-vulnerable driver from a mainstream hardware vendor, exploit its handler to run their own kernel code, then disable signature enforcement from the inside — the defense is an ever-growing driver blocklist rather than a clean fix.
• HWID spoofers, which change nothing physical and instead intercept the hardware-identity queries the anti-cheat sends, feeding back different answers. Against a boot-time system the spoofer has to load even earlier than the driver it's fooling, which is why a working HWID spoofer is a boot-ordering problem as much as a software one. Our HWID ban & spoofer guide covers how that plays out.

The honest summary, and one experienced players reach on their own, is that kernel anti-cheat clears out the flood of free public cheats while doing far less against well-funded hardware setups. It raises the floor; it does not close the ceiling.

The Hardware Arms Race

The most active battles have moved off the software layer entirely, and a few recurring moves define where the fight stands without needing a calendar attached to them.

Anti-cheats have begun weaponizing IOMMU against DMA: a system can flag a DMA cheat card as unsafe through IOMMU, forcing Windows to cut its memory access. The trap is elegant — disabling IOMMU restores the device, but the same systems require IOMMU to be on in order to play, so a cheater can have a working card or a running game, not both. One vendor's public framing of turning expensive cards into "paperweights" caused a panic that entire PCs were being bricked, which the studio denied: the system flags the cheat device, it does not damage hardware.

Cloud-based attestation is the second shift, moving the trust boundary off the player's machine so a cheater can no longer simply lie about boot integrity. The third is the move against input-modification hardware, where detection now targets classes of machine-driven behavior rather than a single device signature, so reconfiguring the hardware no longer evades it. The fourth is the largest in the long run: after a widely reported security-vendor driver triggered a global outage, Microsoft began building an endpoint platform that lets vendors operate outside the kernel — a direction that could eventually reshape whether anti-cheat needs Ring 0 at all. None of this is settled, which is the precise reason a single snapshot of "current state" ages badly while the direction of travel stays clear: anti-cheat pushing toward hardware attestation, cheats retreating into hardware the OS can't inspect.

Security and Privacy: How Real Are the Risks?

The strongest case against kernel anti-cheat is not that vendors are spying on you — it is that a Ring 0 driver multiplies the blast radius of any single mistake. A bug in a user-mode app crashes the app; a bug in a kernel driver can compromise the entire machine, because the driver's trust level is the system's trust level.

The clearest cautionary case is the anti-cheat driver from Genshin Impact, mhyprot2.sys: because it was legitimately signed, Windows trusted it completely, and ransomware operators loaded it onto victim machines — including PCs that had never installed the game — then abused its kernel access to kill antivirus before deploying their payload. The same broad category of trusted kernel driver was behind a security-vendor outage that took systems down worldwide. Neither was an anti-cheat targeting players, and that is exactly the point: the danger is the privilege, not the intent.

The privacy concern is narrower but legitimate. A boot-time driver is technically capable of observing far more than a game needs and can run while you are not playing; vendors state they do not abuse this, and there is no broad evidence they do, but the capability exists and the trust required is large. An academic analysis that scored several of these systems against rootkit characteristics found the most aggressive, boot-time ones share real traits with rootkits, and tellingly, the encyclopedia entry on the topic links "Rootkit" in its own See-also section. The grounded reaction is informed caution rather than panic: kernel anti-cheat is neither spyware nor harmless, it is a powerful tool with a large failure radius.

Performance, False Positives, and Shadow Bans

Beyond security there are everyday costs that rarely reach the headlines but shape how the systems feel to live with. Kernel drivers add measurable overhead — commonly a low single-digit frame-rate cost — and a poorly behaved driver can cascade into crashes or boot failures, which is why major launches of boot-time systems tend to arrive with a wave of stability complaints.

Compatibility is the quieter tax: signature-strict, boot-time systems conflict with virtualization tools, some overclocking utilities, and other legitimate kernel software, occasionally forcing players to choose between a tool they rely on and a game they want to play. Detection is also imperfect, and the failure mode that breeds the most resentment is the shadow ban — suspected players routed into lobbies populated only by other suspects. Done well it quarantines cheaters; done off mass-reports it can trap an innocent player in a loop with no clear appeal, which is why community sentiment toward some systems stays sour even when published ban-wave numbers look impressive. The recurring expert verdict is blunt and worth keeping in mind: the technology is not perfect, and it is not going anywhere.

Kernel Anti-Cheat on Linux and the Steam Deck

This is where kernel anti-cheat gets genuinely awkward, and it is the question Steam Deck owners ask most. The systems were built around the Windows driver model, and Linux differs in ways that matter — driver-signing rules, kernel-module policies, and the decentralized nature of distributions all make shipping a proprietary kernel driver hard.

In practice there are three outcomes. Easy Anti-Cheat and BattlEye can run through the Wine and Proton compatibility layers without a kernel driver, which means they work on the Deck but with weaker detection than on Windows — and even then, each game's developer has to switch that support on, so a supported anti-cheat does not guarantee a supported game. Boot-time systems that demand TPM, Secure Boot and a Windows kernel driver — Vanguard being the clearest example — do not run on Linux at all, which is why their titles are simply unplayable on the Deck. So the answer to "does it work on Linux" is never one word: it depends entirely on which anti-cheat the game ships and whether the studio enabled the user-space path.

Which Games Use Kernel-Level Anti-Cheat?

Most major competitive titles now ship one of the four systems, and the cleanest way to read the map is by which driver guards which catalog. Easy Anti-Cheat covers the broadest list, including Fortnite and survival and multiplayer staples; BattlEye holds the tactical and extraction end with DayZ alongside Siege and Tarkov; Vanguard is Riot-only; and Ricochet guards the Call of Duty line, including Warzone and Black Ops 7.

The practical heuristic: if a game has ranked play, an esports scene, or a serious cheating problem, assume it runs a kernel-level driver unless you have confirmed otherwise — and assume the specific system, not just the fact of it, determines what survives on that title.

Kernel Anti-Cheat FAQ

What is kernel-level anti-cheat in simple terms?

It is anti-cheat software that installs a driver at the deepest level of Windows (Ring 0), giving it the same access as the operating system so it can detect cheats that hide from ordinary programs. The trade-off is deep system access in exchange for stronger detection.

Is Easy Anti-Cheat kernel level?

On Windows, yes — EAC uses a kernel-mode driver plus a user-mode process. On Linux and Proton it runs in user space only, with no kernel driver and noticeably more limited detection, which is the version that runs on the Steam Deck.

Is Ricochet kernel level?

Yes. Ricochet uses a kernel-level driver on PC that runs only while a protected Call of Duty title is open, paired with server-side machine learning, cloud-based attestation, and in-game mitigations rather than relying on bans alone.

Is kernel-level anti-cheat safe?

For most players it runs without incident, but it carries real risk: a flaw in a kernel driver can expose the whole system, as the Genshin Impact mhyprot2 ransomware case showed when attackers reused a signed anti-cheat driver to disable security software. It is a reasonable trade-off for many, not a zero-risk one.

Why doesn't kernel anti-cheat work on Linux?

Linux handles driver signing and kernel modules very differently from Windows, so proprietary kernel drivers are hard to deploy. Some systems adapt by running in user space through Proton, while strict boot-time systems like Vanguard require TPM, Secure Boot and a Windows kernel driver and do not support Linux at all.

Can you remove kernel-level anti-cheat?

Most can be uninstalled like normal software, though boot-time drivers may need extra steps and a restart to clear fully. Removing it usually means you can no longer launch the games that require it, since they check for the driver at startup.

Kernel anti-cheat clears the public-cheat flood, but the techniques covered above — DMA at the hardware bus, spoofers loading beneath the driver, attestation moving trust off your machine — are exactly where a Ring 0 system goes blind. Knowing which system guards a title, and where its blind spot sits, is the difference between guessing and understanding before you load into a ranked lobby.