Sideloaded MSIX and AppX: the app-security blind spot on Windows

Line-of-business sideloading and unrestricted AppX installs quietly widen your attack surface. Here is what to audit and how WinSentinel flags it.

Most Windows hardening advice obsesses over EXEs and MSIs — SmartScreen, AppLocker publisher rules, code-signing. But there is a whole parallel install path that a lot of endpoint audits never look at: MSIX and AppX packages. These are the modern packaging format behind the Microsoft Store, and — crucially — behind sideloading, where a package is installed straight from a file or an internal server without going through the Store at all.

Sideloading is legitimate and common. Line-of-business apps ship as signed .msix/.appx bundles; IT deploys them with Add-AppxPackage or Intune. The problem is that the machinery which allows sideloading is also a quiet way for an attacker or a careless user to install packaged software that never touches the Store's review pipeline. If you are not auditing it, you have a blind spot.

Why sideloaded packages slip past your controls

AppLocker's default rules don't cover it well. AppLocker has a separate Packaged app rule collection, and if you only wrote EXE/MSI/script rules, packaged apps run unrestricted. Many hardened images still leave the Packaged-app collection empty.
Self-signed and internal-CA packages. A sideloaded package only needs a certificate your machine trusts — not a Microsoft-issued one. Drop a cert into the Trusted People / Trusted Root store and any package signed by it installs cleanly.
The Store auto-update setting is orthogonal. Turning off Store auto-updates (common in locked-down fleets) means sideloaded LOB apps silently go stale, accumulating known-vulnerable dependencies with no patch path.
Provisioned vs. installed. A package can be provisioned for all future users of the machine, so it reappears on every new profile even after you uninstall it for the current user.

What to actually audit

Four settings and one inventory give you 90% of the visibility:

Sideloading / developer-mode policy. Check AllowAllTrustedApps and AllowDevelopmentWithoutDevLicense under HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\AppModelUnlock. Developer mode enabled on a production endpoint is a red flag.
AppLocker packaged-app rules. Confirm the Appx rule collection exists and is in Enforce mode, not Audit only and not absent.
Store auto-update. AutoDownload under HKLM\SOFTWARE\Policies\Microsoft\WindowsStore. If updates are disabled, you need a compensating patch process for LOB packages.
Installed / provisioned inventory. Enumerate with Get-AppxPackage -AllUsers and Get-AppxProvisionedPackage -Online, then flag any publisher outside Microsoft and the Store.
Signer trust. Cross-reference the signing cert of each non-Store package against the machine's trusted stores — a package trusted only because someone added its cert deserves a second look.

A quick manual pass looks like this:

# Non-Microsoft packaged apps installed for any user
Get-AppxPackage -AllUsers |
  Where-Object { $_.Publisher -notmatch 'CN=Microsoft' } |
  Select-Object Name, Publisher, Version, PackageFullName

# Is sideloading / dev mode unlocked?
Get-ItemProperty 'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\AppModelUnlock' `
  -Name AllowAllTrustedApps, AllowDevelopmentWithoutDevLicense -ErrorAction SilentlyContinue

How WinSentinel handles it

WinSentinel's Application Security module rolls all of this into scored findings — no PowerShell spelunking required. It enumerates installed and provisioned packages, isolates the non-Store publishers, reads the sideloading and dev-mode unlock keys, and checks the Store auto-update policy. Each finding comes with severity, an explanation of the risk, and (where safe to automate) a one-click fix — for example re-locking developer mode or moving the AppLocker packaged-app collection into enforce mode.

All of this runs locally on a single machine and is part of the free, open-source tier — install with dotnet tool install --global WinSentinel.Cli and run winsentinel --audit. If you manage more than a handful of endpoints, WinSentinel Pro rolls these package inventories up across your whole fleet so you can answer "which machines have developer mode unlocked?" in one query instead of one login at a time.

The Store made packaged apps feel safe. Sideloading is where that assumption quietly breaks — so audit the install path, not just the app.