Microsoft Intune Winget Integration: Everything IT Admins Need to Know

The integration between Microsoft Intune and the Windows Package Manager (Winget) represents one of the most significant shifts in how IT administrators manage application deployments across enterprise endpoints. For years, getting applications into Intune meant downloading installers from vendor websites, manually creating IntuneWin packages, writing detection rules by hand, and repeating the entire process every time a new version shipped. Winget changes the equation by providing a standardized, version-tracked repository of over 10,000 applications -- but understanding exactly how this integration works, where it falls short, and how to get the most out of it requires a deeper look at the architecture and tooling involved.

This guide covers the complete picture of the Intune Winget integration: how the Windows Package Manager works under the hood, the different ways Winget connects to Intune, what Microsoft's native support looks like in practice, and how tools like IntuneGet extend that integration to cover the full Winget repository with automated packaging and deployment. Whether you are evaluating Winget for the first time or looking to optimize an existing Intune app management workflow, this guide will give you the technical grounding to make informed decisions.

Understanding the Winget Package Manager

The Windows Package Manager, known as Winget, is Microsoft's official command-line tool for discovering, installing, upgrading, and removing applications on Windows 10 and Windows 11 devices. It shipped as part of the App Installer package from the Microsoft Store and has been included by default on Windows 11 since launch. Winget brings the same package management paradigm that Linux administrators have relied on for decades -- centralized repositories, dependency resolution, and scriptable installation -- to the Windows ecosystem.

The Winget repository

At the core of Winget is the winget-pkgs repository, a community-maintained collection of package manifests hosted on GitHub. Each manifest is a YAML file that describes an application: its publisher, version history, installer URLs, SHA256 hashes, silent install switches, and supported architectures. As of early 2026, the repository contains over 10,000 unique application packages spanning productivity tools, developer utilities, security software, and enterprise applications.

Every submission to the Winget repository goes through automated validation that checks installer integrity, manifest schema compliance, and hash verification. This validation layer is critical for IT administrators because it means the installer metadata in the repository has been verified before it reaches your deployment pipeline.

How Winget works on endpoints

On a local Windows device, Winget operates as a CLI tool that queries the repository index, resolves package metadata, downloads the appropriate installer, and executes it with the correct silent switches. A typical installation looks like this:

# Search for an application
winget search "Visual Studio Code"

# Install a specific version silently
winget install Microsoft.VisualStudioCode --version 1.96.0 --silent

# Upgrade all installed applications
winget upgrade --all --silent

Winget handles the complexity of determining installer type (MSI, EXE, MSIX, or Burn bundle), selecting the correct architecture (x64, x86, ARM64), and applying the appropriate silent install flags. This metadata is exactly what Intune needs to deploy applications -- the challenge is bridging the two systems effectively.

How Winget and Intune Connect

The Intune Winget integration is not a single feature -- it is a collection of connection points between the Winget ecosystem and the Intune management platform. Understanding these connection points helps you choose the right approach for your environment.

The Microsoft Graph API layer

All Intune operations, including app management, flow through the Microsoft Graph API. When you create a Win32 app in the Intune portal, the portal is making Graph API calls to endpoints under deviceAppManagement/mobileApps. These same API endpoints are available programmatically, which is how tools like IntuneGet automate the deployment process. The key Graph API permissions for app management are:

• DeviceManagementApps.ReadWrite.All: Required to create, update, and delete application packages in Intune. This is the primary permission needed for any automated deployment workflow.
• DeviceManagementApps.Read.All: Read-only access to view existing app deployments and their status. Useful for monitoring and reporting.
• DeviceManagementConfiguration.ReadWrite.All: Needed if you want to assign apps to configuration profiles or use app protection policies alongside your deployments.

Two integration paths

There are fundamentally two ways to bring Winget applications into Intune. The first is Microsoft's native Winget app type, where Intune sends a Winget command to the endpoint and the local Winget client handles installation. The second is the Win32 app approach, where the application installer is sourced from Winget but packaged as an .intunewin file and managed entirely through the Intune management extension on the device.

Each path has distinct implications for detection rules, update management, offline installation support, and endpoint prerequisites. The native Winget path is simpler to set up but gives you less control. The Win32 path requires more packaging effort upfront but provides the full Intune management feature set. IntuneGet automates the Win32 path, giving you the control benefits without the manual packaging overhead.

Native Intune Winget Support

Microsoft introduced the "Windows package manager app" type in the Intune admin center as a way to directly leverage Winget for app deployment. This native integration allows administrators to browse a curated catalog of Winget packages and add them to Intune without any manual packaging steps.

Adding apps from the built-in catalog

To add a Winget app natively in Intune, navigate to Apps > All apps > Add in the Intune admin center. Select "Windows package manager app (Winget)" as the app type. You can then search the integrated catalog by application name. Once you select an app, Intune pre-fills the app information including name, publisher, and description from the Winget manifest.

The deployment workflow assigns the app to user or device groups just like any other Intune app. When the policy reaches the endpoint, the Intune management extension invokes the local Winget client to install the application. Detection is handled automatically based on the Winget package metadata.

Limitations of the native approach

While the native Winget app type simplifies the initial setup, it introduces several constraints that IT administrators need to account for:

• Partial catalog coverage: The built-in catalog exposes only a curated subset of the full Winget repository. Many enterprise-relevant applications are not available through this interface, forcing you to use Win32 packaging for those apps anyway.
• Endpoint dependency on Winget client: Target devices must have the Winget client (App Installer) installed and up to date. If the App Installer package is outdated or missing, the deployment will fail. This creates an additional prerequisite in your device readiness chain.
• Limited detection rule customization: You cannot define custom detection rules for Winget app types. The detection logic is managed by Winget itself, which can be problematic for applications that install to non-standard directories or use atypical registry patterns.
• No offline installation: Because the Winget client downloads the installer at deployment time, endpoints need internet access to the Winget source URLs. This can be an issue for devices on restricted networks or during the initial provisioning phase.
• Coarser update control: Update management for native Winget apps is tied to the Winget client's behavior rather than Intune's supersedence and versioning features that Win32 apps support.

Using IntuneGet for Full Winget Integration

IntuneGet takes a different approach to the Intune Winget integration. Rather than relying on the native Winget app type with its endpoint dependencies and limited catalog, IntuneGet uses the Winget repository as the application source and packages everything as Win32 apps for Intune. This gives you access to the entire 10,000+ Winget catalog while retaining all of Intune's Win32 management features.

Complete Winget repository access

IntuneGet indexes the full Winget repository, not just the curated subset available in the Intune portal. Search any application by name, publisher, or Winget package ID. For applications that are difficult to locate by name, IntuneGet includes AI-powered app discovery that matches natural language queries to the correct package -- type "remote desktop tool" and it will surface the relevant Winget packages.

Automated IntuneWin packaging

When you select an application for deployment, IntuneGet automatically downloads the installer from the Winget source, wraps it in the .intunewin format using the Microsoft Win32 Content Prep Tool, and configures the install and uninstall commands with the correct silent switches from the Winget manifest. There is no need to run the Content Prep Tool locally or write PowerShell scripts.

Intelligent detection rules

One of the most error-prone parts of manual Intune app deployment is configuring detection rules. IntuneGet generates detection rules automatically based on the installer type. MSI packages get product code detection, EXE installers get file existence checks based on known install paths, and registry-based detection is used when the Winget manifest provides registry key information. This eliminates the guesswork that leads to false "installation failed" reports in Intune.

Automated update management

IntuneGet monitors the Winget repository for new application versions and gives you configurable update policies for each deployed app:

• Auto-update: Automatically re-package and update the Intune deployment when a new version appears in Winget.
• Notify only: Receive a notification when a new version is available so you can review and approve the update manually.
• Pin version: Lock the deployment to a specific version, ignoring new releases. Useful for applications that require compatibility testing before updates.
• Ignore: Stop tracking updates for a particular application entirely.

To get started with IntuneGet, see the Getting Started guide or sign in with your Microsoft Entra ID to start deploying immediately. IntuneGet is free, open source under the MIT license, and has no seat limits or premium tiers.

Best Practices for Winget to Intune Deployment

Regardless of which integration method you choose, following these best practices will reduce deployment failures and improve the reliability of your Intune Winget workflow.

Test in pilot groups before broad rollout

Never deploy a new application or application update directly to your entire device fleet. Create a pilot group containing a representative sample of hardware configurations and user profiles. Assign the app to this group first and monitor the installation status in the Intune portal for at least 24-48 hours before expanding the assignment. This catches issues with silent install failures, detection rule problems, and architecture mismatches before they affect production users.

Pin versions for critical applications

For applications that are business-critical or that have known compatibility requirements with other software in your environment, pin the deployment to a specific version rather than allowing automatic updates. This is especially important for applications like browsers, VPN clients, and collaboration tools where a broken update can disrupt user productivity. Test new versions in your pilot group before updating the production deployment.

Establish an update review cadence

Set a regular schedule -- weekly or biweekly -- to review pending application updates from the Winget repository. IntuneGet's notify-only update policy is ideal for this workflow: you receive alerts when new versions are available and can batch-approve updates during your review window. This balances the need for current software with the operational stability your users depend on.

Monitor deployment status actively

Intune provides detailed installation status reporting for each app deployment. Check for patterns in failure reports -- if a specific hardware model or Windows build consistently fails, it often points to an architecture mismatch or a missing prerequisite. For Win32 apps deployed through IntuneGet, the Intune management extension logs on the endpoint (located in C:\ProgramData\Microsoft\IntuneManagementExtension\Logs) contain detailed installation output that helps diagnose failures.

Document your app catalog

Maintain a record of which Winget packages map to which Intune deployments, including the version deployed, the update policy in effect, and any custom configuration applied. This documentation is invaluable during incident response, audits, and when onboarding new team members. IntuneGet tracks this mapping automatically in its dashboard, but maintaining an external record as a backup is a sound operational practice.

Winget Intune Integration Limitations to Know

While the Intune Winget integration covers a large portion of enterprise application needs, there are scenarios where it does not apply. Understanding these boundaries helps you plan a complete app management strategy.

Applications not in the Winget repository

Winget contains over 10,000 packages, but it does not cover every application. Proprietary enterprise software, niche vertical applications, and internally developed tools will not be found in the Winget catalog. For these applications, you will still need to use the traditional Win32 app packaging workflow in Intune -- download the installer from the vendor, package it with the Content Prep Tool, and configure detection rules manually.

Custom line-of-business applications

LOB applications developed in-house are outside the scope of any Winget integration. These apps typically use MSI or MSIX formats and are uploaded directly to Intune as LOB app types or packaged as Win32 apps. If your organization develops internal tools, plan for a separate packaging and deployment pipeline alongside your Winget-based workflow.

Network and firewall considerations

Both the native Winget app type and IntuneGet-based Win32 deployments require network access to download installers. For the native approach, endpoints need access to the Winget source URLs (primarily GitHub and CDN endpoints) at installation time. For the Win32 approach, the installer download happens server-side during packaging, but the .intunewin file is then distributed through Intune's content delivery network. Organizations with strict egress filtering should ensure the relevant URLs are allowed. The Intune CDN endpoints are documented in Microsoft's network requirements documentation.

Winget manifest quality varies

Because the Winget repository is community-maintained, manifest quality is not uniform across all packages. Some manifests have incomplete silent install switches, outdated installer URLs, or missing architecture specifications. When deploying lesser-known applications, verify the Winget manifest data and test the deployment in a pilot group before rolling out broadly. IntuneGet mitigates this by validating manifest data during the packaging process and alerting you to potential issues.

Frequently Asked Questions

Conclusion

The Intune Winget integration gives IT administrators a fundamentally better way to manage application deployments compared to the manual download-package-upload cycle of the past. Microsoft's native Winget app type in the Intune portal is a solid starting point for organizations that need a quick, low-effort way to deploy common applications. However, the limited catalog, endpoint dependencies, and restricted customization options mean it cannot serve as a complete app management strategy on its own.

For IT teams that need access to the full Winget repository with the reliability and control of Win32 app packaging, IntuneGet provides the automation layer that connects these two worlds. Automatic IntuneWin packaging, intelligent detection rule generation, and configurable update policies eliminate the manual effort while preserving the management features that enterprise Intune deployments require.

The key is choosing the right approach -- or combination of approaches -- for your environment. Use the native Winget app type for simple, widely available applications where minimal customization is needed. Use IntuneGet for the broader catalog, for applications requiring custom detection rules, and for any deployment where automated update management is a priority. For a hands-on walkthrough of deploying your first app, see our complete Winget to Intune deployment guide. To understand the time savings of automation over manual processes, read Winget vs manual Intune deployment.