"SecureBoot is not enabled" — The Battlefield 6 Error That Lied to Me for Two Days

How a misleading error message, a Linux bootloader, and an anti-cheat update collided — and the forensic trail that finally exposed the real culprit.

The Symptom

One evening in mid-July 2026, I closed Battlefield 6 after a normal session, stepped away for ten minutes, and relaunched it. Instead of the game, I got this:

SecureBoot is not enabled. Learn how to use SecureBoot at go.ea.com/SecureBoot

No warning, no crash, no change on my side. It worked, and then it didn't.


I checked the obvious thing first: Secure Boot. It was on. `Confirm-SecureBootUEFI` returned `True`. `msinfo32` said *Secure Boot State: On*. TPM 2.0 present and ready. UEFI mode. GPT disk. Every prerequisite EA lists — green.


And yet the game insisted otherwise.

Red Herring #1: "It's a BIOS problem"

Almost every guide for this error tells you to enable Secure Boot in BIOS. My BIOS is password-locked, which turned out to be irrelevant — Secure Boot was never off. If you take one thing from this article, take this:

"SecureBoot is not enabled" does not mean Secure Boot is off. It means EA's Javelin anti-cheat failed to start, and this is the generic page it shows you.

The game cannot launch its anti-cheat service, and rather than telling you why, it shows the most common cause's troubleshooting page. Everything after this realization was about finding what was actually killing the service.

Red Herring #2: The Disappearing Service

Digging into the Windows event logs revealed a bizarre pattern. Every launch did this:

13:54:52  Event 7045  A service was installed: EAAntiCheatService
13:54:54  Event 7045  A service was installed: EAAntiCheatService
13:55:03  Event 7023  The EAAntiCheatService service terminated with
                      the following error: %%4294901871

The launcher would install the Javelin service, start it, and the service would deliberately kill itself about ten seconds later with EA's internal error code `0xFFFF006F`. Then the service registration vanished entirely (`OpenService FAILED 1060 — service does not exist`), which is why every launch also popped a UAC prompt for `EAAntiCheat.Installer.exe --install -title bf6` — it was reinstalling from scratch each time.


A UAC prompt at every launch is itself a tell: on a healthy system the anti-cheat service is installed once and merely started at launch. If you're being asked for admin every time, the service is dying and being wiped on every attempt.

The Elimination Gauntlet

Over two days, every plausible cause was tested and eliminated:

The machine was, by every measurable standard, perfect. And Javelin still refused to run.

The Clue That Broke the Case

Two facts didn't fit any theory:

1. The failure started between two game launches, minutes apart, with no reboot and no system change — only a silent Javelin update in between.
2. The machine is a dual boot: Kubuntu lives on half the drive.

Fact #2 turned out to be everything. Checking the firmware boot entries:


displayorder  {1f4bb913-...}   ← Kubuntu   (\EFI\ubuntu\shimx64.efi)  FIRST
            {bootmgr}        ← Windows Boot Manager

The PC never booted Windows directly. Every single boot went:

firmware → shim (shimx64.efi) → GRUB → Windows Boot Manager → Windows


Secure Boot was on — but the boot chain contained a third-party bootloader. And a machine's TPM faithfully measures every link of that chain into its boot log, readable at runtime by any software that cares to look.


EA Javelin cares. The July 16 update appears to have added (or tightened) a boot-chain integrity check: if the path from power-on to Windows passes through GRUB — a component designed to load arbitrary kernels — the chain of trust reads as compromised. Javelin kills its own service with `0xFFFF006F`, and the game shows... the Secure Boot page.


No reboot was needed for the breakage because the check happens at service start, against the TPM's record of the current boot. The update landed while I was AFK; the next launch was judged by new rules.

The 5-Minute Test That Proved It

After two days of forensics, the decisive experiment took five minutes:
1. Shut down
2. Power on → tap Esc → F9 (HP Boot Device Options)
3. Select Windows Boot Manager — booting Windows without GRUB in the chain
4. Launch Battlefield 6

The game started. First time in two days.

Same Windows, same files, same anti-cheat build, same Secure Boot state. The only variable removed was GRUB — and that was the whole problem.

The Fix (Permanent)

1. Set Windows Boot Manager as the first firmware boot entry (from admin PowerShell: `bcdedit /set {fwbootmgr} displayorder {bootmgr} ...`), so normal power-ons boot straight into Windows.
2. Kubuntu remains untouched and fully usable: Esc → F9 → Kubuntu entry whenever you want Linux.
3. No game reinstall, no Windows reinstall, no BIOS changes needed. (For the record: an in-place Windows repair install was attempted and refused — "couldn't update the system reserved partition," a classic dual-boot small-ESP issue. Bullet dodged; it wouldn't have fixed anything.)

Lessons

1. Error messages lie by omission. "SecureBoot is not enabled" meant "our service failed its integrity check." When the stated cause is provably false, translate the message to "something in the anti-cheat's startup is unhappy" and hunt that.
2. The service dying with a vendor error code is the real error. `%%4294901871` in the System log was the truth the whole time; the popup was a cover story.
3. A UAC prompt for the anti-cheat installer at every launch means the service is being wiped every launch. Persistent services don't ask.
4. Dual-boot users are canaries. Any anti-cheat that validates the measured boot chain can break on a GRUB/shim path overnight, via a silent update, with zero local changes. If your game worked yesterday and blames Secure Boot today, ask: how did I boot this machine?
5. Boot into Windows directly if you game on a dual-boot machine. Keep Linux on the F9 menu. It costs two seconds and saves two days.
   
   

The Short Version for Search Engines

Battlefield 6 "SecureBoot is not enabled" on a dual-boot PC: EA Javelin's July 2026 update fails its boot-chain integrity check when Windows is booted through GRUB/shim. Secure Boot being on doesn't matter. Fix: boot Windows directly via Windows Boot Manager (set it first in firmware boot order, or pick it from the BIOS boot menu with Esc/F9 on HP). Keep Linux bootable from the boot menu. No reinstall required.



Postscript: if you're an EA engineer reading this — error `0xFFFF006F` on a Secure-Boot-enabled HP dual-boot machine, boot chain via shim/GRUB. A clearer message ("unsupported boot chain detected") would have saved everyone a weekend.