What is third-party patch management?

Third-party patch management involves updating applications on your endpoints that your OS vendor does not update for you. In practice, that means keeping an accurate inventory of what is actually installed, tracking releases from dozens of independent vendors, packaging each update so it installs silently, and getting it onto machines before the installed version falls too far behind.

Why don't OS patching tools cover third-party apps?

Third-party applications are developed, packaged, and updated by separate vendors. OS vendors don't distribute and manage every third-party patch through the same native update process.

These factors explain why OS patching doesn’t natively cover most third-party apps:

1. Third-party vendors control their own updates

Vendors decide when to release updates, how to distribute them, and what an endpoint needs to install them. An OS patching tool doesn't automatically control that process.

2. There's no single update mechanism for third-party apps

Some apps include built-in updaters, while others rely on an .MSI or .EXE installer. You may need a different deployment or update method depending on the application.

3. Installers don't follow one standard

Apps can have different silent install parameters, dependencies, configuration requirements, and install contexts. Some install per machine; others live inside individual user profiles.

4. Updates may need packaging before deployment

Even when an OS management tool can deploy third-party software, you may need to obtain, package, configure, and test the update first.

These gaps don't always mean OS management tools can't help. Some, including WSUS and Microsoft Intune, can support third-party patching when IT supplies the additional setup or packaging. While WSUS is deprecated, its existing capabilities remain available and supported for production deployments.

How WSUS and Microsoft Intune handle third-party updates

WSUS and Microsoft Intune can support third-party patching, but the level of built-in support depends on the tool and the app. Some updates can come through supported catalogs, while others require IT to package, configure, or maintain the deployment. Neither provides native coverage for every third-party app.

WSUS

When used with Microsoft Configuration Manager, WSUS can distribute updates from supported third-party software update catalogs. To get third-party updates from a catalog onto managed devices, sysadmins need to:

• Subscribe to a catalog

• Sync its update metadata

• Publish the required update content to the software update point

• Deploy it to clients

Microsoft Intune

Intune supports third-party apps through several paths. Sysadmins can package and deploy Win32 apps, which requires configuring details such as install and uninstall commands, requirements, and detection rules.

Microsoft's Enterprise App Catalog provides prepackaged Microsoft and non-Microsoft Win32 apps with predefined installation, requirement, and detection settings. For eligible catalog apps that are set up for managed deployment, Intune can automatically deploy newer versions when they become available.

The practical limitation is coverage. Catalog-supported apps can reduce much of the packaging and update work, but updates that aren't part of supported catalogs may need another publishing or deployment process.

How do you find the third-party apps on your network?

To find third-party apps on your network, inventory the software installed on your endpoints and collect details like application name, version, and device. A current software inventory gives you the baseline you need to find outdated apps, unexpected installations, and what other software needs a closer look.

1. Inventory installed applications

Start with identifying the apps on your managed endpoints. Your inventory should give you enough information to answer:

• What applications are installed?

• Which endpoints have each app installed?

• Which version is installed?

Not every endpoint running the same app is running the same version. Version sprawl can leave your fleet running a mix of releases of the same app.

2. Look for software that doesn't belong

Inventory can turn up applications that didn't come through your normal deployment process. Users may install utilities, browsers, remote access tools, or other software without IT knowing about it.

That's what shadow IT is. An app doesn't have to be malicious to create work for IT. Older app versions may carry more baggage than they seem. If it's installed on a managed endpoint, determine if it's approved, supported, and something you're responsible for patching. Keep an eye out for a few surprises like:

• Multiple versions of the same application

• Software installed outside the normal IT process

• Unapproved applications

• Apps no one uses anymore

• Per-user installations you weren't tracking

• Older versions left behind after an upgrade

Related reading: What are CVEs?

3. Compare installed and current versions

When you have your inventory, compare the installed app versions with the releases you expect the endpoints to run. Doing this will help show you which applications are current and which ones need an update. From there, you have an actionable list of what needs patching and where.

How do common third-party apps update?

Common third-party apps update through vendor-run update services, built-in updaters, or installers that IT deploys and manages. The exact method varies by application, installation type, and configuration, so your patching process should account for how each app handles updates.

Identify the update method for each app before deciding how to patch it.

• If an app already updates itself, decide when to keep that behavior or manage updates centrally.

• If it relies on installer deployment, make sure your patching process can package, deploy, and track new versions.

Should you disable automatic updates for third-party apps?

Sometimes. Make the call app by app. The same update strategy won’t fit every application. Vendor auto-update requires less IT involvement, while centralized patching gives you more control over timing and deployment. Running both can get messy if your patching tool and the app’s updater try to install different releases at the same time.

Vendor auto-update makes sense when you:

• Want updates installed soon after the vendor releases them

• Don't need to test or stage every release before deployment

• Are comfortable letting the vendor control the update schedule

Chrome is a familiar example. Google Update can keep browsers current without waiting for IT to package and deploy every release. Meanwhile, centralized patching makes more sense when you need to:

• Test updates before a large deployment

• Roll out updates in stages or deployment rings

• Control when updates install

• Track deployment and patch status centrally

How do you disable vendor auto-updates and take control?

Configure the update controls, move them to your patching process, and verify that updates continue as expected after you take over. You should understand:

• How each app handles updates

• What happens after you intervene

• If centralized management is the better option

1. Find and configure the vendor's update controls

Use the vendor-supported method to disable or restrict auto-updates, then confirm that your patching process replaces them. Identify what controls the automatic update behavior: a background service, scheduled task, updater.exe, application setting, or admin policy. Check what each control affects before changing it; disabling one updater may leave others active. Exact controls vary by app. For example:

• Google Chrome: Use Google Update policies to control automatic updates, update timing, and target versions. Disabling Chrome updates doesn't stop Google Update itself from updating, and some Chrome components have separate controls.

• Java: Disable automatic update checks through Java’s update controls when you take over patching. Confirm the change applies to the installations you manage. Note that separate out-of-date warnings may continue even after automatic checks are turned off.

• Adobe Acrobat and Reader: Use Adobe’s enterprise controls to disable auto-updates and manage deployment on IT’s schedule.

2. Make sure your patching process picks up the slack

Disabling auto-update without a replacement process leaves software unpatched. After you suppress an updater, ensure you can:

• Detect the installed version

• Deploy the required update

• Confirm that the update completed

• Repeat the process for new releases

Otherwise, you're trading an automated patching process for a manual task you don't need.

Time savings are gold when manual workload already takes up a good chunk of your team's day. According to PDQ’s 2026 State of Sysadmin report, 73% of sysadmins would prefer automation to handle most or all of endpoint management, and 33% report that automation is already freeing up time they would otherwise spend on routine tasks.

3. Don't disable auto-update by default

Some apps are better left to their vendor's updater. If its automatic updates are reliable, letting the updater do its job can save you the packaging and maintenance work.

Should you use prebuilt or custom packages for third-party app patching?

Use prebuilt packages when they meet your deployment requirements and build custom packages when you need more control over installation or configuration. In practice, most environments use a mix of both, depending on the app and what needs to happen before, during, or after deployment.

When to use prebuilt packages

Prebuilt packages are a good fit when the package already does what you need and you don't have a compelling reason to rebuild that work. They can save you from manually tracking down installers, silent parameters, and every new release.

When to build a custom package

Customize your own when the application or environment has requirements a prebuilt package can't cover. You may need a custom package for:

• App-specific configuration files

• Custom install parameters

• Pre- or post-install scripts

• Internal or LOB apps

• Additional deployment steps specific to your environment

How do you tier third-party apps by patch cadence?

Tier third-party apps by setting different patch cadences based on their update frequency, security exposure, business impact, and testing needs. Frequently updated or higher-risk apps may need shorter patch cycles, while apps that require more testing may need a measured schedule.

Consider these factors when assigning apps to a patch cadence:

• Update frequency: Shorter cadence for apps with frequent releases to prevent versions from piling up

• Security exposure: Shorter routine cadence for internet-facing or frequently targeted apps, particularly when an update fixes a high-risk vulnerability

• Business impact: A cadence that allows more testing time for business-critical apps, especially when a bad update could disrupt users and important workflows

• Update history: More testing built into the patch cycle for apps with a history of troublesome installations, compatibility failures, or other update problems

• Testing requirements: Extra time between release and larger rollout for apps that require compatibility testing

Some apps have less room to wait. Verizon’s 2026 Data Breach Investigations Report finds that vulnerability exploitation has become the leading breach entry point, accounting for 31% of breaches. The report also points to recent exploitation activity as a factor IT can weigh when deciding what to patch first. This reinforces why higher-risk apps may require a shorter patch cadence.

Related reading: Essential steps for testing and vetting software packages

You can then group apps into simple patch cadence tiers such as:

• Frequent: High-exposure apps or updates that need quick deployment

• Standard: Routine updates that can follow your normal patch schedule

• Extended: Business-critical or breakage-prone apps that need more validation before you send a new version across the fleet

Your tiers don't have to be fancy. You need tiers that work so you don't end up squeezing your entire software stack into one giant patch window and hoping nothing catches fire.

For larger fleets: Explore Third-party enterprise app patching.

Why are some third-party apps hard to deploy silently?

Silent deployment gets tricky when a third-party app’s installer expects user interaction, a specific install context, or other conditions that get in the way of unattended deployment. How the app was built and installed tells you if it can update quietly in the background or needs to account for a few extra hurdles.

The usual culprits that complicate silent deployment include:

The installer may not fully support silent deployment

Silent deployment depends on what the installer allows. An .MSI or .EXE may require specific silent parameters, display prompts that can't be suppressed, or need additional configuration to run without user interaction.

Confirm which silent install parameters the vendor supports and if the installer can complete without waiting for input.

Active app sessions can interfere with updates

Some apps can't update while they're open. If a user is actively running the application when deployment starts, the installer may fail, postpone the update, or require the process to close first.

Plan how you'll handle running applications ahead of pushing the update onto the fleet, especially software that users tend to leave open all day.

Per-user and per-machine installs behave differently

A per-machine installation is available systemwide, while a per-user installation is tied to an individual user's profile. The distinction can affect:

• Where the app is installed

• Which account can update it

• Whether a deployment running under the system account can access the installation

Some apps need user context or post-install action

An installation can complete silently but still need extra work. The app may require activation, a user sign-in, configuration, or another step before it's ready to use. You may receive a successful installer exit code even when the deployment isn’t complete.

Going the other direction? See how to uninstall silently instead.

How to manage macOS apps with different update mechanisms

Check how a macOS app gets its updates and who manages them before bringing it into your patching process. One process should clearly own each installation because even copies of the same app may follow different update paths.

Avoid having two systems manage the same app. If the existing mechanism reliably works, you may not need to replace it. Common paths include:

Endpoint management tool

An endpoint management tool can centralize macOS app inventory, patching, deployment, and reporting, giving IT one place to manage software across platforms. PDQ, for example, supports Windows and macOS app management, including software inventory and prebuilt or custom package deployment.

Sparkle

Many directly downloaded Mac apps use this open-source software update framework to check for and install new versions from within the app. If you manage the app centrally, account for its existing auto-update behavior so the two workflows don’t clash.

App Store

Installations through Apple’s built-in storefront receive updates through the App Store, not a vendor-supplied installer. If you manage the app centrally, account for its existing update path when deploying another version.

Homebrew

Apps installed through Homebrew follow this package manager's upgrade process and do not rely on their own updater. Before patching a Homebrew-installed app another way, assess if it’s better to continue managing it through Homebrew.

Direct download

Direct installation from a vendor may update itself through a built-in updater like Sparkle or require a new installer. Review the vendor's update mechanism before replacing it with centralized patching.

For the general macOS patching workflow, read PDQ's Managing Macs in a Windows shop guide.

When is removing an app better than patching it?

Removing an app may be better than patching it when the software is no longer needed, supported, or approved. Uninstalling unnecessary apps takes repeated packaging, testing, deployment, and verification work off your plate. It also eliminates another potential source of vulnerabilities from your endpoints, shrinking your attack surface.

• Smaller software footprint = fewer apps to maintain, fewer versions to track, and fewer patches to juggle

Consider removal when an app is:

• Unused: Nobody needs it anymore, but it's still sitting on endpoints waiting for another update.

• Unsupported: The vendor stopped providing security updates or fixes for the installed product or version.

• Redundant: Another approved application already serves the same purpose.

• Unapproved: The app isn’t permitted under your organization's security or software policies.

• Not worth maintaining: The operational or security cost of keeping the app outweighs the value it provides.

Check before you uninstall. Use your software inventory to find potential removal candidates, but don't uninstall based on inventory data alone. Confirm that the app isn't required by users, business workflows, or other software.

How do you show third-party app versions for an audit?

Use current software inventory and version reporting to show auditors which third-party app versions are installed on your endpoints. Keep it separate from deployment reporting.

• Deployment records = show that you sent a patch

• Inventory data = confirms that the expected release landed

In the 2026 State of Sysadmin report, 49% of sysadmins say compliance and audit work consume more time than they’d like. Keeping evidence handy means one less thing to scramble for later.

It makes exceptions easier to spot, too. If 498 endpoints run the expected app version and two don't, you have two devices to investigate instead of a “successful” deployment report that says everything went according to plan. For each app, be prepared to show:

• Application: What software is installed

• Installed version: Which release the endpoint currently runs

• Endpoint: Which devices have each version installed

• Patch status: Whether the installed version meets your current patch requirements

• Exceptions: Which endpoints are missing the expected version or don’t match your patch requirements

Don't rely on patch deployment status alone. A successful status tells you that the deployment ran, but verifying what's installed is what counts for evidence.

How does PDQ help with third-party patch management?

PDQ helps IT teams automate third-party patching across Windows and macOS endpoints from a cloud-based platform. Instead of manually tracking new application versions, building every deployment from scratch, and following up device by device, admins can use prebuilt packages and software policies to keep supported applications up to date.

Third-party patching FAQs

Can Windows Update patch third-party applications?

No, Windows Update generally doesn't patch third-party apps. It primarily handles Windows and supported Microsoft products. You need another patching process to manage, deploy, and track updates for software that's beyond Windows Update's native coverage.

How do you patch line-of-business (LOB) and internal apps?

Patch LOB and internal apps like other third-party software, but expect more custom work when there’s no standard package or update process to fall back on. You may need vendor-provided installers, configuration files, scripts, or post-install steps. Document these requirements in a repeatable package.

How do you patch third-party apps on offline or remote endpoints?

For endpoints that are asleep, shut down, or off-network during the original deployment, retry the update when they reconnect. Some third-party patch management tools handle this natively. Otherwise, reschedule as needed, then check if the update went through.

When should you deploy an emergency third-party patch?

Push an emergency third-party patch when delaying the update poses more risk than deploying outside your normal cadence. Situations that warrant emergency patching include actively exploited vulnerabilities and critical flaws on internet-facing apps. Routine and lower-risk fixes can usually wait for your normal patch window.

Which metrics should you track for third-party patching?

Useful third-party patching metrics include deployment time, patch coverage, failure rate, and outstanding exceptions. Compare deployment results with current software inventory so a successful status doesn’t hide endpoints that still run an outdated release.

What should you look for in a third-party patch management tool?

Choose a third-party patching tool that finds outdated apps, automates deployments, confirms results, and reports status. Look for broad app coverage, package customization, scheduling, retry options, and remote device support. An efficient tool should make routine patching less hands on.

Do third-party application updates require a reboot?

Yes, some third-party application updates require a reboot, but many don’t. A restart may be necessary when the installer can’t replace files, services, or components currently in use. Plan required restarts around users' active hours to minimize interruption.