Best Third-Party Patching Tools for Microsoft Intune (2026 Comparison)

This comparison is for Intune admins choosing how third-party applications get patched: Chrome, Zoom, Adobe Acrobat, 7-Zip and the long tail behind them. It covers four products that solve the problem in two different ways, and the five decisions that separate them in practice.

The scope is Windows devices managed by Microsoft Intune, with Win32 apps delivered by the Intune Management Extension (IME). It assumes you already run Windows Update policies for the OS and want the same discipline for everything else. It is a decision framework built from vendor documentation and operating experience, not a lab benchmark: none of the release-speed claims below are timed measurements.

Why third-party patching is the hard part

Windows quality updates are the easy half of patching. Microsoft ships them on a calendar, WUfB rings handle the rollout, and the reporting is built in. Third-party apps have none of that.

When you carry 150 or more third-party apps, the work is rarely the packaging itself. It is everything that drifts after you packaged it:

• Silent switches change between versions. A vendor moves from an MSI to an EXE bootstrapper, renames a switch, or starts ignoring /qn and showing a first-run dialog in session 0, where nobody can click it. The install hangs until the IME timeout kills it.
• Detection rules drift. Chrome's 64-bit install lives under C:\Program Files\Google\Chrome, not Program Files (x86). Acrobat's unified 64-bit installer does not register the same display name or product code as the 32-bit Reader MSI many estates still carry. Zoom's consumer installer writes to the user profile, not Program Files. A detection rule written for last year's package reports "not installed" on a healthy device, and Intune tries to install again.
• The CVE window is tighter than your packaging cycle. When a browser zero-day lands, the security team wants the fleet patched in days. A hand-built package, tested and assigned through three rings, does not move that fast unless the pipeline is already automated.

Every tool in this comparison automates that pipeline. The question is where it runs, who owns the package, and how much control you keep.

The short answer

Comparison at a glance

1. Catalog depth and release velocity

Catalog size is the number every vendor leads with, and it is the least useful number in the table. What matters is whether your top apps are in the catalog, how fast a new version reaches your tenant after a vendor release, and how much testing happened before it did.

Patch My PC runs a curated catalog: a smaller list than Robopack's, but each product has a maintained install command, detection logic and conflicting-process list. For the apps that cause most of the CVE pressure (Chrome, Edge, Firefox, Zoom, Acrobat, 7-Zip, Notepad++, Java runtimes), that curation is the product. You pay for someone else to notice that a vendor changed a switch.

Robopack draws from Winget and the Microsoft Store, which is why the number is over 30,000. Robopack's FAQ says a new version that appears in Winget is typically available through Robopack in about 30 minutes. That is fast, but it means velocity and quality both depend on the Winget manifest. For a mainstream browser the manifest is usually current and correct. For a niche line-of-business utility, check who maintains it before you auto-approve it.

Action1 and NinjaOne maintain their own third-party catalogs for their agents. NinjaOne documents Adobe, Java, Chrome and over 135 common business applications, then extends coverage with WinGet. Both are good at the high-volume apps and thinner in the long tail, which is where you fall back to custom packages.

What to measure in a trial, because no vendor page will tell you:

1. Pick five apps that matter to your security team. Chrome, Zoom, Acrobat and 7-Zip are a good start; add your own worst offender.
2. Record the vendor's release time for the next version of each.
3. Record when the update became available in the tool, when it reached the pilot ring, and when the first device reported it installed.
4. Repeat for at least one browser zero-day cycle before you decide.

That timeline is the release velocity that matters: vendor release to installed on a pilot device, not vendor release to catalog.

2. Architecture and agent footprint

This is the decision that splits the four tools into two pairs, and it matters more than any feature row.

Native Intune publishing: Patch My PC and Robopack

Both create ordinary Win32 apps in your tenant through Microsoft Graph. Robopack's FAQ lists the permissions its enterprise app requests, including DeviceManagementApps.ReadWrite.All and Group.ReadWrite.All. Patch My PC Cloud works the same way from its SaaS side, and the on-premises Publisher does it from a Windows server you run, alongside ConfigMgr and WSUS if you have them.

On the device, nothing new runs. The IME downloads the package, runs the install command (often a vendor wrapper or PSADT script inside the package), evaluates the detection rule, and reports back. The consequences:

• App status, install failures and detection results live in the Intune admin center like every other Win32 app.
• Your existing log workflow applies: AppWorkload.log and IntuneManagementExtension.log under C:\ProgramData\Microsoft\IntuneManagementExtension\Logs.
• Assignments, filters, supersedence, dependencies and the Enrollment Status Page all behave as Intune documents them.
• The trade-off: you inherit Intune's delivery speed and limits. A device that has not checked in does not patch, and the IME's evaluation cycle sets the pace.

Agent-based patching: Action1 and NinjaOne

Both install their own agent and patch outside Intune. The agent runs alongside the IME, talks to its own cloud, and applies updates on its own schedule. That has real advantages: a patch can go out within minutes of approval, vulnerability data and remediation sit in one console, and NinjaOne adds full RMM (remote control, scripting, monitoring, ticketing) across multiple tenants.

The cost is a second source of truth. Intune's discovered apps inventory still sees the new version, but Intune's app install status knows nothing about it. The failure pattern to design around:

• Intune has a required Win32 app for Chrome with a version-specific detection rule.
• Action1 or NinjaOne updates Chrome to the next version.
• Intune's detection now fails, so the IME tries to install the older package again. Chrome refuses the downgrade, Intune reports a failure, and the helpdesk sees a red device that is actually patched.

The rule that prevents this is simple: one owner per app. If an agent-based tool patches Chrome, Intune deploys Chrome once with a detection rule that checks for presence or a minimum version, never an exact version, and never supersedes it.

3. Ring deployment and pilot gates

Every tool here can deploy to a pilot group first. They differ in what moves an update from pilot to broad: a timer, a success threshold, or a person.

Two things that no tool gives you, whatever the marketing says:

• Automated rollback of an installed app. None of these tools undoes a third-party update on its own. Rollback means stopping the ring and, where the app allows it, redeploying the previous version. Robopack keeps three previous versions in Intune by default, which helps. Browsers generally refuse to downgrade over a newer profile, so for Chrome and Edge, "rollback" is really containment.
• A pilot that represents your estate. A pilot ring of five IT laptops proves the installer runs. It does not prove the update works with the finance add-in, the VDI image or the kiosk shell. Put a named device from each awkward population in the pilot, with a named owner.

A practical ring design for third-party apps, whichever tool you choose:

1. Ring 0, IT validation: 10 to 20 devices, no delay. Includes at least one device per hardware model and one VDI or shared device if you have them.
2. Ring 1, business pilot: 5 to 10 percent of the estate, named champions in each department, 2 to 3 days after Ring 0.
3. Ring 2, broad: everyone else, 3 to 7 days after Ring 1, with a shorter path for actively exploited CVEs.
4. Expedite path: a documented exception for zero-days that collapses Rings 1 and 2 into one step after Ring 0 reports, with the security team's sign-off recorded.

4. Packaging flexibility

Catalog apps cover most of the estate. The remaining 10 to 20 percent is where packaging flexibility decides whether the tool saves you time or just moves the hand-packaging somewhere else.

Patch My PC offers pre- and post-install scripts, MST transforms, custom install arguments, and conflicting-process handling per app. The Custom Apps feature in Patch My PC Cloud lets you package apps outside the catalog with the same machinery: 100 custom apps on Enterprise Plus, 500 on Enterprise Premium. If you already maintain MST transforms for Acrobat or Java settings, they carry over.

Robopack wraps packages with the PowerShell App Deployment Toolkit, supporting PSADT v3 by default and v4.1. Script templates let you standardise pre-install and post-install logic across every app: close processes, remove the per-user version, set a registry value, write a log. If your team already thinks in PSADT, Robopack fits how you work. One documented limitation to plan for: when Robopack updates an app in Intune, metadata such as Owner, Notes and Categories is not preserved.

Action1 supports custom packages in its software repository with your own install switches, and its agent runs scripts on the endpoint. NinjaOne handles custom installs through its scripting and automation library. Both can pass TRANSFORMS= on an msiexec command line, but neither gives you the Intune-native detection, dependency and supersedence model, because the install never goes through Intune.

Whatever tool builds the package, the install command for a transform-based MSI should look the same and log to a predictable place:

# Install command inside a Win32 app or custom package
msiexec.exe /i "AcroRead.msi" TRANSFORMS="AcroRead.mst" /qn /norestart /L*v "$env:ProgramData\Logs\AcroRead-install.log"

A verbose MSI log in a known folder is the difference between "it failed" and "it failed because the transform targets a different product code".

5. Cost and licensing transparency

Licensing models differ enough that list price comparisons mislead. What to compare is the cost for your device count, including the minimum commit.

Patch My PC and Robopack sit on top of Intune licensing you already pay for. Action1 and NinjaOne can replace parts of what you use Intune for, which only saves money if you actually retire those parts. For an Intune-first estate, the honest comparison is usually Patch My PC against Robopack, with Action1 or NinjaOne in play only when there is a non-Intune population to cover or an RMM requirement.

Failure modes when a third-party package fails silently

Most "the patch didn't install" tickets end up in one of a handful of patterns. Whichever tool publishes the package, the IME log tells you which one it is. On co-managed devices where Configuration Manager owns the apps workload, read AppEnforce.log in C:\Windows\CCM\Logs instead.

To pull the lines that matter without scrolling CMTrace for an hour:

$log = "$env:ProgramData\Microsoft\IntuneManagementExtension\Logs\AppWorkload.log"
Select-String -Path $log -Pattern 'exit code|0x87D1041C|1618|1602|detected|not detected' |
  Select-Object -Last 40 LineNumber, Line

On a co-managed device with the ConfigMgr apps workload:

Select-String -Path 'C:\Windows\CCM\Logs\AppEnforce.log' -Pattern 'exit code|Application not discovered|Discovered application' |
  Select-Object -Last 40 LineNumber, Line

Expected output shape: a run of lines for one app showing the command line, an exit code, and a detection result. If the exit code is 0 and the next detection line says not detected, the package is fine and the detection rule is wrong.

Validate detection rules before you trust any catalog

A catalog tool ships its own detection logic, and it is usually right. Your custom apps, transforms and pre-install scripts are where it goes wrong, and that is where a quick check pays for itself.

Start with what the device actually reports. This reads both registry views, so a 32-bit app on a 64-bit device does not hide:

$paths = @(
  'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\*',
  'HKLM:\SOFTWARE\WOW6432Node\Microsoft\Windows\CurrentVersion\Uninstall\*'
)
Get-ItemProperty -Path $paths -ErrorAction SilentlyContinue |
  Where-Object DisplayName -Match 'Chrome|Zoom|Acrobat|7-Zip' |
  Select-Object DisplayName, DisplayVersion, PSChildName, InstallLocation |
  Sort-Object DisplayName

Then build the detection rule against what you found, not against what last year's package installed. The free Intune Win32 detection script generator produces detection or requirement scripts for file versions, registry values with an explicit 32-bit or 64-bit view, MSI product codes and services. The scripts follow the Intune contract Microsoft documents: write to STDOUT and exit 0 when detected, exit non-zero otherwise, and never write to STDERR, because any STDERR output makes Intune treat the app as not installed.

Validation before you assign a custom app to Ring 0:

1. Run the detection script on a device without the app. It must exit 1 with no output.
2. Install the app with the exact install command from the package. The detection script must exit 0 and print one line.
3. Install the next version over it. Decide whether detection should still pass (minimum version) or fail (exact version), and confirm it does what you decided.
4. Run it as SYSTEM, in the same bitness the Win32 app uses, because that is how the IME runs it.

For detection failures in the field, work through the Win32 app stuck at Waiting or Pending guide.

When not to use each tool

• Do not use Patch My PC if you need success-gated ring progression inside Intune today, or if most of your fleet is not in Intune or ConfigMgr. It patches through the tools you already run; it does not replace them.
• Do not use Robopack if your security team requires a vendor-tested package for every app, unless you review the Winget source for each one first. Also plan around the metadata that updates do not preserve.
• Do not use Action1 to patch apps that Intune also deploys with exact-version detection. Pick one owner per app. Also do not assume the free tier includes support.
• Do not use NinjaOne purely for third-party patching on an Intune-managed fleet. You would be buying an RMM platform to do one job Intune-native tools already do; it earns its place when you need the RMM, or you manage many client tenants.

Pilot checklist

• List the top 50 third-party apps by install count and CVE history, and confirm each is in the candidate tool's catalog
• Decide the owner of each app: Intune-native publisher, agent-based tool, or neither
• Remove or relax exact-version detection on any Intune app an agent-based tool will patch
• Build Ring 0 with one device per hardware model, plus VDI and shared devices if you have them
• Configure conflicting-process behaviour for browsers, Zoom, Teams add-ins and Acrobat before the first update
• Time one full cycle per app: vendor release, available in the tool, installed on the first pilot device
• Collect AppWorkload.log (or AppEnforce.log) evidence for one success and one failure
• Validate every custom detection rule with the four steps above
• Document the expedite path for actively exploited CVEs and who approves it
• Confirm the licence count against your real device count, including the minimum commit

Rollback

Plan rollback as containment, because no tool here reverses an installed third-party update for you.

1. Pause the ring. Stop the update reaching the next ring: pause the Robopatch flow or Action1 ring, remove the broad assignment in Patch My PC, or set the NinjaOne patch to rejected.
2. Limit the blast radius first. The ring design does most of the work. A bad update that stopped at Ring 0 is an inconvenience; one that reached everyone is an incident.
3. Redeploy the previous version where the app allows it. Keep the previous package available in Intune (Robopack keeps three by default). Expect browsers and some auto-updating apps to refuse a downgrade.
4. Record the trigger. Note the version, the symptom and the log lines, so the same update does not walk back into Ring 0 next week.

Final recommendation

• Intune-first estate, with or without ConfigMgr: start with Patch My PC. Native Win32 publishing, no added agent, a curated catalog, and MST and script support that matches how enterprise packaging already works. Accept that ring progression is time-based and put a human pause step in your process.
• Cloud-only Intune estate that wants automation and gated waves: trial Robopack. The PSADT model and success-threshold waves are the strongest automation in this group. Review the Winget source for the apps you will auto-approve.
• SMB or mixed estate that needs vulnerability remediation now: Action1, starting on the 200-endpoint free tier. Keep Intune for configuration and compliance, and give Action1 clear ownership of the apps it patches.
• MSP managing many tenants, or a team that needs full RMM: NinjaOne, priced as an RMM platform rather than a patching tool.

Whichever you choose, the biggest risk is not the tool. It is detection rules nobody has checked since the package was built, and two tools that both think they own Chrome.

Primary Sources

• Add, assign, and monitor a Win32 app in Microsoft Intune
• Troubleshoot Win32 app issues
• Intune Management Extension for Windows
• Configuration Manager log file reference
• Patch My PC pricing
• Patch My PC Cloud Update Rings
• Robopack pricing and Robopack FAQ
• Action1 expands its free offering to 200 endpoints
• Action1 update rings documentation
• NinjaOne third-party software patch management FAQ

Related Reading

• Intune Win32 detection script generator
• Intune Win32 app stuck at Waiting or Pending
• ConfigMgr app content vs detection before moving to Intune
• Patch Tuesday operations with Intune and WUfB
• Intune vs SCCM/MECM
• Patch Management hub