August 27, 2026 - KB5120998 for Windows 11 - WinGet can no longer be run in an elevated terminal (Administrator Protection enforcement)

[R-Adrian]

Relevant area(s)

WinGet CLI

Relevant command(s)

winget upgrade

Brief description of your issue

after installing August 27, 2026—KB5120998 (OS Builds 26200.9278 and 26100.9278) Preview update, WinGet is no longer usable from an elevated command prompt.

Now it only works from a non-elevated terminal and requires secure-desktop approval with PIN or Password.

Steps to reproduce

• install KB5120998 Preview update for Windows 11 Pro from Microsoft Update

• find that it now only works in non-elevated terminal windows and any upgrade action requires elevation with Windows Hello mandatory PIN/Password - a simple click on the yes button is no longer possible.

Expected behavior

expected: no hidden / surprise major changes

Actual behavior

actual behaviour: KB5120998 introduces an.... interesting security context privilege separation.

Now administrator accounts seem to use a completely different user profile when elevated than when non-elevated.

Environment

elevated environment:

PS C:\WINDOWS\system32> winget --info
winget : The term 'winget' is not recognized as the name of a cmdlet, function, script file, or operable program. Check the spelling of the name, or if a path was included, verify that
 the path is correct and try again.
At line:1 char:1
+ winget --info
+ ~~~~~~
    + CategoryInfo          : ObjectNotFound: (winget:String) [], CommandNotFoundException
    + FullyQualifiedErrorId : CommandNotFoundException

PS C:\WINDOWS\system32>




non-elevated environment:
C:\>winget --info
Windows Package Manager v1.29.290
© 2026 Microsoft. All rights reserved.

Windows: Windows.Desktop v10.0.26200.9278
System Architecture: X64
Package: Microsoft.DesktopAppInstaller v1.29.290.0

WinGet Directories
-------------------------------------------------------------------------------------------------------------------------------
Logs                               %LOCALAPPDATA%\Packages\Microsoft.DesktopAppInstaller_8wekyb3d8bbwe\LocalState\DiagOutputDir
User Settings                      %LOCALAPPDATA%\Packages\Microsoft.DesktopAppInstaller_8wekyb3d8bbwe\LocalState\settings.json
Portable Links Directory (User)    %LOCALAPPDATA%\Microsoft\WinGet\Links
Portable Links Directory (Machine) C:\Program Files\WinGet\Links
Portable Package Root (User)       %LOCALAPPDATA%\Microsoft\WinGet\Packages
Portable Package Root              C:\Program Files\WinGet\Packages
Portable Package Root (x86)        C:\Program Files (x86)\WinGet\Packages
Installer Downloads                %USERPROFILE%\Downloads
Configuration Modules              %LOCALAPPDATA%\Microsoft\WinGet\Configuration\Modules

Links
---------------------------------------------------------------------------
Privacy Statement   https://aka.ms/winget-privacy
License Agreement   https://aka.ms/winget-license
Third Party Notices https://aka.ms/winget-3rdPartyNotice
Homepage            https://aka.ms/winget
Windows Store Terms https://www.microsoft.com/en-us/storedocs/terms-of-sale

Admin Setting                             State
--------------------------------------------------
LocalManifestFiles                        Disabled
BypassCertificatePinningForMicrosoftStore Disabled
InstallerHashOverride                     Disabled
LocalArchiveMalwareScanOverride           Disabled
ProxyCommandLineOptions                   Disabled
ConfigurationProcessorPath                Disabled
DefaultProxy                              Disabled

C:\>

[R-Adrian]

update: seems that until KB5120998 was released, Administrator Protection policies under secpol.msc (or gpedit.msc) were only for decorative purposes... and i have tried changing them in the past to see what they do but forgot about it since they didn't seem to do much...

However, starting with KB5120998 Microsoft is now using Administrator Protection functions seriously and this will now cause such split-behaviour in account profiles.
This split profile personality is intended by design and WinGet should be changed to account for this.

https://learn.microsoft.com/en-us/windows/security/application-security/application-control/administrator-protection/

https://blogs.windows.com/windowsdeveloper/2025/05/19/enhance-your-application-security-with-administrator-protection/

quote from learn.microsoft.com:
System requirements
Administrator protection is now available with [KB5120998] (https://support.microsoft.com/servicing/os/windows-11/2026/08/kb5120998-windows-11-24h2-25h2-update). The feature is off by default. Enterprise customers can enable the feature using custom OMA-URI.

Supported editions: Windows 11 Home, Pro, Enterprise, Education.

Administrator protection currently applies to supported Windows 11 devices outside Windows 365 Cloud PCs and Azure Virtual Desktop session hosts. Support for these environments, as well as Windows Server editions, is planned for a future release.

For Windows 365 and Azure Virtual Desktop session hosts, configure users as standard users to follow least-privilege best practices.

How Administrator protection works
At its core, Administrator protection operates on the principle of least privilege. When a user signs in to Windows, they receive a deprivileged user token. However, when admin privileges are needed, Windows requests that the user authorize the operation. Once authorized, Windows uses a hidden, system-generated, profile-separated user account to create an isolated admin token. This token is issued to the requesting process and is destroyed once the process ends, ensuring that admin privileges don't persist. The architectural changes ensure that no one can access or tamper with the code or data of elevated sessions without proper authorization.

/quote

[R-Adrian]

quick and dirty fix for Powershell until proper Administrator Protection is implemented in WinGet

1. start an elevated powershell terminal
2. check if the winget upgrade command works
3. if not, then re-register the winget app with this one-liner:

Get-AppxPackage -AllUsers *DesktopAppInstaller* | Foreach-Object { Add-AppxPackage -DisableDevelopmentMode -Register "$($_.InstallLocation)\AppXManifest.xml" }

note: it's "dirty" because it doesn't track DesktopAppInstaller upgrades properly, sometimes you will have to re-register it when WinGet / DesktopAppInstaller gets an update ¯\_(ツ)_/¯