For Honor Leaves Linux - The Open-Platform Question at the Heart of Modern Anti-Cheat

On September 10, 2026, a nine-year-old melee game became the latest flashpoint in one of PC gaming’s longest-running arguments. Ubisoft ended Linux support for For Honor, which also means the game no longer runs on Steam Deck or other SteamOS devices. The reason given was not performance or compatibility. It was anti-cheat.

The decision matters beyond one game’s player base. It shows the tension between open platforms, which let users control their own systems, and competitive integrity, which increasingly depends on publishers trusting the system a player uses. For anyone interested in hardware security, that tension is where the real engineering questions live.

What Ubisoft announced

According to GamingOnLinux’s September 1 report, Ubisoft announced that For Honor would block SteamOS and Linux players from September 10. The game uses Easy Anti-Cheat, which had been enabled for Linux, and the plan was to switch that support off. XDA Developers reported that the notice came in a blog post that also introduced a new Ranked Dominion mode and a rework of Ranked Duel, which puts the change squarely in the context of competitive play.

In the statement quoted by both outlets, Ubisoft framed the move as part of new player safety measures meant to reinforce a fair competitive environment. The key phrase was that the team “cannot meaningfully deploy protection” on Linux. Ubisoft added that it would keep looking at ways to improve its anti-cheat, with the possibility of reopening the platform later.

XDA’s writer noted that what stood out was the reversal. Linux players have been locked out of games before, but here a game that had worked on Linux for years was withdrawn after the fact.

Not an isolated case

GamingOnLinux placed For Honor alongside earlier titles that blocked Linux, naming the Battlefield series, Apex Legends, and GTA V. In a June interview with PC Games Hardware, Valve engineers said the company continues to work with major anti-cheat providers, including Easy Anti-Cheat and BattlEye, and that solutions exist for developers who want to support Linux and Proton. Their emphasis was that it is up to each developer to turn that support on. PCGH also noted that kernel-level anti-cheat is much harder to implement on Linux, and pointed to Apex Legends as an example of a game whose publisher blocked Linux and Steam Deck, citing cheat and exploit risks.

That makes the Steam Machine era awkward. Valve is selling hardware built around SteamOS to mainstream buyers, while the most security-sensitive multiplayer games still decide individually whether that platform is trustworthy enough.

The underlying problem: who controls the machine?

Strip away the brand names and the question is simple. Modern anti-cheat increasingly relies on the operating system and firmware to vouch for the environment a game runs in. On Windows, publishers can lean on a common stack: kernel-mode drivers, signed code requirements, Secure Boot, TPM-based attestation, and virtualization-backed security features. Call of Duty, for example, now requires TPM 2.0 and Secure Boot for online play in its current titles for exactly this reason.

Linux is built on a different premise. Users can compile their own kernels, load their own modules, and change almost any part of the system. That openness is a strength for developers, researchers, and anyone who values control over their hardware. It also means an anti-cheat vendor cannot assume the kernel it is talking to is the kernel the distribution shipped.

When Ubisoft says it cannot “meaningfully deploy protection,” the charitable reading is not that Linux players cheat more. It is that the publisher’s anti-cheat model depends on guarantees it cannot get on a platform designed to let the owner change anything.

Why “just use user-mode anti-cheat” is not a full answer

Critics often point out that Easy Anti-Cheat and BattlEye already support Linux in some form, and that Valve says the tools exist. That is true, and many games run with those protections on SteamOS today. But the level of assurance matters. Publishers that have moved toward kernel components, hardware attestation, and boot integrity checks on Windows are effectively saying that user-mode signals alone no longer meet their bar for ranked play.

From a threat-modeling view, two trends push publishers that way:

• Cheats have moved lower in the stack. Publishers now openly name hardware-assisted tools as part of the threat landscape. Activision’s September cheat economy report, for instance, lists DMA-based cheating hardware alongside software cheats. Defenses that only observe the game process see less of the picture.
• Integrity has become a platform property. Checks increasingly ask whether the whole system booted into a known-good state, not just whether the game’s memory looks normal. That requires cooperation from the operating system and firmware.

On an open platform without a widely accepted attestation story, publishers either accept weaker signals, build something new, or leave. For Honor chose to leave, at least for now.

Better options than blanket blocks

The frustration in community reactions is understandable. Players bought a game that worked and then lost access. There are more nuanced tools the industry could use, and the For Honor case is a good prompt to discuss them:

• Separate matchmaking pools. Activision’s own support documentation describes restricting some modes and placing non-compliant players in separate pools. Similar approaches could keep casual play open while protecting ranked queues.
• Clearer store labeling. PCGH argued that Valve could label anti-cheat restrictions much more clearly on store pages, so buyers know which parts of a game will work before they pay.
• Opt-in attested configurations. In principle, a SteamOS image with verified boot and a locked configuration could give publishers stronger guarantees while leaving ordinary Linux untouched. Nothing announced so far confirms such a plan, but it is the kind of middle ground the ecosystem needs.
• Transparent follow-up. If a publisher removes a platform for integrity reasons, sharing whether cheating actually fell afterwards would build trust far more than a one-paragraph notice.

What this means for defenders and researchers

For security-minded readers, the lesson is that anti-cheat is now a question of platform trust as much as detection. The same building blocks that protect enterprises, such as measured boot, TPM attestation, and IOMMU-based DMA protection, are becoming requirements for competitive games. That creates real research questions: how to attest an open system without taking control away from its owner, how to verify that runtime DMA protections are really enforced, and how to design anti-cheat that respects privacy while resisting low-level threats.

Those questions deserve careful, legitimate study in controlled labs, with findings shared through responsible channels. They do not need cheat tooling, and they are not answered by trying to sneak around a publisher’s platform decision.

The takeaway

Ubisoft’s decision will not be the last of its kind. Until open platforms have a credible, privacy-respecting way to prove their integrity, publishers focused on ranked play will keep treating Linux as a risk to manage, sometimes by walking away. Players, platform holders, and researchers are better served by pushing for a technical middle ground than by treating the fight as a culture war. Fair play and user freedom are both worth defending, and the useful work is finding systems that respect both.