Microsoft's WinGet package manager is being pushed as a modern way to keep Windows apps updated. But for IT administrators managing fleets of business PCs, the widely used winget upgrade --all command harbors a dangerous flaw: it cannot reliably separate applications that need administrator rights from those that don't. The result is a patchwork of broken installs, permission prompts, and unpredictable software behavior that compliance teams haven't signed up for.

This isn't a bug—it's a missing feature that has been openly tracked since November 2022 in GitHub issue #2706. And with WinGet adoption accelerating inside enterprises, the gap between enthusiast convenience and enterprise governance has never been wider.

What's Actually Broken in WinGet's Upgrade Command

The winget upgrade --all command is deceptively simple. It scans your system, finds every app with a newer version available, and tries to install them all at once. Microsoft documents optional --scope user and --scope machine filters to narrow the list by installation scope, but these don't address elevation requirements—the actual privilege level each installer needs to complete.

Elevation and scope are different things. A machine-scope app (installed for all users) almost always needs admin rights to update. But a user-scope app might still trigger a User Account Control prompt if it writes to a protected registry key or drops a file in a system folder. Conversely, some apps change their install mode when run elevated, accidentally shifting from a per-user setup to a machine-wide one—potentially breaking per-user customizations and shortcuts.

Microsoft's own documentation for WinGet Configuration v3 (released alongside WinGet 1.11) underscores this nuance. Resources that need elevation must explicitly declare securityContext: elevated, and the documentation warns that "adding unnecessary elevation can cause issues and is a security anti-pattern." The message is clear: elevation should be assigned deliberately to each resource, not sprayed across an entire workload. Yet winget upgrade --all offers no such granularity.

Without an elevation-aware filter—something like --elevation-required or the ability to batch non-elevated first and then prompt once for the rest—administrators are left to guess. The workaround of simply running the entire command in an elevated shell introduces further problems. If the elevated session runs under a separate administrator account (common in managed environments), it may skip per-user apps or install them under the wrong profile. Desktop shortcuts, registered file associations, and user‑specific data paths can silently break.

The GitHub request for this filter has languished for years, with no official commitment from Microsoft on when—or if—it will arrive. In the meantime, enterprises continue to stumble into the same trap.

What This Means for You—and It Depends on Who You Are

The impact of this gap varies dramatically by user type.

For Home Users and Enthusiasts

If you're managing one personal PC and you're comfortable clicking through UAC prompts, winget upgrade --all works well enough. You run it, supply admin credentials when asked, and move on. The occasional per-user app glitch is a minor nuisance. The command saves time over hunting for updates manually.

For IT Administrators and Desktop Engineers

This is where the pain lives. In a managed environment, every software update must be:
- Predictable: You know what will install and where.
- Traceable: You can audit the before/after state.
- Reversible: If an update breaks something, you can roll back without affecting other apps.
- Compliant: Licensing, security, and configuration policies are preserved.

winget upgrade --all fails on most of these fronts. Without testing each package individually, a single bad update can cascade across dozens of machines. Even worse, if the deployment runs under a system account or elevated provisioning context, it may misattribute installations, making inventory and compliance reporting inaccurate.

Consider this real-world scenario: A bank's desktop engineering team wants to use WinGet to keep 45 line-of-business apps current. They script winget upgrade --all to run weekly. After the first run, 12 apps fail silently because they require user-interaction during install. Another three upgrade but lose their per-user licenses. The helpdesk gets flooded with calls about missing shortcuts and broken add-ins. The team scrambles to undo the damage, and management bans further automated updates.

The lesson: WinGet's upgrade-all command is not a standalone patch management tool. It's a raw ingredient that demands a controlled recipe.

For Developers

Developers who maintain internal enterprise apps need to ensure their installers behave correctly under different privilege levels. The confusion around scope and elevation means a developer might inadvertently create an installer that works fine for a single user but breaks when deployed by an admin. Microsoft's evolving WinGet Configuration v3 schema—where each resource can declare its own security context—provides a path forward, but until the CLI catches up, developers must document and test elevation scenarios explicitly.

How We Got Here: A Timeline of Overlooked Complexity

WinGet debuted in May 2020 as a command-line answer to app stores and Linux package managers. It was immediately popular with power users. By mid-2022, Microsoft started positioning it for enterprise use, adding Group Policy controls, REST API sources, and the ability to integrate with Microsoft Intune.

  • November 2022: GitHub user [jn-org] opens issue #2706 requesting a batch-upgrade method that respects elevation boundaries. The request gains rapid community support.
  • May 2023: Microsoft releases WinGet 1.4, which introduces --scope flags but does not address elevation filtering. The documentation notes that scope and elevation are not the same, but offers no remedy.
  • 2024–2025: The issue remains active, with users sharing PowerShell workarounds that all suffer from the identity problem described above.
  • Late 2025: WinGet Configuration v3 arrives with the dscv3 processor, finally allowing granular elevation declarations in declarative configuration files. But the imperative winget upgrade --all command remains unchanged.
  • May 2026: The last visible discussion on issue #2706 confirms the feature is still missing.

The story is one of a tool that grew up in the wild west of personal computing and is now being dressed up for corporate boardrooms without the necessary tailoring. The goodwill and open-source responsiveness that made WinGet a hit in the community haven't yet translated into the kind of deterministic, security-compliant workflow enterprises demand.

How to Use WinGet Safely on Managed PCs Today

You don't need to abandon WinGet. You need to wrap it in a process that restores the control that --all takes away.

1. Start with an Inventory, Not a Blanket Command

Run winget upgrade without arguments to see what's available. This is your candidate list, not your to-do list.

2. Curate a Tested Catalog

For each app your organization officially supports, determine:
- The exact Package ID (winget show <app>)
- Its typical installer behavior (silent install, required arguments, interactive)
- Whether it's per-user or machine-scope in your environment
- Whether an update needs elevation (test this in a sandbox)
- Rollback steps
Only add an app to an automated deployment after its upgrade behavior has been validated under the same account type and privilege boundaries used in production.

3. Script Narrow Upgrades by Package ID

Instead of winget upgrade --all, loop through a curated list:

$approved = @('JanDeDobbeleer.OhMyPosh', 'Git.Git', '7zip.7zip')
foreach ($id in $approved) {
    winget upgrade --id $id --silent --accept-package-agreements
}

For apps that truly need elevation, separate those into a dedicated script that runs in an elevated context—but only after confirming the installer won't alter user‑scope data.

4. Match Elevation to the Installation Scope—But Don't Stop There

You can use --scope machine to group apps likely to need elevation, but always test each one. Document results. A machine-scope app that requests elevation during upgrade is normal; a user-scope app that does the same might be a sign of a poorly authored installer that could corrupt the user profile.

5. Verify After Every Run

Use a post-script that checks installed versions via winget list or the registry. Log failures and unexpected scope changes. These audits are critical for change control audits.

6. Consider WinGet Configuration for Higher Assurance

If you're already on WinGet 1.11 or later, the v3 configuration schema lets you declare exactly which packages to install, their sources, and whether they need elevation—all in a YAML file. This is a declarative, auditable approach superior to ad-hoc scripts. However, it's an install-time tool, not a recurring update mechanism, so you'll still need a scheduled task or management platform for ongoing patches.

For fleets over a few dozen machines, integrate WinGet with a tool like Microsoft Intune, Windows Autopatch, or a third-party solution that can handle targeting, maintenance windows, reporting, and rollback. WinGet becomes the execution engine, not the policy manager.

Outlook: Will Microsoft Close This Gap?

The existence of a well-defined GitHub issue, coupled with the elevation-aware design of WinGet Configuration v3, suggests Microsoft understands the problem. But prioritization is unclear. The company's recent push to make WinGet a first-class citizen in enterprise provisioning—evidenced by the v3 schema and deep integration with Windows 11—hints that a CLI-level fix might arrive within the next major release cycle.

When (or if) an elevation-aware filter lands, it should allow syntax like:

winget upgrade --all --require-elevation=auto

That would run non-elevated upgrades first, then prompt once for the rest, while preserving user identity for per-user apps. Until then, the safe path is clear: treat winget upgrade --all as a reconnaissance command, not a deployment strategy. Your fleet will thank you.