Translated from the Japanese original
On October 14, 2026, Epic Games announced that it will rebuild the Linux implementation of its Easy Anti-Cheat software as “EAC Linux v2.” The goal is protection closer to that of the Windows version. But instead of installing a dedicated anti-cheat kernel module, Epic plans to combine Linux’s built-in security features with eBPF. It will first run a trial with Fortnite, check the results, and then extend the system to other game developers. To bring more games to Linux, it is no longer enough for the games themselves to support it. The question now is who signs the kernel, and with what configuration it boots.
No dedicated module, but still OS-level protection
In EAC Linux v2, the first time you launch a protected game, you are asked to install an anti-cheat systemd service. systemd is the mechanism Linux uses to manage starting and stopping services. This service is designed to run when the game starts and stop when it ends.
In the FAQ of its official announcement, Epic explains: “EAC Linux v2 does not install or load an anti-cheat kernel module.” Even without a dedicated module, however, it still exercises control deep within the OS. For that it uses eBPF, which runs programs using kernel functionality, and BPF LSM, which monitors and restricts security-related operations.
The official Linux kernel documentation describes BPF LSM as a feature that lets privileged users implement system-wide access control and auditing. Epic says it will use this to restrict other processes from reading or writing the memory of a protected game, and to monitor for cheating. It would be premature to take the claim that there is no dedicated module to mean that ordinary low-privilege apps alone provide the protection.
EAC’s Linux support itself is not new. It has supported native Linux games since 2014, and games run on Linux through Wine/Proton since 2021. Even so, it has to be enabled game by game, and some games held back because the Linux implementation could not offer protection on par with the Windows version. v2 is meant to close that gap in protection
Eight requirements check signatures, boot records, and runtime state
The eight EAC Linux v2 requirements Epic presented on October 14, 2026 can be sorted into three roles: verifying signatures, recording what was booted, and restricting changes after boot. Grouping requirements 1 to 8 in the official technical blog by what each mainly verifies or restricts gives the following.
| Main role | Requirement | State Epic requires |
|---|---|---|
| Verifying signatures | Signed kernel and modules | Use ones built by an organization and signed with a signing key Epic recognizes |
| Verifying signatures | Secure Boot | Enabled in the BIOS and booting with a recognized key |
| Recording boot contents | TPM 2.0 | Enabled in the BIOS, serving as the basis for a tamper-resistant boot record |
| Recording boot contents | Boot-time measurement | Measurements of executed code and configuration are recorded |
| Restricting changes after boot | IOMMU | For non-handheld devices, enabled in the BIOS and kernel, with passthrough disabled |
| Restricting changes after boot | Kernel lockdown | Integrity mode explicitly specified and enabled at boot |
| Restricting changes after boot | kexec disabled | Explicitly specified and disabled at boot |
| Restricting changes after boot | BPF LSM | Loaded and enabled |
The three categories in the table are our own grouping based on each feature’s main role, not a classification Epic itself presented. The features are also interrelated: the TPM supports boot-time measurement, and disabling kexec keeps the system consistent with the measurement record. Epic says the requirements may change in the future, and the table does not show measured protection performance.
Secure Boot and boot-time measurement look similar but verify different things. The former verifies the signatures of the code that boots, while the latter records information about the code and configuration that actually booted in the TPM. With that record, Epic explains, the boot contents can be checked afterward, without the anti-cheat itself having to run continuously from OS startup.
But if the kernel can be swapped after the record is made, the earlier boot record alone can no longer explain the current state. Disabling kexec, which moves to a new kernel without a full reboot, is meant to prevent this mismatch. Lockdown, which curbs things like kernel modification by administrator privileges, also helps preserve the post-boot state.
IOMMU is a feature that controls direct access to physical memory from devices. Epic lists it to prevent cheating hardware from accessing the game, but it limits the enablement requirement to “non-handheld devices.” That limit applies only to the IOMMU item and does not mean handheld devices are exempt from the remaining requirements.
Self-signing alone does not meet the conditions
For users who build their own kernels or drivers, the difference between adding a signature and being recognized by EAC Linux v2 is significant. Epic requires that the kernel and any additional modules be built by an organization and signed with a recognized key. It is not a system where signing with any key of your choosing satisfies the condition.
Linux’s module signing feature is a mechanism by which the kernel verifies a signature when loading a module. Upstream documentation describes settings that allow unsigned modules or modules with unknown keys, and settings that accept only valid signatures verifiable with the public keys the kernel holds. In other words, beyond Linux being able to verify a signature, EAC v2 also makes the building organization and the signing key a condition.
Many Linux drivers are included in the kernelrnel. On the other hand, the same conditions extend to external modules such as the NVIDIA GPU driver, which Epic cited as an example. Users will be affected by whether a configuration with recognized signatures can be prepared, including the GPU driver needed to run games
Epic will initially manage the list of recognized signing keys itself, and aims to open-ora, and Universal Blue, which is used by Bazzite and others, but it is a list of keys, not a guarantee that any individual game will work. Epic calls on distribution maintainers to respond to the configuration requirements and to discuss adding their keys
You do not have to lock your everyday environment into game-oriented settings at all times. Epic suggests preparing a separate boot entry that specifies the required kernel and boot settings, and choosing it when playing protected games. However, when booting through shim, all enrolled MOKs (Machine Owner Keys) used for module verification must be recognized keys, so separating boot options does not necessarily let you keep arbitrary keys alongside. If a game is launched without meeting the requirements, Epic says it will show an error rather than suspend the account.
Fortnite goes first, and existing games can choose whether to migrate
Epic plans to try EAC Linux v2 first in a live Fortnite environment, verify its effectiveness, and then offer it to other developers. The description of protection close to the Windows version is, for now, a level Epic is aiming for. No specific release date has been given, so the announcement cannot be treated as meaning Fortnite is now playable on Linux.
As for Steam Deck, Epic explains that it currently does not meet the features v2 needs. The company is in talks with Valve and hopes to support it in the future, but it has not disclosed which features are missing or when support might arrive. The plan to expand Linux support cannot simply be read as a commitment to support Steam Deck.
Games that already have EAC Linux support enabled keep a choice. Developers can keep the old implementation to prioritize compatibility, or switch to v2 to strengthen protection. The policy is not to move all games to the new requirements at once.
Epic expects that the more distributions meet the required features in their default settings, the fewer configuration changes users will need to make. Whether Fortnite can demonstrate the protection effect is one factor, but adoption will also depend on distributors preparing signed configurations and game developers choosing to adopt it. If both progress, it could reduce the burden on Linux users of adjusting their own environments to play competitive games.
