Riot’s kernel-level anti-cheat, Vanguard, stopped being a single-player headache in 2026. Schools running Valorant clubs, LAN centers renting seats by the hour, and esports orgs managing dozens of practice PCs all hit the same wall: Vanguard installs and uninstalls itself separately from Valorant, loads a kernel driver before most of Windows finishes booting, and now ships an entirely new “On-Demand” mode with its own hardware checklist. None of that is documented for IT admins who need to manage the driver across twenty, two hundred, or two thousand machines instead of one gaming PC.

If you’re looking for the consumer-side steps to uninstall Valorant on one PC or to bulk-remove it across a handful of personal accounts, those guides cover that ground already. This tutorial is written for a different audience: system administrators, IT technicians, and security teams who need to audit, configure, deploy, or remove Riot Vanguard at scale using Intune, SCCM, and PowerShell remoting, not a single player trying to free up disk space. We’ll cover the current state of Vanguard On-Demand, the Windows 11 25H2 security baseline it depends on, and a complete working script you can adapt for your own fleet. By the end you’ll have a repeatable, auditable process instead of a pile of one-off support tickets.

Why Riot Vanguard Became an IT Problem in 2026

Riot Vanguard is no longer a Valorant-only component. It’s the shared kernel anti-cheat layer Riot uses across its PC titles, and it behaves like platform infrastructure rather than a game add-on. That distinction matters for fleet management: you can’t treat Vanguard as something that comes and goes with a single game install, because removing Valorant does not remove Vanguard. Riot ships them as separate installed programs, and the Vanguard services keep running (and loading at boot, in the default configuration) until they’re removed on their own.

Two things changed in 2026 that pushed this from an occasional support ticket into a real IT planning question. First, Riot rolled out Vanguard On-Demand starting June 24, 2026, letting the driver load only when a supported Riot game launches instead of at every boot, but only on machines that meet a specific Windows 11 25H2 security baseline. Second, Windows 11 version 25H2 itself reached General Availability, with Microsoft’s own release-health documentation listing build 26200.9445 in the General Availability Channel as of September 8, 2026, literally the week this guide was written. Together, those two changes mean the “install it and forget it” era of managing Vanguard on lab machines is over.

This shift in how the wider esports ecosystem treats anti-cheat infrastructure is a direct byproduct of Vanguard’s install base. For LAN centers and cyber cafes billing by the hour, an early-loading kernel driver on every machine is a real boot-time cost multiplied across dozens of seats. For schools and esports orgs, it’s a compliance and security question: a third-party kernel driver on managed hardware needs the same change-control rigor as any other privileged software. Both groups need the same thing, a documented, scriptable way to know where Vanguard is installed, decide whether it should stay, and remove or reconfigure it without breaking the rest of the security stack.

What Riot Vanguard Actually Does at the Kernel Level

Vanguard’s core component is a kernel-mode driver, documented in Riot’s own Vanguard support articles and commonly referenced by its service name vgk, paired with a user-mode client service, vgc. The kernel driver is what makes Vanguard controversial among IT teams: by default it loads very early in the Windows boot sequence, before most third-party drivers initialize, so it can monitor the boot chain rather than just the game session. That’s also exactly why it can collide with other kernel-level software, virtualization platforms, packet capture tools, and other anti-cheat engines that want similarly privileged, similarly early hooks into the OS.

On a managed endpoint, Vanguard leaves a predictable footprint: two Windows services (vgk and vgc), registry keys under HKLM\SYSTEM\CurrentControlSet\Services, and an install folder under Program Files. That footprint is what makes fleet auditing possible in the first place. You’re not guessing whether Vanguard is present, you’re querying known service names and paths across every machine in your inventory.

The On-Demand model changes when that driver loads, not what it is. Instead of the kernel driver initializing at every boot, Vanguard is only loaded when a Riot game that requires it actually launches, and it can unload again afterward. Riot ties this to a specific hardware and OS trust baseline, described in the next section, because on-demand loading of a kernel anti-cheat driver only makes sense if the platform underneath it can already attest that the boot chain, firmware, and code-integrity policy are intact.

ComponentTypeTypical IdentifierFleet-Relevant Behavior
Kernel driverKernel-mode servicevgkLoads at boot by default; On-Demand mode delays load until game launch
Client serviceUser-mode servicevgcManages updates and communicates with Riot’s backend
Install directoryFile systemProgram Files\Riot VanguardPersists independently of the Valorant client folder
Registry hiveService configurationHKLM\SYSTEM\CurrentControlSet\Services\vgk / vgcPrimary detection point for audit scripts

Prerequisites and Environment Requirements

Before touching a production fleet, confirm you have the following in place. None of this is Vanguard-specific tooling, it’s the standard endpoint management stack most IT teams already run, plus a short list of Vanguard’s own requirements for On-Demand mode.

  • Windows 11, version 25H2 (build 26200.x) on any endpoints you want to move to Vanguard On-Demand; older Windows 11 or Windows 10 endpoints can still be audited and have Vanguard removed, just not switched to On-Demand
  • PowerShell 5.1 (built into Windows) for local scripts, or PowerShell 7.4 or later if you want cross-platform remoting features and better error handling
  • Local administrator rights on target endpoints, or a service account with equivalent rights delegated through your management tooling
  • Microsoft Intune with Win32 app management enabled, if you manage devices through Microsoft Endpoint Manager
  • Microsoft Configuration Manager (SCCM), current branch, if you manage devices on-premises or in a hybrid setup
  • WinRM enabled on target machines for PowerShell remoting (enabled by default on domain-joined Windows 11 endpoints via Group Policy in most environments, but verify before you rely on it)
  • A pilot device group of 5-10 machines that mirrors your production hardware and Windows build mix, used before any fleet-wide change

Also decide up front who owns this decision. Vanguard is privileged, kernel-level software; changing its state across a fleet is a change-management action, not a routine software push. Loop in whoever owns endpoint security policy before you run anything past the pilot group.

Step 1: Audit Every Endpoint for Vanguard’s Footprint

You can’t make a fleet-wide policy decision without knowing where Vanguard already is. Start with an audit script that checks for the vgk and vgc services, the install directory, and the registry keys, then run it across your device inventory. The script below checks a single machine and can be looped against a list of computer names using PowerShell remoting, which we’ll cover in Step 7.

function Get-VanguardStatus {
    [CmdletBinding()]
    param()

    $services = Get-Service -Name vgk, vgc -ErrorAction SilentlyContinue
    $installPath = "$env:ProgramFiles\Riot Vanguard"
    $regKeyKernel = "HKLM:\SYSTEM\CurrentControlSet\Services\vgk"
    $regKeyClient = "HKLM:\SYSTEM\CurrentControlSet\Services\vgc"

    [PSCustomObject]@{
        ComputerName    = $env:COMPUTERNAME
        VgkServiceFound = [bool]($services | Where-Object Name -eq 'vgk')
        VgcServiceFound = [bool]($services | Where-Object Name -eq 'vgc')
        VgkStatus       = ($services | Where-Object Name -eq 'vgk').Status
        InstallFolder   = Test-Path $installPath
        RegistryKeys    = (Test-Path $regKeyKernel) -and (Test-Path $regKeyClient)
        CheckedAt       = Get-Date -Format 'yyyy-MM-dd HH:mm:ss'
    }
}

Get-VanguardStatus | Format-Table -AutoSize

On a machine with Vanguard installed, you should see output similar to this:

ComputerName  VgkServiceFound VgcServiceFound VgkStatus InstallFolder RegistryKeys CheckedAt
------------  --------------- --------------- --------- ------------- ------------ ---------
LAB-PC-014    True            True            Running   True          True         2026-09-09 08:12:41

Run this against your full device inventory and export the results to CSV. That CSV becomes your baseline: it tells you how many endpoints actually have Vanguard, how many have it running versus stopped, and which machines are clean and don’t need any action at all.

Step 2: Classify Devices and Decide Your Vanguard Policy

With the audit data in hand, sort your fleet into three buckets: devices that should keep Vanguard running normally (gaming lab machines actively used to play Valorant or League of Legends), devices that qualify for On-Demand mode and should be switched over to cut boot-time overhead, and devices that should have Vanguard removed entirely because Riot games aren’t part of their workload anymore.

This classification step is where most fleet rollouts go wrong. Teams either remove Vanguard everywhere (breaking Valorant access for machines that still need it) or leave it everywhere (missing the boot-time and attack-surface benefits of On-Demand mode on machines that qualify). Use your audit CSV plus your asset inventory to tag each device, then treat that tag as the input to every later step: the removal script, the Intune deployment, and the SCCM collection membership should all read from this same classification.

Step 3: Verify the Windows 11 25H2 Security Baseline

Vanguard On-Demand only works on machines that meet Riot’s published requirements: Windows 11, version 25H2 or later, UEFI Secure Boot enabled, TPM 2.0 present and active, Virtualization-Based Security (VBS) and Hypervisor-Protected Code Integrity (HVCI) enabled, and IOMMU support enabled. Before you flip any device to On-Demand, verify all five conditions programmatically rather than trusting hardware specs on paper.

function Test-VanguardOnDemandBaseline {
    $osBuild = [int](Get-CimInstance Win32_OperatingSystem).BuildNumber
    $deviceGuard = Get-CimInstance -Namespace root\Microsoft\Windows\DeviceGuard -ClassName Win32_DeviceGuard
    $tpm = Get-Tpm
    $secureBoot = Confirm-SecureBootUEFI -ErrorAction SilentlyContinue

    [PSCustomObject]@{
        ComputerName      = $env:COMPUTERNAME
        Build25H2OrNewer  = $osBuild -ge 26200
        SecureBootEnabled = [bool]$secureBoot
        Tpm2Present       = $tpm.TpmPresent -and ($tpm.SpecVersion -like '2.0*')
        VbsRunning        = $deviceGuard.VirtualizationBasedSecurityStatus -eq 2
        HvciEnabled       = 2 -in $deviceGuard.SecurityServicesRunning
        MeetsBaseline     = $null
    }
}

$result = Test-VanguardOnDemandBaseline
$result.MeetsBaseline = $result.Build25H2OrNewer -and $result.SecureBootEnabled -and $result.Tpm2Present -and $result.VbsRunning -and $result.HvciEnabled
$result | Format-List

IOMMU support is a firmware-level feature that PowerShell can’t always confirm reliably across every OEM, so cross-check it against your hardware vendor’s specification sheet or your existing asset management data for that model. If MeetsBaseline comes back False, don’t attempt to force On-Demand mode. Leave that device on the standard always-load configuration and re-evaluate after the missing setting (usually VBS or HVCI) is enabled through Group Policy.

Step 4: Enable Vanguard On-Demand for Qualifying Devices

For devices that pass the baseline check, Riot exposes the On-Demand toggle through the game client’s own settings and through Vanguard’s Pre-Check flow, not through a standalone Group Policy object or registry value you flip remotely. For a managed fleet, the practical approach is to bake baseline compliance into your device configuration (VBS, HVCI, Secure Boot, and TPM enforced through Intune or Group Policy), then let each device’s Vanguard Pre-Check confirm eligibility and apply on-demand loading the next time a user launches a Riot game on that machine.

Treat this as a two-part rollout: your management tooling enforces the security baseline fleet-wide, and Vanguard itself handles the actual on-demand switch per device once it detects the baseline is met. Track completion by re-running the Step 3 audit script on a schedule and reporting on MeetsBaseline as a compliance metric, the same way you’d track BitLocker or Defender status.

Step 5: Package Vanguard for Intune Deployment

For devices in the “remove entirely” bucket, package the removal as a Win32 app in Intune so it’s tracked, reportable, and reversible through normal app deployment controls rather than an ad hoc script. Intune’s Win32 app model needs an install command, an uninstall command, and a detection rule; for a removal task, the “install” command is the one doing the actual removal work.

# Install command (runs the removal)
powershell.exe -NoProfile -ExecutionPolicy Bypass -File Remove-Vanguard.ps1

# Detection rule script (returns nothing if Vanguard is gone, "NotFound" if present)
if (Get-Service -Name vgk, vgc -ErrorAction SilentlyContinue) {
    Write-Output "VanguardStillPresent"
    exit 1
}
exit 0

Set the detection rule to use a custom PowerShell script and check for a non-zero exit code, since that’s what confirms Vanguard is actually gone rather than just assuming the uninstall command succeeded. Assign the app to the Azure AD device group that maps to your “remove” classification from Step 2, and stage the rollout to a pilot group before assigning it to “All Devices” in that group.

Step 6: Push Removal Through SCCM / Configuration Manager

If your environment uses Configuration Manager instead of, or alongside, Intune, use the Scripts feature to run the same removal logic against a device collection without packaging a full application. This is faster for a one-time cleanup but gives you less ongoing compliance tracking than a proper Application deployment, so use it for the initial sweep and consider an Application deployment for anything you expect to re-check regularly.

Import-Module "$($ENV:SMS_ADMIN_UI_PATH)\..\ConfigurationManager.psd1"
Set-Location "YOUR:"  # replace YOUR with your site code

$collection = "Vanguard Removal Candidates"
$scriptGuid = (Get-CMScript -ScriptName "Remove-Vanguard").ScriptGuid

Invoke-CMScript -CollectionName $collection -ScriptGuid $scriptGuid

Build the “Vanguard Removal Candidates” collection using a query against the same audit data from Step 1, a WQL or PowerShell-based collection rule that includes only devices where your inventory extension reports the vgk service present. That keeps the collection membership in sync with reality instead of a manually maintained device list that drifts out of date.

Step 7: Remove Vanguard at Scale With PowerShell Remoting

For environments without Intune or SCCM, or for a quick pilot run before you build the full app packaging, PowerShell remoting against a list of computer names does the same job directly. This is also the fastest way to validate your removal logic before wrapping it in Intune or SCCM tooling.

$computers = Get-Content -Path .\pilot-computers.txt
$cred = Get-Credential

$removalScript = {
    $installPath = "$env:ProgramFiles\Riot Vanguard"

    Stop-Service -Name vgc -Force -ErrorAction SilentlyContinue
    Stop-Service -Name vgk -Force -ErrorAction SilentlyContinue

    sc.exe delete vgc | Out-Null
    sc.exe delete vgk | Out-Null

    if (Test-Path $installPath) {
        Remove-Item -Path $installPath -Recurse -Force -ErrorAction SilentlyContinue
    }

    [PSCustomObject]@{
        ComputerName = $env:COMPUTERNAME
        Removed      = -not (Get-Service -Name vgk, vgc -ErrorAction SilentlyContinue)
    }
}

Invoke-Command -ComputerName $computers -Credential $cred -ScriptBlock $removalScript -ThrottleLimit 20 |
    Export-Csv -Path .\vanguard-removal-results.csv -NoTypeInformation

Keep -ThrottleLimit conservative on your first run (10-20 concurrent connections) so a bad script doesn’t take down a large chunk of the fleet at once before you’ve confirmed it behaves correctly. Always test against the pilot group from your prerequisites list first.

Step 8: Resolve Kernel Driver Conflicts With Other Software

Vanguard’s early boot-time load order and kernel-level presence put it in the same privileged space as several tools IT and security teams rely on daily: Hyper-V, WSL2 (which depends on the Windows Hypervisor Platform), Wireshark and other packet-capture drivers, sandboxing tools, and any other kernel-level anti-cheat if a machine runs multiple game platforms. Conflicts here usually show up as boot delays, blue screens tied to a driver load order, or one tool refusing to start while the other is active, rather than a clear error message pointing at Vanguard by name.

Two mitigations reduce this friction without giving up either tool. First, moving qualifying devices to Vanguard On-Demand (Step 4) means the driver isn’t resident at all outside of active game sessions, which removes the boot-time conflict window entirely for machines that don’t need Valorant running constantly. Second, for machines that must keep Vanguard always-on and also run virtualization workloads, isolate the two use cases on separate machines or separate boot configurations rather than troubleshooting a shared environment indefinitely. Vanguard’s design assumes it has strong, largely exclusive access to the kernel’s driver-loading path, and that assumption doesn’t leave much room for negotiation with other privileged drivers.

Step 9: Validate Removal Across the Fleet

Removal isn’t complete until you’ve re-run the audit script from Step 1 and confirmed zero footprint, not just a successful exit code from your removal job. This is the same principle behind our single-machine PowerShell audit for confirming Vanguard is gone, scaled up to a full device fleet. Compare the post-removal CSV against your pre-removal baseline: every device you targeted should now show False for VgkServiceFound, VgcServiceFound, InstallFolder, and RegistryKeys.

$before = Import-Csv .\vanguard-audit-before.csv
$after  = Import-Csv .\vanguard-audit-after.csv

Compare-Object -ReferenceObject $before -DifferenceObject $after -Property ComputerName, VgkServiceFound |
    Where-Object { $_.SideIndicator -eq '=>' }

Any device that still shows a Vanguard footprint after a removal job needs manual follow-up. Common causes are a locked file handle (usually because a Riot game process was running during removal), insufficient permissions on the remote session, or a scheduled task re-installing Vanguard because a user manually reinstalled a Riot game after the removal ran.

Step 10: Build a Rollback Plan

Before you run removal at fleet scale, decide how you’ll reverse it if a business need changes, a lab that gets repurposed for a Valorant tournament next semester, for example. Rollback here is simple: reinstalling Vanguard is handled automatically the next time a user installs and launches a Riot game requiring it, since Vanguard’s installer is bundled with the Riot client install flow. The rollback plan you actually need to document is procedural, not technical: who approves re-enabling Vanguard on a given device group, and how quickly your Intune or SCCM deployment can be un-assigned from a collection if removal was pushed to the wrong group by mistake.

Keep your pre-removal audit CSVs archived for at least one budget or academic cycle. They’re the fastest way to answer “which machines had Vanguard before we started this project” if that question comes up in a later audit.

Step 11: Automate Ongoing Compliance Monitoring

Vanguard’s state on a given endpoint isn’t static, a user can reinstall a Riot game and bring the driver back on a machine you’d previously cleared. Schedule the audit script from Step 1 to run on a recurring basis (a weekly scheduled task or an Intune/SCCM compliance script) and alert when a device that should be Vanguard-free shows the driver present again.

$task = New-ScheduledTaskAction -Execute 'powershell.exe' `
    -Argument '-NoProfile -ExecutionPolicy Bypass -File "C:\Scripts\Get-VanguardStatus.ps1"'
$trigger = New-ScheduledTaskTrigger -Weekly -DaysOfWeek Monday -At 6am
Register-ScheduledTask -TaskName "VanguardComplianceCheck" -Action $task -Trigger $trigger -RunLevel Highest

Feed the output into whatever compliance dashboard your team already uses for other endpoint checks (BitLocker status, Defender health, patch compliance). Vanguard presence and On-Demand baseline compliance are just two more rows in the same report, not a separate system to maintain.

Step 12: Document the Policy for Compliance and Audit

Write down the classification rules from Step 2 as an actual policy document: which device groups keep Vanguard always-on, which qualify for On-Demand, which are removal targets, and who owns changing that classification. Kernel-level third-party software is exactly the kind of thing that shows up in a security audit or an insurance questionnaire, and “we have a documented process for it” is a much better answer than explaining it from memory during the audit itself.

Common Pitfalls When Managing Vanguard Across a Fleet

  • Assuming uninstalling Valorant removes Vanguard. It doesn’t. Valorant and Vanguard are separate installed programs, and removing one has no effect on the other’s services or files, the same lesson covered from the single-PC angle in our guide to removing the Vanguard driver after uninstalling Valorant.
  • Pushing removal fleet-wide without a pilot group. A removal script that works on your test VM can still fail silently on production hardware with different driver load orders or third-party security software present.
  • Forcing On-Demand mode on devices that don’t meet the baseline. Without Secure Boot, TPM 2.0, VBS, HVCI, and IOMMU all enabled, On-Demand eligibility checks will fail, and troubleshooting “why won’t On-Demand turn on” is far more time-consuming than verifying the baseline first with the Step 3 script.
  • Removing Vanguard while a Riot game process is still running. Locked file handles and active service dependencies cause partial removals that leave orphaned registry keys behind, which then show up as false positives in your next audit.
  • Treating this as a one-time project instead of an ongoing policy. Users reinstalling Riot games silently reintroduces Vanguard on “cleaned” machines; without Step 11’s monitoring, that drift goes unnoticed until the next manual audit.

Troubleshooting Guide

SymptomLikely CauseFix
Vanguard blocks the Riot client uninstall from finishingVanguard’s service is still active while the uninstaller tries to remove shared componentsFollow the fixes in our Valorant won’t uninstall troubleshooting guide before retrying removal at scale
Removal script reports success but audit still shows vgk presentRiot game process was running during removal, locking driver filesClose all Riot processes first, then re-run the removal script
PowerShell remoting fails with “Access is denied”Account used lacks local admin rights on the target endpointUse a credential with local admin rights or delegate the task through Intune/SCCM instead
sc.exe delete vgk returns “specified service is marked for deletion”A previous partial removal left the service in a pending-delete stateReboot the target machine to clear the pending state, then re-run removal
On-Demand eligibility check fails despite Windows 11 25H2VBS or HVCI not actually enabled, only the OS build is currentRun the Step 3 baseline script and enable the specific missing setting via Group Policy
Intune Win32 app shows “failed” despite manual removal workingDetection rule script exit code doesn’t match Intune’s expected logicConfirm the detection script exits 0 only when Vanguard is absent, matching Step 5’s example
SCCM script run reports success on devices not in the target collectionCollection membership rule is stale or too broadRebuild the collection query against current audit data, not a static device list
Machine blue-screens shortly after enabling HVCI for On-Demand eligibilityAn older, incompatible third-party kernel driver on that machine conflicts with HVCI enforcementIdentify the conflicting driver via the crash dump, update or remove it before re-enabling HVCI
Vanguard reappears on a machine days after confirmed removalUser reinstalled a Riot game, which reinstalls Vanguard automaticallyEnroll the device in Step 11’s scheduled compliance check to catch this within a week

The Complete Vanguard Fleet Manager Script

Combining the audit, baseline check, and removal logic from the steps above into a single script gives you one tool to run in Intune, SCCM, or directly via remoting, with a consistent parameter interface instead of juggling separate files. This is the working project version: save it as VanguardFleetManager.ps1 and call it with -Mode Audit, -Mode CheckBaseline, or -Mode Remove.

param(
    [ValidateSet('Audit', 'CheckBaseline', 'Remove')]
    [string]$Mode = 'Audit',
    [string]$ReportPath = ".\vanguard-report-$(Get-Date -Format 'yyyyMMdd-HHmmss').csv"
)

function Get-VanguardStatus {
    $services = Get-Service -Name vgk, vgc -ErrorAction SilentlyContinue
    [PSCustomObject]@{
        ComputerName    = $env:COMPUTERNAME
        VgkServiceFound = [bool]($services | Where-Object Name -eq 'vgk')
        VgcServiceFound = [bool]($services | Where-Object Name -eq 'vgc')
        InstallFolder   = Test-Path "$env:ProgramFiles\Riot Vanguard"
        CheckedAt       = Get-Date -Format 'yyyy-MM-dd HH:mm:ss'
    }
}

function Test-OnDemandBaseline {
    $osBuild = [int](Get-CimInstance Win32_OperatingSystem).BuildNumber
    $dg = Get-CimInstance -Namespace root\Microsoft\Windows\DeviceGuard -ClassName Win32_DeviceGuard
    $tpm = Get-Tpm
    [PSCustomObject]@{
        ComputerName     = $env:COMPUTERNAME
        Build25H2OrNewer = $osBuild -ge 26200
        Tpm2Present      = $tpm.TpmPresent -and ($tpm.SpecVersion -like '2.0*')
        VbsRunning       = $dg.VirtualizationBasedSecurityStatus -eq 2
        HvciEnabled      = 2 -in $dg.SecurityServicesRunning
    }
}

function Remove-Vanguard {
    Stop-Service -Name vgc, vgk -Force -ErrorAction SilentlyContinue
    sc.exe delete vgc | Out-Null
    sc.exe delete vgk | Out-Null
    $path = "$env:ProgramFiles\Riot Vanguard"
    if (Test-Path $path) { Remove-Item $path -Recurse -Force -ErrorAction SilentlyContinue }
    Get-VanguardStatus
}

$result = switch ($Mode) {
    'Audit'         { Get-VanguardStatus }
    'CheckBaseline' { Test-OnDemandBaseline }
    'Remove'        { Remove-Vanguard }
}

$result | Export-Csv -Path $ReportPath -NoTypeInformation
$result | Format-List
Write-Host "Report saved to $ReportPath"

Wrap this same script in the Intune detection/uninstall pattern from Step 5 or the SCCM script deployment from Step 6, and you have one source of truth for audit, baseline checking, and removal instead of three separate tools drifting out of sync with each other.

Riot Vanguard vs. BattlEye vs. Easy Anti-Cheat for Admins

If your fleet runs multiple game platforms, Vanguard isn’t the only kernel-level anti-cheat you’re managing. Understanding how it compares operationally to BattlEye and Easy Anti-Cheat helps you set consistent policy instead of a different ad hoc process for each one.

Anti-CheatLoad Timing (Default)On-Demand OptionSeparate From Game Install
Riot VanguardEarly boot (always-on default)Yes, added June 2026, requires Windows 11 25H2 security baselineYes, installed and removed independently
BattlEyeAt game launchEffectively yes, per-title by defaultTypically bundled per game, not a shared platform service
Easy Anti-CheatAt game launchEffectively yes, per-title by defaultTypically bundled per game, not a shared platform service

The practical difference for IT teams is that Vanguard’s always-on default and shared-across-titles design make it the one most worth actively managing with the audit-and-classify workflow in this guide. BattlEye and Easy Anti-Cheat’s default game-launch loading already behaves more like Vanguard’s new On-Demand mode, which is part of why Vanguard’s 2026 changes read as it catching up to where the other two already were.

Advanced Tips for Security and IT Teams

  • Track Microsoft’s vulnerable driver blocklist alongside Vanguard’s own changelog. Microsoft periodically expands the recommended driver block rules that ship with Windows, and any kernel driver on your fleet, including Vanguard, is affected by how that policy is configured on managed devices.
  • Watch for VBS/HVCI-adjacent CVEs, not just Vanguard-specific ones. In April 2026, Microsoft shipped a mitigation for CVE-2026-23670, an attack technique nicknamed “Download More RAM” that could undermine VBS and HVCI protections using writable memory-module configuration data, with kernel-level anti-cheats including Vanguard, BattlEye, and Easy Anti-Cheat named as potentially affected software. Patch level, not just anti-cheat version, matters for this class of risk.
  • Remember Vanguard’s own January 2026 disclosure. Riot fixed a kernel privilege-escalation vulnerability in Vanguard disclosed in early January 2026 that could let a malicious driver run with kernel-level privileges, though exploitation required both physical access to the device and valid administrator credentials. Riot reported no evidence it was used against real players, but it’s a reminder that a kernel-level anti-cheat is itself part of your attack surface, not just a defense against cheating.
  • Stagger rollouts by ring, not by convenience. Pilot group, then a broader early-adopter ring, then the full fleet, the same pattern you’d use for any other kernel-level or driver-level change, because Vanguard removal and On-Demand configuration both touch the same privileged layer as your EDR and virtualization stack.
  • Keep your removal script and your detection script in version control. Both change as Riot updates Vanguard’s service names or install paths; a script that worked in early 2026 is worth re-validating against a current Vanguard install before every large rollout.

Frequently Asked Questions

Does uninstalling Riot Vanguard break Valorant on that machine?
Yes. Vanguard is required for Valorant to launch. If you remove Vanguard from a device that still needs to run Valorant, the game will prompt for Vanguard reinstallation the next time it’s launched, which happens automatically through the Riot client.

What’s the difference between removing Vanguard and switching to On-Demand mode?
Removal deletes the driver, services, and install folder entirely, so no Riot game requiring Vanguard will work until it’s reinstalled. On-Demand mode keeps Vanguard installed but changes when the kernel driver loads, from every boot to only when a supported Riot game actually launches.

Can I manage Vanguard through Group Policy directly?
There’s no dedicated Vanguard Group Policy template from Riot. What you can manage through Group Policy or Intune configuration profiles are the underlying Windows security features On-Demand mode depends on: Secure Boot, TPM 2.0, VBS, and HVCI. Vanguard itself then detects and responds to that baseline.

Why does my removal script sometimes fail with “access denied” on the service deletion?
This is almost always a permissions issue with the account running the script, not a bug in the removal logic. Confirm the account has local administrator rights on the target machine, and that any PowerShell remoting session is running elevated.

Is Vanguard On-Demand available on Windows 10?
No. On-Demand mode requires Windows 11, version 25H2 or later, along with the full security baseline of Secure Boot, TPM 2.0, VBS, HVCI, and IOMMU. Windows 10 devices, or Windows 11 devices below 25H2, can run Vanguard but only in the always-on default configuration.

Will removing Vanguard fix a machine that won’t boot properly due to a driver conflict?
Sometimes, but treat it as a diagnostic step, not a guaranteed fix. If Vanguard’s early kernel load is genuinely the source of the conflict, removal (or switching to On-Demand, if the device qualifies) should resolve it. If the crash dump points to a different driver, removing Vanguard won’t help and you’ll need to address the actual conflicting component.

How often should I re-run the compliance audit?
Weekly is a reasonable default for most environments, matching the cadence many teams already use for other endpoint compliance checks. LAN centers or schools with high device turnover or frequent re-imaging may want daily checks instead.

Does Riot support enterprise deployment tooling like Intune or SCCM officially?
Riot doesn’t publish official Intune or SCCM packages for Vanguard. The deployment patterns in this guide use standard Win32 app and script deployment features in Intune and Configuration Manager to wrap Riot’s own installer and your own removal logic, which is the same approach IT teams use for most third-party software without a vendor-provided enterprise package.