Windows Update Patch Management on EC2 Graviton Windows 11 ARM

Checo7/3/26About 2 min

Windows Update Patch Management on EC2 Graviton Windows 11 ARM

Windows 11 ARM on Graviton is installed through an unofficial path. Can Windows Update still work normally? Will updates replace the inbox StorNVMe driver and break the system? This article runs a complete scan/download/install verification.

Test Environment

Item	Configuration
Instance	t4g.large (Graviton2)
OS	Windows 11 Pro 25H2 ARM64, Build 26200.8655
NVMe driver	inbox stornvme.inf 10.0.26100.8521
ENA driver	AWS ENA ARM64 2.2.1.65

Quick Summary

Test Item	Result
Windows Update scan	Connects to Microsoft servers and completes scan
Cumulative update install	KB5094126 installed successfully
Defender signature update	Daily auto-update succeeds
Driver update	AudioProcessingObject driver updated
StorNVMe replaced?	Not replaced, version unchanged
Reboot required?	No (signature and driver updates do not require reboot)
Post-update anomalies?	None

Relationship Between ARM64 and x64 Patches

Cumulative updates for Windows 11 share the same KB number and the same Build number between ARM64 and x64, but the packages are separate.

For the June 2026 security update:

Property	x64	ARM64
KB number	KB5094126	KB5094126
Build	26200.8655	26200.8655
Catalog entry	...for x64-based Systems	...for arm64-based Systems

The Windows Update client automatically detects the system architecture and pulls the matching package, so there is no risk of installing the wrong architecture. For manual offline installation, when searching the Microsoft Update Catalog by KB number, choose the arm64-based Systems entry; the wrong architecture will be rejected by the system.

Defender signature updates (KB2267602) are also received normally on ARM64 — signatures are platform-agnostic data files.

Walkthrough

1. Baseline

# Check current Build
(Get-ItemProperty 'HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion').DisplayVersion
# Output: 25H2

# Installed patches
Get-HotFix | Sort-Object InstalledOn -Descending | Format-Table HotFixID, Description, InstalledOn

2. Scan for available updates

$session = New-Object -ComObject Microsoft.Update.Session
$searcher = $session.CreateUpdateSearcher()
$result = $searcher.Search('IsInstalled=0')
Write-Host "Found $($result.Updates.Count) updates."
foreach ($update in $result.Updates) {
    Write-Host "  $($update.Title) - $([math]::Round($update.MaxDownloadSize / 1MB, 1)) MB"
}

Scan completed in 14 seconds — the WU client can reach Microsoft update servers normally.

3. Download and install

foreach ($update in $result.Updates) {
    if (-not $update.EulaAccepted) { $update.AcceptEula() }
}

$downloader = $session.CreateUpdateDownloader()
$downloader.Updates = $result.Updates
$downloadResult = $downloader.Download()

$installer = $session.CreateUpdateInstaller()
$installer.Updates = $result.Updates
$installResult = $installer.Install()
# ResultCode: 2 (Succeeded)
# RebootRequired: False

4. Post-update driver check

Get-CimInstance Win32_PnPSignedDriver |
    Where-Object {$_.InfName -like '*nvme*'} |
    Select-Object DeviceName, DriverVersion, InfName

DeviceName                       DriverVersion    InfName
----------                       -------------    -------
Standard NVM Express Controller  10.0.26100.8521  stornvme.inf
Standard NVM Express Controller  10.0.26100.8521  stornvme.inf

The driver version is unchanged — Windows Update did not replace the inbox StorNVMe driver.

A Detail: PROCESSOR_ARCHITECTURE Reports AMD64

$env:PROCESSOR_ARCHITECTURE
# Output: AMD64
(Get-CimInstance Win32_ComputerSystem).SystemType
# Output: ARM64-based PC
(Get-CimInstance Win32_OperatingSystem).OSArchitecture
# Output: ARM 64-bit processor

PowerShell 5.1 runs under x64 emulation on Windows 11 ARM, so the process environment variable reports AMD64. But system-level WMI queries correctly reflect the ARM64 architecture. The Windows Update client does not rely on process-level environment variables to determine architecture, so it pulls ARM64 packages correctly even when PowerShell sees AMD64.

Notes

Cumulative updates may require a reboot: This test only installed signature and driver updates (no reboot required). Monthly cumulative updates usually require a reboot. On Graviton, rebooting means instance stop/start — verify the instance can start back normally.
StorNVMe will not be replaced by WU: The inbox StorNVMe tracks the OS version and is only replaced by a newer inbox driver during a major version upgrade (e.g., 25H2 → 26H1).
Manual offline installation: When downloading from the Update Catalog, choose the arm64-based Systems entry. The x64 .msu file will be rejected (The update is not applicable to your computer).
SSM Patch Manager compatibility: Windows 11 Pro (not Server) has limited SSM Patch Manager support. Manage updates via the COM API or UsoClient StartScan instead.