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.