Electronic Arts has quietly signaled a possible turning point for PC gaming on Arm-based hardware: a new job posting reveals the company is hiring a senior engineer specifically to build a native ARM64 kernel driver for
EA Javelin Anticheat, with explicit goals to enable
Windows on Arm support and to “chart a path” toward broader Linux and Proton compatibility. If realized, this work would remove a major technical barrier that has kept many EA multiplayer titles off Snapdragon, Copilot+ and other ARM-powered Windows devices — but it also raises hard technical, security and privacy questions that gamers, OEMs and platform maintainers will want answered before cheering the arrival of more native EA titles on ARM hardware.
Background / Overview
Windows on Arm has evolved from a niche experiment into a practical platform for thin, battery-efficient laptops and handheld PCs. Modern ARM silicon and aggressive emulation/translation layers have closed much of the performance gap for native apps, but one stubborn compatibility gap has remained:
kernel-level anti-cheat systems.
Anticheats that run in the operating system kernel hold unique power to detect sophisticated cheats, but they also carry systemic consequences. Many of the industry’s most deployed anti-cheat engines were originally developed around x86_64 assumptions. When an anti-cheat vendor requires kernel-level components or particular firmware features, that can effectively block games from running on non‑x86 platforms or under translation layers such as Proton.
EA’s internal anti-cheat — recently rebranded as
EA Javelin Anticheat — is one such kernel-mode system. Designed to detect and intervene against ring‑0 cheats and tampering, Javelin’s deep coupling with OS internals and hardware trust features has improved detection rates for EA titles, but also produced platform friction. Historically this has translated into explicit requirements like Secure Boot and TPM and a tendency to block or fail on Linux-based and some ARM environments.
The new job posting makes EA’s intentions explicit: build native ARM64 kernel capabilities for Javelin and put in the infrastructure to test, validate and — over time — explore broader OS and runtime support (including Linux/Proton). That’s a strong signal that EA views ARM as a material platform for future PC play and is willing to invest in the lowest, most sensitive layers of the stack to make its multiplayer ecosystem portable.
What the job listing says — and why it matters
The position being recruited is framed as a senior anti-cheat engineering role focused on ARM64. The responsibilities described in the posting are direct and operationally significant:
- Develop a native ARM64 kernel driver for EA Javelin Anticheat, not a user-mode shim or partial translation layer.
- Implement logic to load different anti-cheat binaries depending on user hardware, enabling runtime selection between x86_64 and ARM64 variants.
- Build automated build and test pipelines for validating Javelin on a variety of ARM hardware.
- Design mitigations for emerging security threats on ARM and plan for potential support on additional OSes and runtimes such as Linux/Proton.
The requirements emphasize low-level Windows experience (driver development, machine-code debugging, compiler toolchains) and ARM experience. The combination of responsibilities and required skills indicates EA expects this to be a full port, not a stopgap.
Why that matters:
- A native kernel driver avoids brittle translation issues that typically plague kernel-mode code under emulation. It’s the most robust route to parity on ARM.
- Multi‑binary loading suggests EA will maintain separate artifacts per architecture and make runtime decisions based on device capabilities — an important engineering and signing challenge.
- The inclusion of Linux and Proton in the posting signals EA is assessing how Javelin might function in compatibility layers — a necessary step if EA wants its catalog to run under Proton-enabled environments like Steam Deck or handheld Linux PCs.
At the same time, a job posting is a commitment to hiring effort and investigation, not delivery of product. The road from hiring to shipping fully functional, signed kernel drivers across diverse ARM hardware and OS combinations is long and full of policy, technical and legal gates.
The technical challenge: porting a kernel-mode anticheat from x86_64 to ARM64
Porting kernel-level code is one of the hardest engineering tasks in system software. It’s not merely recompilation — there are deep architectural shifts to address:
1. ABI, calling conventions and CPU semantics
ARM64 uses different calling conventions, exception mechanisms, and interrupt handling from x86_64. Kernel code often relies on architecture-specific behaviors, inline assembly, and CPU intrinsics. Replacing or reengineering these hotspots requires careful redesign and rigorous low-level testing.
2. Memory model and instruction ordering
Subtle differences in memory models and concurrency primitives can introduce race conditions, deadlocks, or data corruption if ported naively. Anticheat drivers operate under intense timing and concurrency pressure; correctness under adversarial conditions is paramount.
3. Driver model and kernel interfaces
Windows kernel driver frameworks are consistent across architectures, but platform mismatches (e.g., device descriptions, CPU features) require architecture-aware code paths. Kernel APIs that assume x86 details must be re-examined; some low-level protections rely on x86 features that have no direct ARM analogue.
4. Signing, Secure Boot and driver distribution
Microsoft enforces driver signing and, on modern Windows versions, tighter Secure Boot interactions. Distributing an ARM64 kernel driver means complying with Windows kernel signing policies for ARM devices and ensuring the driver will load across OEM firmware variants and Secure Boot configurations. That can be a significant barrier to broad deployment.
5. Testing matrix complexity
ARM hardware is heterogeneous. There are multiple SoC vendors, firmware versions, OEM boot chains and peripheral configurations. Building a robust continuous integration (CI) pipeline for ARM kernel testing requires assembling physical hardware pools, firmware test harnesses, and automated validation — exactly the sort of work the job posting highlights.
6. Interoperation with translation layers (Proton/Prism)
Even with a native ARM driver, games often run through compatibility layers or emulation (x86 binaries on ARM). Ensuring the anticheat cooperates with those layers — or at least does not prevent them from functioning — is nontrivial. Proton and Windows’ own Prism translation interact with kernel and user-mode hooks in complex ways; any kernel driver must be architected to behave predictably in those contexts.
Security and privacy implications: power, trust and risk
A kernel-mode anticheat is uniquely powerful: it can inspect memory, hook system events and influence hardware access. That power yields both the defensive capability to catch advanced cheats and systemic risks if misused or buggy.
Benefits
- Improved detection: Kernel visibility lets Javelin detect cheats that operate at ring‑0 or alter system state in ways user-mode sensors cannot.
- Reduced match tampering: For competitive titles, robust kernel defenses can measurably reduce real-time cheating and protect player experiences.
Risks
- Increased trusted computing base (TCB): Adding more code to kernel space increases the attack surface. Vulnerabilities in a kernel driver can lead to crashes, privilege escalation and persistent compromise.
- Supply-chain and update risk: Kernel drivers must be updated safely and audibly. An attacker who compromises the driver distribution or update channel could gain a powerful foothold.
- Telemetry and data handling: Anticheat systems necessarily collect signals about system state. Clear, auditable limits on telemetry, retention and sharing are essential to preserve user privacy and trust.
- Stability and third-party conflicts: Kernel-mode components can conflict with other drivers, causing blue screens and preventing gameplay — a significant UX risk if the driver interacts poorly with certain VPNs, device utilities or third-party drivers.
Because the job posting calls for engineering efforts in the kernel,
EA will need to be transparent about how the ARM driver is signed, how it is updated, and how telemetry is bounded. Without that transparency, users and OS vendors will remain cautious.
Platform politics: Secure Boot, TPM and Proton compatibility
Kernel anti-cheats often rely on firmware-backed signals to counter advanced, pre-boot tampering. This has real ramifications:
- Secure Boot and TPM requirements: Titles protected by kernel anti-cheats have in the past required Secure Boot and TPM to be enabled. Those requirements can exclude older hardware and some Linux-based devices. Enforcing Secure Boot is a straightforward defense against unsigned kernel modifications, but it also raises consumer compatibility questions.
- Proton and Steam Deck: Proton is widely used to run Windows games on Linux systems. However, Proton environments historically lack the firmware-backed features anti-cheat drivers expect, and they do not provide a compatible kernel environment for Windows drivers. Even with an ARM64 Javelin driver, Proton compatibility requires architectural work from EA, Valve and the Proton maintainers to emulate or otherwise satisfy firmware and driver expectations safely.
- Driver signing and platform policies: Microsoft’s signing policies for kernel drivers on Windows on Arm may be more restrictive or different in practice across OEMs. EA will need to navigate these policies to ensure the driver loads reliably on shipped devices.
The job posting’s mention of Linux and Proton is notable: it signals EA is at least studying the compatibility problem rather than pushing a hard platform lockout. That is encouraging but not a guarantee of Steam Deck or Proton support — those are still complex negotiations involving firmware, OS and policy.
Market context: why EA is doing this now
Several market dynamics help explain the timing:
- Arm silicon on the rise: PC vendors are shipping more Arm-based laptops and handhelds with significant compute capability and extended battery life. High-profile moves in the ARM silicon space — including new architectures and even rumors of large players bringing Arm CPUs into mainstream PC silicon — change the addressable market for native PC games.
- Developer and middleware momentum: Other anti-cheat vendors and middleware have started providing Arm support. When major components of the ecosystem move, publishers face pressure to follow or risk fragmenting their player base.
- Player demand and OEM strategy: Hardware makers want to advertise compatibility with popular AAA titles. EA enabling Javelin on Arm would remove a visible friction point for OEMs and gamers alike.
These commercial incentives make the investment logical. However, the business calculus does not erase the technical and trust hurdles.
What this means for gamers, OEMs and open-platform advocates
Gamers
- If EA successfully ships ARM64 Javelin drivers, more EA titles might run natively or reliably on ARM-based Windows devices. That would broaden consumer choice and could improve battery-life-backed play scenarios.
- Users should be prepared for the possibility of new platform requirements (Secure Boot, TPM or driver signing) — not all old devices will be supported.
OEMs
- OEMs shipping Arm devices will benefit from broader game compatibility, but they will also need to coordinate firmware and driver distribution practices to ensure the anticheat driver loads securely.
- OEMs must validate that drivers do not disrupt other preinstalled software or cause system instability.
Linux and Proton advocates
- The job posting’s reference to Proton is an olive branch, but Proton compatibility will require more than EA porting a kernel driver; it may require co‑operation across Valve, EA and perhaps the wider anticheat ecosystem to provide safe, auditable ways to run protected titles under compatibility layers.
- Until such cross‑vendor coordination exists, some devices like the Steam Deck may remain unsupported for certain EA titles.
Strengths of EA’s approach — and significant caveats
Strengths
- Technical completeness: Building a native ARM64 kernel driver is the most durable way to deliver equivalent anti-cheat coverage on Arm hardware.
- Operational readiness: The job emphasis on test pipelines and multiple binary support shows EA is thinking beyond a single-device proof‑of‑concept to real-world rollout considerations.
- Long-term thinking: Including Linux/Proton in the roadmap suggests EA is not content to only chase Windows on Arm but is considering cross-platform compatibility strategies.
Caveats and open questions
- Timeline: Hiring and porting are multi‑quarter efforts. The job posting does not equal an imminent rollout.
- Policy and signing: How will the driver be signed and distributed? Will Microsoft’s platform policies restrict deployment across OEMs?
- Transparency: Will EA publish third‑party audits or clear telemetry policies that reassure privacy-conscious users?
- Compatibility trade-offs: Will EA require Secure Boot or other firmware features by default, and will that exclude older or enthusiast devices?
- Risk of regressions: Kernel drivers have caused game-launch failures in the past; rigorous cross‑vendor testing is essential.
Because many of these questions hinge on policy decisions and implementation details, users and community advocates should treat the job posting as a meaningful signal, but not a concrete promise.
Short-term likely outcomes and possible timelines
- Hiring and initial architecture (0–3 months): EA fills the role, completes design reviews and begins porting critical code paths to ARM64.
- Prototype drivers and internal testing (3–9 months): Proof-of-concept drivers run on a small set of ARM hardware, with automated tests in CI.
- Beta validation and OEM engagement (9–18 months): Wider testing across OEM devices, driver signing and distribution channels created, and limited rollouts to users of supported hardware.
- Broader Linux/Proton experiments (12–24+ months): If early work is successful, EA and the anticheat team may run experiments with Valve/Proton maintainers around compatibility approaches. This is the most uncertain phase; Proton integration requires platform-level coordination.
These are rough estimates and depend heavily on hiring speed, available hardware pools, and external stakeholder cooperation.
Practical advice for players and IT pros
- If you own an Arm-based Windows PC: Don’t expect immediate support for every EA title. Watch for official EA support notes and driver updates. Be cautious about enabling or disabling Secure Boot and consult EA’s published guidance if a game fails to run.
- If you manage fleets or lab devices: Consider building test images that can validate anticheat driver behavior without risking production systems. Kernel drivers can affect device stability.
- If you use Linux/Proton: Continue following Proton and Valve developments. Prognoses about Proton support require vendor cooperation, not just publisher intent.
- For privacy-conscious users: Demand transparency. Ask EA to publish clear telemetry policies and third‑party audit results for kernel components.
Conclusion
EA’s job posting for a senior ARM64 anti-cheat engineer is a concrete technical signal that the company is preparing to invest in
Windows on Arm as a first‑class platform for its multiplayer titles. Building a native ARM64 kernel driver for
EA Javelin Anticheat would remove one of the most stubborn blockers to gaming on Arm devices and opens the door to future experiments with Linux and Proton.
That opportunity comes with real caveats: kernel drivers are powerful and risky; driver signing, Secure Boot and firmware dependencies can fragment compatibility; and Proton support will require collaboration across vendors. For gamers and industry watchers, the posting is encouraging but should be read as the start of a long project rather than a near-term fix. EA’s approach promises technical completeness and operational rigor, but success will depend as much on transparent policies, secure distribution practices and cross‑industry cooperation as on engineering effort.
If EA executes responsibly — with robust testing, auditable privacy commitments and clear communication — native Javelin on ARM could be a genuine enabler for gaming on energy‑efficient devices. Until then, the community should welcome the intent, watch implementation details closely, and insist on the safeguards that make powerful kernel code safe for every player’s machine.
Source: TechPowerUp
EA Working on Javelin Anticheat Port for Windows-on-Arm