Game Security and Anti-Cheat Guide: Accounts, Economies and Anti-Cheat Trade-Offs

Online games run on a client the attacker owns, hold accounts and virtual items worth real money, and serve millions of players, many of them children, so they face cheating, account theft and fraud at a scale most applications never see. Studios often respond by reaching for client-side anti-cheat, including kernel drivers, when most of the exploitable weaknesses are in the server design, the account system and the in-game economy. This guide covers the game threat model, server authority, the trade-offs between user-mode, kernel and server-side anti-cheat, account protection, economy integrity, secrets in shipped clients, availability and children's protection. It is written for game security engineers, backend and platform teams, live-operations leads, and security teams in publishers or platforms that host games.

Key takeaways

• Never trust the client. Anything a player's machine computes or reports, such as position, damage, currency earned or match results, can be altered, so authoritative state must live on servers you control.
• Anti-cheat is risk reduction, not prevention. Client anti-cheat raises the cost of cheating; server-side validation and behavioural detection decide whether cheating actually pays.
• Kernel anti-cheat has a security cost. A signed kernel driver installed on millions of PCs is attack surface, and the Genshin Impact anti-cheat driver mhyprot2.sys was abused by a ransomware actor to kill antivirus.
• Accounts and items are the real prize. Credential stuffing, weak recovery flows and session theft drive account takeover, because stolen inventories can be resold for cash.
• Economies need transactional integrity. Duplication and double-spend bugs are race conditions and business logic flaws, fixed with server-side transactions and locking, not with anti-cheat.

The game threat model

Games differ from ordinary web applications in three ways: the client is a rich program running with the player's full privileges, the state that matters (a match, an inventory, a currency balance) changes many times per second, and the motivation includes status and fun as well as money. The useful threat model separates attackers by goal.

Server authority: the control that matters most

Valve's Steamworks anti-cheat guidance puts the core principle plainly: run dedicated servers that manage game state, make the server authoritative over positions and other state to counter speed hacks and god mode, and send each client only the data it needs, such as nearby player positions. In peer-to-peer games, each client should validate the others so the host cannot control state alone.

• Clients send intent, servers decide outcomes: the client says "move forward" or "fire at this angle"; the server simulates, checks reachability, rate of fire, cooldowns and line of sight, and rejects impossible results. OWASP ASVS 5.0 V2.2.2 states the same rule for any application: input validation at a trusted service layer, never relying on client-side checks.
• Minimise what the client knows: wallhacks work because the client was told where hidden enemies are. Server-side visibility culling (only replicate players the client could plausibly see or hear) removes the information rather than trying to stop a cheat reading it.
• Validate rates and sequences: physically impossible speeds, actions faster than human timing and out-of-order steps should be rejected. ASVS V2.3.1 (expected sequential step order) and V2.4.2 (realistic human timing) map directly.
• Accept the latency trade-off deliberately: client-side prediction and lag compensation are needed for responsive play, but each one is a place where the server trusts client-supplied timing. Keep the trust window small and bounded, and log when compensation is applied at its limits.
• Never let clients write scores or progression directly: backend-as-a-service platforms often allow client-side writes for convenience; switch off client write access to statistics, leaderboards, currencies and inventory, and perform these changes in server code.

Client anti-cheat: options and trade-offs

Client anti-cheat looks for known cheat software, tampering with the game process and suspicious input. It cannot be perfect, because the attacker controls the hardware, but it raises the cost and catches the casual majority. The design choice is how deep in the operating system it runs.

Deciding how deep to go

• Competitive shooters with ranked play and prize money: the cheat market is large and sophisticated; server authority plus behavioural detection is mandatory, and many studios add kernel-level protection. Disclose it clearly to players before purchase.
• Cooperative, casual or single-player games: kernel anti-cheat is rarely proportionate. Protect the economy and leaderboards on the server and accept that some local cheating is harmless.
• Mobile games: use platform integrity APIs and server-side checks; see the Mobile App Security Guide.
• Small studios: use a platform or middleware anti-cheat and the platform's ban infrastructure rather than writing a driver. Steamworks Game Bans, for example, let a developer issue bans through the ICheatReportingService Web API, and banned accounts cannot join secure servers for that game.

If you ship a kernel driver

Microsoft's Driver Security Checklist starts by asking whether the job can be done in user mode at all, and then sets out what a responsible driver needs:

1. Restrict who can open the device with a strict SDDL in the INF or IoCreateDeviceSecure, and check access per IOCTL with IoValidateDeviceIoControlAccess. A driver that lets any process ask it to read memory or kill processes is a ready-made attack tool.
2. Validate every buffer, prefer METHOD_BUFFERED, and capture user-mode data before using it to avoid time-of-check to time-of-use bugs.
3. Make the driver compatible with memory integrity (HVCI): no writable and executable memory, non-executable pools.
4. Run CodeQL, Driver Verifier and IOCTL fuzzing before every release, and threat model the driver interface.
5. Never production-sign builds with test or debug capabilities such as arbitrary memory access; ship through WHQL signing and staged rollout.
6. Plan how you will respond when an old signed version is found to be abusable, including working with Microsoft on blocklisting it.

Microsoft's Windows Resiliency Initiative (June 2025) announced platform capabilities to let antivirus and endpoint security products run outside the kernel. Anti-cheat vendors face the same pressure, and studios should track whether user-mode alternatives become viable for their threat model.

Anti-cheat drivers as an enterprise risk

Trend Micro reported in August 2022 that a ransomware actor used mhyprot2.sys, the anti-cheat driver of Genshin Impact, to gain kernel privileges and terminate antivirus processes before deploying ransomware. The driver was legitimately code-signed, the certificate had not been revoked at the time of writing, and the game did not need to be installed for the driver to be abused. This is the "bring your own vulnerable driver" pattern (ATT&CK T1068 Exploitation for Privilege Escalation).

• For enterprises: keep the Microsoft vulnerable driver blocklist enabled. It is on by default since the Windows 11 2022 update and enforced whenever memory integrity (HVCI), Smart App Control or S mode is active. The in-box list is updated quarterly and through monthly updates; organisations that want the latest list sooner can deploy Microsoft's recommended driver block rules through App Control for Business.
• Detection: alert on Windows System event ID 7045 (a service was installed) for kernel-driver services that are not part of your software baseline, and on game anti-cheat drivers appearing on servers or corporate endpoints where no game is approved. See the Windows Endpoint Hardening Guide.
• For studios: your driver will outlive your game. Design it so that an old version cannot be loaded and driven by arbitrary processes, and plan revocation with the platform owner.

Player accounts and identity

Game accounts are attractive because inventories, rare skins and ranked accounts have resale value, and because players reuse passwords. Treat the account system as a consumer identity platform. See the Customer IAM (CIAM) Guide.

• Credential stuffing defence: rate-limit and risk-score login by IP, device and account (NIST SP 800-53 AC-7), check passwords against breached lists, and detect bursts of failures across many accounts. See the Password Spraying and Credential Stuffing Defence Guide.
• MFA that players will use: offer authenticator apps and passkeys, and reward enrolment (cosmetic items, removal of trade delays). Avoid SMS as the only factor. See the MFA Guide.
• Recovery is the weakest link: support agents are routinely socially engineered into resetting email addresses on high-value accounts. Recovery must not bypass MFA (ASVS V6.4.3), and changes to email, MFA or linked platform accounts should trigger notification and a cooling-off period. See the Account Recovery and Help Desk Security Guide.
• Linked platform accounts: many games sign in through console, PC store or social identity providers. Validate tokens server-side, bind sessions to the account, and handle unlinking as a sensitive change.
• Session tokens: launchers and companion apps often hold long-lived tokens on disk, a target for infostealers. Keep tokens short-lived, rotate refresh tokens, and revoke on password change. See the Session Hijacking and Cookie Theft Guide.
• Post-takeover friction: holds on trading and gifting after a new device login, password reset or MFA removal give the real owner time to recover before items are moved. See the Account Takeover Prevention Guide.

Protecting the in-game economy

Most economy exploits are ordinary application security bugs with a game skin. The server must be the ledger.

Run daily reconciliation that compares currency created and destroyed against expected sources and sinks; an unexplained surge is often the first sign of a duplication bug.

Secrets and trust in shipped clients

A game client, like a mobile app, is in the attacker's hands. Any key compiled into it should be assumed public. Symantec's 2022 research found 1,859 mobile apps with hard-coded AWS credentials, including a shared library in 16 online gambling apps that exposed root-level AWS credentials; see the Mobile Apps Hard-Coded AWS Keys 2022 breach page.

• Server and admin keys never ship: backend-as-a-service "title secret" or server API keys, cloud access keys, analytics admin tokens and signing keys must stay on servers. Clients authenticate as the player and receive a player-scoped session.
• Scan builds before release: run secret scanning on build artefacts and asset bundles, not only on source, because SDKs and plugins add their own keys. See the Secrets Management Guide.
• Treat build infrastructure as crown jewels: signing keys, platform publishing credentials and CI service accounts let an attacker ship a malicious update to every player. See the Software Supply Chain Security Guide.
• Mods and plugins: where a game supports user-generated scripts or mods, run them in a sandbox with a minimal API; WebAssembly is one option, see the WebAssembly Security Guide.

Availability and player safety

• DDoS: game servers and matchmaking are frequent DDoS targets, often by players disrupting matches. Use provider DDoS protection, keep server addresses behind relays, and avoid peer-to-peer designs that expose players' home IP addresses. Application floods against login or matchmaking (ATT&CK T1499.003) need rate limits at the application layer too. See the DDoS Protection Guide.
• Children's privacy and safety: in December 2022 the US FTC announced that Epic Games would pay $520 million in total: a $275 million penalty for collecting personal information from children under 13 without verifiable parental consent under COPPA, and $245 million in refunds over design patterns that led to unwanted purchases. The order required voice and text chat to be off by default for children and teens and barred charging without affirmative consent. Treat safe defaults, consent for purchases and age-appropriate chat as security requirements. See the COPPA and Children's Privacy Guide and the Age Assurance Guide.
• Fair enforcement: Steamworks guidance is to tell players an anti-cheat system exists, explain clearly in game why they were banned, and limit bans to the game where cheating happened. Keep an appeals process and evidence (replays, detections) for each ban.

Implementation roadmap

1. Threat model the title: list what is valuable (rank, items, currency, accounts), where state is decided, and which data each client receives.
2. Move authority to the server: remove client write access to progression, currency and leaderboards; add server-side validation of movement, rates and sequences. Ship validation in log-only mode first, measure false positives against honest play, then enforce.
3. Harden accounts: rate limiting, breached-password checks, MFA incentives, recovery cooling-off and trade holds.
4. Fix the ledger: transactions, idempotency keys, receipt validation and daily reconciliation.
5. Choose client anti-cheat proportionately using the decision guidance above; pilot it on a test ring or one region, measure crash rates and compatibility, and keep a kill switch that disables enforcement without a client patch.
6. Build detection and review: telemetry, statistical outlier detection, replay tools, and a human review queue before permanent bans. Prefer delayed ban waves so cheat developers cannot easily tell which change was detected.
7. Prepare rollback: for false-positive ban waves, have a scripted mass-unban and compensation path; for broken anti-cheat updates, a server-side switch to report-only mode.

Detection and measurement

Log server-side rejections (impossible movement, rate violations), anti-cheat detections with version and signature identifiers, login failures and risk decisions, recovery and MFA changes, trades and currency flows, and ban and appeal outcomes. Feed these into the same monitoring as other production security events (NIST SP 800-53 SI-4).

• Cheater exposure rate: share of matches containing a player later banned for cheating.
• Time to detection: median days from a cheat's first observed use to bans for it.
• False-positive rate: bans overturned on appeal as a share of bans issued.
• Account takeover rate: confirmed takeovers per 100,000 active accounts, and MFA enrolment among high-value accounts.
• Economy integrity: unexplained currency or item creation found by reconciliation, per day.
• Anti-cheat stability: crash rate attributable to the anti-cheat component per release.

Common failure patterns

• Trusting client-reported results: leaderboards and currency written by the client, which no anti-cheat can fully protect.
• Sending hidden information to clients: replicating every player's position to every client, then trying to stop wallhacks with client scanning.
• Shipping server keys in the client: backend secret keys, cloud credentials or admin tokens extracted from builds within days of launch.
• Insecure kernel drivers: drivers with open IOCTLs that any process can use to read memory or terminate processes, later reused by malware.
• Recovery flows that bypass MFA: support agents changing account email on the strength of a purchase receipt or a convincing story.
• Instant, opaque bans: immediate bans that teach cheat developers what was detected, and no appeal path for false positives.

Lessons from incidents

The mhyprot2.sys case shows that anti-cheat is software supply chain risk for every organisation whose staff install games, not only for studios: a legitimately signed driver with powerful, unauthenticated functions became a ransomware tool. The Symantec research on hard-coded credentials shows that client builds, including gambling apps, routinely leak backend keys through shared SDKs. The FTC's Epic Games settlement shows that regulators treat children's defaults and purchase consent in games as enforceable obligations with very large penalties.

Framework mapping

CIS Controls v8.1 Control 16 (Application Software Security) and ISO/IEC 27001:2022 Annex A 8.28 (Secure coding) cover the development side.

Practitioner checklist

• Make the server authoritative for movement, combat outcomes, progression, currency and leaderboards; remove client write access to them.
• Replicate to each client only the game state it needs to render.
• Wrap every trade, craft and purchase in a transaction with idempotency keys, and reconcile the economy daily.
• Validate store purchase receipts server-side and consume each transaction ID once.
• Rate-limit logins, check breached passwords, incentivise MFA and stop recovery flows bypassing it.
• Apply trading and gifting holds after sensitive account changes.
• Scan release builds for secrets and keep server keys, cloud credentials and signing keys off clients.
• Choose client anti-cheat proportionately; if you ship a kernel driver, follow the Driver Security Checklist and plan revocation.
• In enterprises, keep the vulnerable driver blocklist on and alert on unexpected driver service installs (event ID 7045).
• Keep a human review and appeal path, delayed ban waves and a scripted rollback for false positives.

Standards and references

• OWASP: Application Security Verification Standard 5.0
• Microsoft Learn: Driver security checklist
• Microsoft Learn: Microsoft recommended driver block rules
• Valve Steamworks: Anti-cheat and Game Bans
• US FTC: Fortnite video game maker Epic Games to pay more than half a billion dollars over FTC allegations
• Trend Micro: Ransomware actor abuses Genshin Impact anti-cheat driver to kill antivirus
• Microsoft: The Windows Resiliency Initiative
• MITRE ATT&CK: Exploitation for Privilege Escalation

Related NHI Mgmt Group resources: Account Takeover Prevention Guide · Bot Management Guide · COPPA and Children's Privacy Guide · Fraud Prevention Guide for Digital Businesses · WebAssembly Security Guide