Highguard’s PC launch is already stirring debate: the free‑to‑play PvP raid shooter requires platform‑level security—Secure Boot and TPM 2.0—and won’t launch unless those features are present and properly configured. That requirement is driven by the game’s use of kernel‑level anti‑cheat (Easy Anti‑Cheat), which relies on measured boot and firmware attestation to make cheating far more difficult. If you plan to play Highguard on day one, you should verify and, if necessary, enable Secure Boot and TPM 2.0 now rather than discovering a blocker when you first launch the game.
Highguard’s minimum system checklist now includes not only CPU, GPU, RAM and storage figures but also a platform security baseline: UEFI + Secure Boot = On, TPM 2.0 present and provisioned, and a GPT system disk when switching from legacy BIOS/MBR configurations. That posture mirrors recent AAA launches (Battlefield, Call of Duty, Fortnite tournament rules) where kernel‑level anti‑cheat systems require a trusted boot environment to operate reliably. Those vendors and anti‑cheat providers use measured‑boot attestations that depend on TPM‑anchored logs and firmware‑reported Secure Boot events. The outcome: if Windows reports Secure Boot = Off or TPM not ready, the anti‑cheat stack will refuse to run the title.
This article gives a practical, step‑by‑step path for Windows users to check and enable these features, explains the conversion/workflow requirements (MBR → GPT, BIOS Mode → UEFI), lists manufacturer naming conventions (Intel PTT, AMD fTPM, dTPM), and surfaces the realistic risks and trade‑offs you need to consider before making firmware or partition changes. Where relevant, I verify technical commands and vendor‑facing steps against Microsoft documentation and anti‑cheat guidance.
If you run a typical retail laptop or a mainstream desktop built since roughly 2018, you will probably be able to enable TPM and Secure Boot and play Highguard without swapping parts. If you run an older custom rig, enterprise device under IT policies, or a Linux/Proton setup, expect friction and plan accordingly. The right approach is conservative and methodical: back up, validate (msinfo32/tpm.msc), use Microsoft’s supported mbr2gpt tool when conversion is required, update firmware and drivers, and follow manufacturer guidance for TPM provisioning.
For reference and deeper reading on the technical pieces I relied on when verifying commands and behaviors, see the Easy Anti‑Cheat support notes on measured boot and secure attestation, and Microsoft documentation for enabling TPM and for the MBR2GPT conversion workflow.
Will you be playing Highguard at launch? If your system needs changes, treat this as a short project: back up, validate, convert only after successful validation, then enable TPM and Secure Boot in firmware—done carefully, most gamers will be ready within an hour.
Source: Beebom How to Enable Secure Boot and TPM 2.0 to Play Highguard
Background / Overview
Highguard’s minimum system checklist now includes not only CPU, GPU, RAM and storage figures but also a platform security baseline: UEFI + Secure Boot = On, TPM 2.0 present and provisioned, and a GPT system disk when switching from legacy BIOS/MBR configurations. That posture mirrors recent AAA launches (Battlefield, Call of Duty, Fortnite tournament rules) where kernel‑level anti‑cheat systems require a trusted boot environment to operate reliably. Those vendors and anti‑cheat providers use measured‑boot attestations that depend on TPM‑anchored logs and firmware‑reported Secure Boot events. The outcome: if Windows reports Secure Boot = Off or TPM not ready, the anti‑cheat stack will refuse to run the title. This article gives a practical, step‑by‑step path for Windows users to check and enable these features, explains the conversion/workflow requirements (MBR → GPT, BIOS Mode → UEFI), lists manufacturer naming conventions (Intel PTT, AMD fTPM, dTPM), and surfaces the realistic risks and trade‑offs you need to consider before making firmware or partition changes. Where relevant, I verify technical commands and vendor‑facing steps against Microsoft documentation and anti‑cheat guidance.
Why Highguard (and other modern shooters) demand Secure Boot + TPM 2.0
The technical rationale
- Secure Boot enforces signature verification for early boot components so unsigned or tampered bootloaders and kernel drivers can’t run. This blocks a class of cheats (bootkits, early kernel injections) that attempt to load before or alongside the OS.
- TPM 2.0 provides a hardware root of trust and measured‑boot telemetry (PCRs, measured boot logs). Anti‑cheat systems use TPM attestation to verify that the platform booted exactly as expected and that Secure Boot state was observed by the firmware.
- Together they give anti‑cheat systems a far stronger signal that the environment is clean and untampered—particularly important for free‑to‑play multiplayer titles where cheating pressure is intense.
Real‑world consequences and precedent
Publishers moved this direction after seeing kernel‑level cheat techniques proliferate. Games such as Battlefield and Call of Duty have already required Secure Boot and TPM in recent launches; Epic and other vendors have enforced the same for competitive events. That means this is not unique to Highguard: it’s an industry trend. For players, the practical result is that many modern Windows 11 machines are already compatible, while some older or custom rigs require firmware changes—or in rare cases, hardware upgrades.Quick preflight: what to check in Windows right now
Before touching firmware or partitioning, perform these five fast checks:- Open System Information (Win + R → type msinfo32). Look for:
- BIOS Mode (UEFI or Legacy)
- Secure Boot State (On, Off, or Unsupported)
- Open TPM management (Win + R → tpm.msc) and check:
- Status (e.g., “The TPM is ready for use”)
- Specification version (2.0 required)
- Open Disk Management (diskmgmt.msc). Right‑click the system disk → Properties → Volumes tab → check Partition style (GPT or MBR).
- If you prefer CLI checks:
- PowerShell (Admin): run Confirm‑SecureBootUEFI (returns True if Secure Boot is active).
- If any of those show “Off”, “Legacy”, “MBR”, or “not ready”, follow the full steps below—don’t skip the backup advice.
Step‑by‑step: enabling TPM 2.0 and Secure Boot safely
Important: These operations touch firmware and partitioning. Back up critical files, export BitLocker recovery keys (if BitLocker/Device Encryption is enabled), and be ready to use recovery media if something goes wrong.1) Back up and prepare (do this first)
- Create at least one full file backup and, if possible, a verified full disk image.
- If BitLocker is enabled:
- Export the recovery key (Microsoft account, USB, or printed).
- Suspend BitLocker before making changes (Control Panel → BitLocker → Suspend protection OR manage-bde commands). Failure to suspend often triggers a recovery prompt on reboot.
2) Verify current state inside Windows
- msinfo32 → confirm BIOS Mode and Secure Boot State.
- tpm.msc → confirm TPM presence and Specification Version = 2.0.
- Disk Management → verify the system disk is GPT (required for UEFI/Secure Boot enforcement). If everything already reads UEFI + Secure Boot = On + GPT + TPM 2.0, you’re done.
3) If your disk is MBR: use Microsoft’s supported MBR2GPT tool
- Open an elevated Command Prompt (Run as Administrator).
- Validate first (replace X with the disk number; usually 0):
- mbr2gpt.exe /validate /disk:X /allowFullOS
- If validation succeeds, convert:
- mbr2gpt.exe /convert /disk:X /allowFullOS
- Notes and caveats:
- mbr2gpt enforces strict preconditions (partition counts, BCD health, free space for GPT headers). If validation fails, address the listed issues or plan a clean UEFI reinstall.
- Suspend BitLocker before conversion. Microsoft documents this tool and its preconditions—follow it exactly.
4) Enter UEFI/BIOS and enable TPM (Intel PTT / AMD fTPM / discrete TPM)
- Reboot and enter firmware (common keys: DEL, F2, F10, F12, Esc) or use Windows Advanced Startup → Troubleshoot → Advanced options → UEFI Firmware Settings.
- Look for the TPM option under Security, Advanced, or Trusted Computing.
- Typical labels:
- Intel: Intel PTT (Platform Trust Technology)
- AMD: fTPM or AMD fTPM Switch
- Discrete TPM: dTPM, TPM, Security Device Support, or TPM‑SPI
- Enable the TPM (do not clear it unless you understand the consequences—clearing may destroy keys used by BitLocker). Save and reboot. Confirm tpm.msc now shows TPM ready and Specification Version 2.0.
5) Switch Boot Mode to UEFI and enable Secure Boot
- In UEFI firmware:
- Set Boot Mode to UEFI (disable Compatibility Support Module / CSM / Legacy).
- Find Secure Boot (Boot / Security / Authentication menus).
- If the firmware asks about keys, choose Restore Factory Keys or Install Default Keys and set Secure Boot = Enabled.
- If Secure Boot is greyed out you may need to set a supervisor/admin password in the firmware before enrolling keys.
- Save and exit firmware. Boot into Windows and verify msinfo32 now shows Secure Boot State = On and BIOS Mode = UEFI. Optionally, run Confirm‑SecureBootUEFI in PowerShell to confirm True.
Troubleshooting: common failures and fixes
- Secure Boot still shows Off or the anti‑cheat complains after you enabled it:
- Fully power off the PC (shut down and remove standby power if possible) and power on; some firmwares only finalize new variables after a cold boot.
- Toggle Secure Boot to Custom then back to Standard/Default; save, reboot, and re‑check msinfo32.
- Update UEFI/BIOS to the latest vendor release—older firmware sometimes fails to produce the expected measured boot event.
- mbr2gpt validation fails:
- Read the tool’s diagnostics—they will tell you which precondition is missing (too many partitions, insufficient space for headers, bad BCD, etc.). Fix that specific problem or plan a clean UEFI reinstall.
- BitLocker recovery triggered and you don’t have the key:
- This is why backing up/preserving the key is non‑negotiable. Without the recovery key you risk losing access.
- Anti‑cheat errors referencing measured boot logs, PCR mismatch, or missing events:
- Easy Anti‑Cheat documents these exact errors and points to TPM/Secure Boot misconfiguration or missing measured boot events as root causes; ensure your firmware is updated and that you haven’t removed measured boot data with third‑party utilities.
Manufacturer notes and naming conventions
Firmware menus are inconsistent. When following vendor writeups, look for these terms:- Intel platforms: “Intel PTT”, “Platform Trust Technology”
- AMD platforms: “fTPM”, “Firmware TPM”, “AMD fTPM Switch”
- Motherboards: “TPM”, “TPM Device”, “Security Device Support”, “TPM‑SPI”
- Secure Boot may be under Boot, Security, or Authentication; sometimes labeled OS Type = Windows UEFI, or “Secure Boot Mode” (Standard/Custom). If in doubt, consult your OEM guide.
The trade‑offs, risks and broader concerns
Strengths — what you gain
- Stronger anti‑cheat assurance. TPM + Secure Boot + kernel anti‑cheat produce a much higher bar for persistent and low‑level cheats.
- Improved platform security. Secure Boot reduces early‑boot attack surface, and TPM enables better BitLocker protection and attestation features.
- Future proofing. Windows 11 and many publishers are building on these primitives; enabling them reduces friction for future titles and updates.
Real and perceived risks
- BitLocker lockouts and data loss if you make firmware changes without backups or if you clear the TPM inadvertently.
- Driver and compatibility breakage. Secure Boot enforces kernel driver signature checks—old unsigned drivers (legacy AV, RAID/HBA drivers) may fail to load. Expect to update drivers or remove incompatible kernel‑mode components.
- Linux and Proton / Steam Deck exclusion. Requiring Secure Boot/TPM makes many Linux devices and Proton/Steam Deck setups unable to run these games at launch, effectively reducing platform flexibility. This has been widely reported as a community pain point.
- Privacy and security concerns around kernel anti‑cheat. Kernel‑level anti‑cheat drivers operate with high privilege. While they aim to prevent cheating, they raise questions about stability, vulnerabilities, and telemetry—debates that reoccur on each major adoption wave.
Mitigations
- Always back up and export BitLocker keys.
- Update firmware and drivers before toggling Secure Boot.
- Test changes on a secondary device if possible, and document firmware steps for your particular OEM.
- If you dual‑boot Linux, research signed shim options or consider keeping Secure Boot off for that machine and using a separate, Secure Boot‑enabled Windows system for gaming.
A step‑by‑step checklist you can copy
- Back up everything and export BitLocker recovery keys.
- Run msinfo32 → confirm BIOS Mode = UEFI and Secure Boot State.
- Run tpm.msc → confirm TPM present and Specification Version = 2.0.
- If system disk = MBR:
- Open Admin CMD:
- mbr2gpt.exe /validate /disk:0 /allowFullOS
- mbr2gpt.exe /convert /disk:0 /allowFullOS
- Reboot → enter UEFI/BIOS → enable Intel PTT / AMD fTPM / TPM.
- Set Boot Mode to UEFI, disable CSM/Legacy.
- Enable Secure Boot (restore factory/default keys if prompted).
- Save, reboot to Windows, verify msinfo32 shows Secure Boot = On and tpm.msc shows “ready”.
- Re‑enable BitLocker (if used) and update protectors if necessary.
- If Highguard or anti‑cheat still fails, cold power cycle the system, check BIOS updates, and consult vendor or anti‑cheat support for measured‑boot diagnostics.
Final analysis: is this reasonable for gamers?
On balance, the requirement is technically defensible: anti‑cheat vendors and publishers want higher assurance against low‑level cheating. For the majority of modern Windows 11 users, enabling Secure Boot and TPM is a one‑time firmware toggle. But the enforcement has real consequences: it raises the bar for older hardware, blocks many Linux/handheld setups, and forces some users to confront complex procedures (MBR→GPT conversion, BitLocker handling, firmware quirks).If you run a typical retail laptop or a mainstream desktop built since roughly 2018, you will probably be able to enable TPM and Secure Boot and play Highguard without swapping parts. If you run an older custom rig, enterprise device under IT policies, or a Linux/Proton setup, expect friction and plan accordingly. The right approach is conservative and methodical: back up, validate (msinfo32/tpm.msc), use Microsoft’s supported mbr2gpt tool when conversion is required, update firmware and drivers, and follow manufacturer guidance for TPM provisioning.
Closing (practical verdict)
If you want to play Highguard on launch day, verify your Secure Boot and TPM state now. The steps are clear and well‑documented—use msinfo32 and tpm.msc to check, convert MBR→GPT only after validation with mbr2gpt, enable Intel PTT or AMD fTPM in firmware, then enable Secure Boot and enroll factory keys. Keep backups and BitLocker keys handy: the single biggest operational risk is being locked out by a firmware change without recovery credentials. Publishers and anti‑cheat providers are doubling down on these primitives to protect competitive ecosystems, but the rollout does require users to understand a few new technical knobs. If you need help with a specific motherboard or OEM model, note the make/model and follow the vendor’s step‑by‑step guide—manufacturer menus vary and a model‑specific walkthrough is safer than guessing.For reference and deeper reading on the technical pieces I relied on when verifying commands and behaviors, see the Easy Anti‑Cheat support notes on measured boot and secure attestation, and Microsoft documentation for enabling TPM and for the MBR2GPT conversion workflow.
Will you be playing Highguard at launch? If your system needs changes, treat this as a short project: back up, validate, convert only after successful validation, then enable TPM and Secure Boot in firmware—done carefully, most gamers will be ready within an hour.
Source: Beebom How to Enable Secure Boot and TPM 2.0 to Play Highguard
