Winget in Intune works, and for a lot of environments it is genuinely fine. I want to say that plainly up front, because the rest of this article is going to be honest about where it sits, and honesty can read as dismissal if you are not careful. So: Winget is a real, capable way to deliver applications through Intune, it is free, it is already on every modern Windows device, and if it is what you have, you can build a defensible app estate on it. What it is not is the best tool available. Winget is the poor man’s app delivery in Intune. That is not an insult. It is a description of the trade you are making, and the point of this article is to make that trade explicit and then show you what the money buys if you decide to spend it.
What Winget actually is
Winget is the Windows Package Manager, Microsoft’s command-line tool for discovering, installing, updating, and removing applications. It ships inside the App Installer package and stays current through the Microsoft Store. On Windows 11 it is present by default; on Windows 10 it depends on the App Installer being installed. One operational reality to know early: Winget registers on first user login, which means it is not available during OOBE or before the first user session. If you are reaching for it in an Autopilot pre-provisioning context, that timing will bite you.
The Winget paths inside Intune
There are three, and they are worth knowing because two of them are solid and one is a workaround. The cleanest is the native Microsoft Store app (new) type. In the Intune admin center you add a new app, choose Microsoft Store app (new), and the search queries the Winget repository directly. You pick the app, set the assignment, and Intune handles installation, detection, and updates with no packaging and no .intunewin file. For apps that are in the Store with good metadata and silent-install support – 7-Zip, VLC, Notepad++, Chrome Enterprise, and hundreds of others – this is the right free path. Updates flow through the Store rather than on a schedule you control, which is fine for these apps and a limitation for others.
When an app is not available that way, you can wrap a Winget call in a Win32 package: a PowerShell script that calls Winget by package ID, packaged as a .intunewin. The install pattern:
$Winget = Get-ChildItem -Path "$env:ProgramFiles\WindowsApps\Microsoft.DesktopAppInstaller*_x64*\winget.exe"
& $Winget install --id "Publisher.AppName" --silent --accept-package-agreements --accept-source-agreements --scope machineThe --scope machine flag matters. Without it, Winget installs in user context, which under Intune’s SYSTEM context means the app installs for whoever happens to be the current user rather than the whole device. Detection for these packages should be registry-based, checking the Uninstall key for display name and version, because that is more reliable than guessing the install path Winget chose. This path fills gaps, but every one of these packages is now something you own and maintain.
The third path is Remediations (Microsoft dropped the old “Proactive” from the name). A detection script checks whether a newer version exists in the Winget repository, and a remediation script runs winget upgrade if it does. Scheduled daily for security-relevant apps or weekly for the rest, run as SYSTEM in 64-bit PowerShell, this keeps Winget-installed apps current. Remediations needs a qualifying license – Windows Enterprise or Education E3/E5, or Microsoft 365 E3/E5 – so confirm the current licensing list before you build a workflow on it.
The truth about Winget, said plainly
Everything above works. It also has a ceiling, and the ceiling is why I call it the poor man’s path. Winget’s package metadata is often community-maintained, which means it can lag a vendor’s current release, occasionally point at a bad installer, or lack the silent-install arguments an enterprise deployment needs. You do not get real version control – Winget installs whatever the repository currently offers, not the specific build you tested and approved. You get no packaging control for apps that need pre-configuration, license-key injection, or post-install steps. And when you paper over those gaps with Win32 wrappers and Remediation scripts, you have quietly rebuilt a manual packaging pipeline, one script at a time, and made it your job to keep it running. Winget is free because you are supplying the labor and absorbing the risk. That is the trade. For a small estate or a cost-constrained tenant it is a perfectly rational one. At scale it stops being free in any real sense.
What the money buys: Enterprise App Management
Microsoft’s own answer to the Winget ceiling is Enterprise App Management, the Enterprise App Catalog. These are prepackaged Win32 applications – real exe and msi installers that Microsoft prepares and hosts – arriving with install and uninstall commands, detection rules, and requirements already filled in. Auto-update is a per-assignment toggle: enable it on a required app and Intune deploys new catalog versions automatically, no supersedence chains to maintain. Worth being precise about one thing, because it matters in a Winget article: EAM does not use Winget. The Intune Management Extension installs these directly. It is a separate, better-controlled mechanism, and for standard commercial apps it is genuinely cleaner than the Winget Store path.
The catch is access and coverage. EAM used to be a paid add-on only, sold with the Intune Suite or standalone, but as of the mid-2026 service release it is now included in Microsoft 365 E5 as well, which means a lot of tenants that never deliberately bought it now have it. The catalog has also grown well past its launch size and now runs to over a thousand applications, which covers the common commercial titles thoroughly, though it is still not exhaustive. Not everyone has EAM, and even where they do, it will not cover everything.
What the money buys: Patch My PC
The other answer, and the one a lot of serious Intune shops actually run, is Patch My PC. It is a third-party catalog and publishing engine that synchronizes prepackaged apps and updates straight into Intune, assigns them to your Entra groups, and supports update rings for staged rollout. Its draw over EAM is depth: the catalog is well north of a thousand titles against EAM’s few hundred, the team tests and ships new versions within about a day of a vendor’s release, and it adds the things a mature shop wants around apps – CVE reporting, update rings, and lifecycle handling that EAM does not fully match yet. It is paid software, and for some tenants that is the whole conversation. But if third-party app patching is a real operational burden for you, Patch My PC is usually the deeper tool, and it is worth pricing against the hours you are currently spending on Winget wrappers and Remediation scripts.
Where Winget actually fits
Here is how I place these in practice. If you have EAM or Patch My PC, let it own the lifecycle of every standard app it covers, because that is exactly the labor and risk you were absorbing by hand. Use the Winget Store type for the free, well-behaved apps that neither catalog bothers with or that you would rather not pay to cover. Keep the Win32-plus-Winget wrapper for the genuine gaps, the apps nothing else packages. And reach for a controlled Win32 package with a specific, tested installer whenever version control actually matters, regardless of what else is available.
Winget is not the villain here and it is not the hero. It is the floor – the capable, free baseline that every tenant has whether or not they ever pay for anything better. Knowing it is the floor is what lets you decide, deliberately, whether the floor is where you want to stand.
Intune Deployment Guide · Phase 7: Applications
‹ Previous: [7.1.2] Microsoft 365 Apps: Channels and Configuration
Next: [7.1.4] EAM Auto-Update: Trading Control for a Managed Patch Service ›
