An Intune detection rule for a winget app

Deploying a Win32 app through Intune means authoring a detection rule: a registry key, a file path and version, or a script that exits zero when the app is present. For anything winget-managed, that rule is a guess that ages badly.

Why detection rules are brittle here

A detection rule has to encode where the application will be after installation. For per-user applications that location depends on which user installed it, so a machine-scope registry check finds nothing even when several people have the app. For applications whose product code changes between versions — and plenty do — a product-code rule stops matching the moment the vendor ships an upgrade. Version-comparison rules on file paths break when a vendor reorganises its install directory.

So the rule drifts out of true, and the failure is quiet: Intune believes the app is absent and redeploys it, or believes it is present and never remediates.

The deeper problem is that a detection rule asks a deployment tool to re-derive a fact the endpoint already knows.

How this works without detection rules

Our agent does not wait to be asked. It reconciles declared state against observed state on a fifteen-minute cycle and reports an inventory beacon every thirty minutes, and the observation is multi-source rather than a single registry guess: Add/Remove Programs across both registry views, winget’s own COM interface, Chocolatey, Scoop, and per-user profile enumeration corroborated from SYSTEM context.

Because the endpoint reports what is genuinely there, there is no per-application rule to author, and nothing to update when a vendor changes their product code. Drift is a state you can look at rather than an inference from a deployment record.

One detail matters for trust: the classification of what kind of package a row is gets re-derived server-side rather than accepted from the agent, so a compromised agent cannot relabel rows into a more privileged category.

If you specifically need this in Intune

Being straightforward, because this is a real gap rather than a positioning choice.

There is no Intune integration. We do not emit detection rules, detection scripts, .intunewin packages, or Configuration Manager equivalents. Searching our source for Intune returns nothing outside planning documents.

There is a tenant-scoped inventory read API — GET /api/v1/inventory/rows, filterable by manager, source, and package class, with pagination — and building an Intune-facing integration on top of it is possible. Two things you would hit:

• the API projects endpoint, manager, source, package id, version, name, class, compliance flag and last-seen time, but not whether a row is held — so a consumer cannot distinguish a live observation from a last-known row for a logged-out user
• it does not project the user SID, so per-user attribution is invisible to an external consumer even though the platform tracks it internally

Both are genuine limitations for exactly this use case. If you need that integration, it is worth telling us, because the missing fields are a small change and nobody has yet asked for them.

The honest positioning

We sit in front of Intune rather than replacing it. Intune remains a capable deployment and device-management system, and plenty of teams keep it for MDM while letting the winget catalog, the ring policy and the attestation trail live here.

What we would not claim is that we integrate with it today. We answer the question detection rules exist to answer — is this installed, where, and for whom — and we answer it continuously. We just do not currently hand that answer back to Intune for you.