Why VALORANT Can't Come to Mac — And Why It Doesn't Have to Stay That Way

VALORANT isn't on macOS. Not because Riot doesn't want it there, not because

Apple Silicon can't run it — but because of a single implementation detail:

Apple effectively bans third-party kernel drivers, and Riot's anti-cheat,

Vanguard, needs one to work.

So I spent the last few months building a proof-of-concept to answer one

question: does it actually need one?

The Real Problem

Kernel-level anti-cheat (vgc.sys, EAC, BattlEye) exists because Windows is

an open platform. Memory can be read across processes. Unsigned code can be

injected. Hardware DMA cards can bypass software entirely. A kernel driver is

the only vantage point high enough to police all of that.

Apple Silicon is a different environment. Most of those attack surfaces don't

exist the same way — or don't exist at all.

Apple didn't just close these vectors — they built the replacements into the

hardware.

What I Built

Vanguard-for-macOS is a two-component PoC that delivers anti-cheat

guarantees without a kernel driver:

Phase 1 — Endpoint Security Monitor (C)


An entitled user-space agent that subscribes to Apple's ES kernel event stream.

It catches every event competitive integrity actually cares about: process

lifecycle, task-port (memory) access requests, and dylib injection attempts —

all without ring 0, all through an Apple-vetted API.

Expected output when a cheat attempts memory access against a protected process:

[2026] ALERT GET_TASK    requester=loader  target=MyGame

[2026] ALERT EXEC+INJECT path=MyGame  via=DYLD_INSERT_LIBRARIES=/path/to/hook.dylib

Phase 2 — Hardware Attestation (Swift + Node.js)


The Secure Enclave generates a non-exportable P-256 key. Apple's App Attest

service certifies it. The game server verifies the full certificate chain from

scratch — no black box, every check is auditable. The result: the server only

trusts clients whose hardware proves they're running the real, unmodified agent.

Running today on real Apple Silicon hardware:

[attest-client]   SEP P-256 key generated.

[attest-client]   private key export refused by SEP (expected) ✓

[attest-client]   enclave-signed message verifies: ✓



verifyAssertion — happy-path:

  ✓ valid assertion accepted

  ✓ replayed counter rejected

  ✓ tampered clientData rejected

  ✓ wrong rpIdHash rejected

  ✓ foreign-key signature rejected

  5 passed, 0 failed

The core idea is a trust inversion: the client doesn't need to be

unbreakable, it needs to be unforgeable. Tamper with the agent, its code

signature changes, attestation breaks, and the server stops trusting it.

What's Still Missing

I'd rather say this up front than have you find it yourself:

• The ES entitlement (com.apple.developer.endpoint-security.client) requires
  Apple's review to run on stock macOS. It's pending. Without it, Phase 1
  requires SIP disabled to demonstrate — which matters.


• Phase 4 (System Extension packaging) isn't done yet. That's the step that
  turns this from a research build into something a studio could actually ship.


• Server-side heuristics, continuous runtime attestation, and hardware input
  emulators are out of scope — those are backend problems no client agent fully
  closes anyway.

Why This Matters

Every Mac player excluded from VALORANT is excluded by an implementation detail,

not by a fundamental security limitation. Apple Silicon's trust chain is

arguably better than a Windows kernel driver for this use case — it's native

to the hardware, it can't BSOD the machine, and the distribution model (Apple's

entitlement review) is itself a trust property.

This isn't a complete product. It's a proof that the path exists.

GitHub: github.com/JusticeRox98577/Vanguard-for-Macos

If you work in macOS security or anti-cheat and want to poke holes in it, I'd

genuinely welcome it. If you work at Riot — I'd love a technical conversation.

Independent research. Not affiliated with, authorized by, or endorsed by Riot

Games or Apple.