Fortnite has a Linux plan, with new anti-cheat requirements

Epic has outlined a new route for Fortnite to run on Linux, built around Easy Anti-Cheat Linux v2 and a more tightly specified system configuration. The October 14 announcement is a development plan, not a release: Epic has not given a firm availability date, and says Steam Deck does not currently support the required features.

For Linux players, the significance is the type of obstacle Epic is addressing. Rendering a Windows game through a compatibility layer is one problem. Convincing a competitive game's anti-cheat system to accept the environment around that game is another.

Compatibility cannot grant permission by itself

Valve's Proton documentation describes a compatibility layer that allows Windows games to run on Linux. It also explains that support for anti-cheat middleware can require action by the game's developer. A technically capable layer does not automatically enable every protected game.

That makes compatibility lists unusually important for multiplayer players. A game can reach its menu or render a scene without establishing that its protected online mode is supported. The meaningful promise is the complete path into the intended game session, including the service deciding whether the client is acceptable.

Epic's Linux v2 announcement proposes Fortnite as the initial validation vehicle before wider developer availability. Its requirements include signed kernels and modules, TPM 2.0, Secure Boot, measured boot and kernel security settings. Epic says its service runs while a protected game is active and uses eBPF hooks rather than a dedicated anti-cheat kernel module.

“No kernel module” still needs context

The Linux kernel's BPF security documentation explains that privileged programs can attach to Linux Security Module hooks to implement access-control and audit policies. That is meaningful access to system behavior. Avoiding a separately maintained kernel module should not be confused with an anti-cheat system operating without elevated privileges or security-sensitive capabilities.

This architectural distinction can also be useful. Using established interfaces places part of the mechanism within facilities the operating system already provides. It does not, by itself, tell a player how effective a particular anti-cheat implementation will be, how much overhead it adds or how its data handling works. Those conclusions would require evidence about the deployed system.

The tradeoff is therefore more concrete than “Linux becomes supported.” An open operating system permits many configurations. A competitive service may choose to accept only a subset it can evaluate. Players gain an additional possible use for their computers, while the supported gaming environment becomes more constrained than Linux in the abstract.

The distribution becomes part of the game setup

Epic is discussing support with distribution developers and describes a possible separate boot entry for compatible configurations. That could let users retain a more flexible everyday setup alongside a restricted gaming session. It remains a proposed accommodation, not a guarantee that switching will be effortless on every computer.

This also explains why a desktop release such as Ubuntu 26.10 cannot establish a game's compatibility simply by being new. Desktop features, kernel configuration, firmware capabilities and game-service policy occupy different layers. A polished Linux experience can still fail a particular anti-cheat requirement.

For players choosing hardware, the missing release date and current Steam Deck limitation are decisive qualifications. For developers, the interesting experiment is whether a documented, distribution-supported security baseline can make a major competitive game practical on Linux without demanding a bespoke kernel module. Epic has made that experiment explicit. It has not yet supplied the finished compatibility promise.