Patch Management

Third-Party Application Patching Workflow for MSPs

How to extend your patching workflow beyond Windows updates to cover the applications that attackers actually target: browsers, PDF readers, conferencing tools, and LOB software.

Workflow guide Â· Updated Feb 2026

By MSP Workflows Team

Contents

1.The Gap Most MSPs Ignore
2.Build a third-party application inventory
3.Choose your patching approach per application
4.Define approval and soak rules
5.Deploy and verify
6.Handle LOB application conflicts
7.Shadow applications are the real risk
8.Use the right tool for the job
9.Which third-party applications should MSPs prioritize?
10.How do MSPs patch applications that don't have silent install options?
11.Should browser auto-update be disabled in favor of managed patching?

The Gap Most MSPs Ignore

Most MSP patching workflows handle Windows updates reliably. Third-party applications are a different story. Chrome, Firefox, Adobe Reader, Zoom, Java, and dozens of other applications release security updates on their own schedules, through their own update mechanisms, with their own quirks. The problem is that attackers know this. The majority of exploited vulnerabilities in recent years targeted third-party applications, not the OS itself. An endpoint that's fully patched on Windows but running Chrome 3 versions behind has a significant unpatched attack surface.

Build a third-party application inventory

Before you can patch third-party applications, you need to know what's installed. Run a software audit across all managed endpoints. Most RMMs provide software inventory reports. Identify every application that receives security updates, who publishes those updates, and how frequently they release. Focus on the high-risk applications first: web browsers, PDF readers, Java runtimes, conferencing tools, and any application that processes untrusted input from the internet.

Choose your patching approach per application

Not every application can be patched the same way. Some applications (Chrome, Edge) have built-in auto-update mechanisms that work well and should be left enabled. Others (Java, Adobe Reader) have auto-update mechanisms that are unreliable and should be managed through your RMM or a dedicated tool like ImmyBot. For each application, decide: let the built-in updater handle it, manage it through your RMM's third-party patching module, manage it through a dedicated tool, or exclude it and document the exception.

Define approval and soak rules

Apply the same classification logic you use for OS patches. Security updates for major browsers and PDF readers should auto-approve after a 24 to 48 hour soak period. Major version upgrades (Java 17 to 21, for example) should require manual approval and testing against client LOB applications.

Deploy and verify

Deploy third-party updates during the same maintenance window as OS patches or in a separate window if the client prefers. Verify installation by checking the application version post-deployment, not just the deployment status. An update that "deployed successfully" but left the old version running is not actually applied.

Handle LOB application conflicts

Line-of-business applications are the biggest source of third-party patching headaches. A Java update breaks the client's EHR system. A .NET update breaks their accounting software. Build a registry of known LOB application dependencies per client and test updates against those dependencies before deploying broadly. If a client's LOB vendor requires a specific application version, document the requirement, exclude that application from your automated patching, and accept the risk in writing.

Shadow applications are the real risk

The applications you know about are manageable. The ones users install themselves (personal Dropbox, unauthorized remote access tools, random browser extensions) are the real exposure. Run your software inventory scan monthly and flag anything that shouldn't be there. Work with the client to either formalize or remove unauthorized software.

Use the right tool for the job

If your RMM's third-party patching covers the top 20 applications reliably, that may be enough. If you're managing environments with dozens of niche applications, ImmyBot's desired-state model handles the long tail much better than most RMM modules. Match the tool to the complexity of the environment.

Which third-party applications should MSPs prioritize?

Start with the applications that process untrusted internet content: web browsers (Chrome, Firefox, Edge), PDF readers (Adobe Acrobat Reader), email clients, conferencing tools (Zoom, Teams), and Java. These have the highest exploit frequency and the broadest install base across client environments.

How do MSPs patch applications that don't have silent install options?

Some applications require user interaction to update. For these, either deploy the update with a user prompt during business hours, schedule a scripted deployment that handles the install silently (most applications can be installed silently even if the default updater requires interaction), or coordinate a manual update during a maintenance window.

Should browser auto-update be disabled in favor of managed patching?

No. Browser auto-update mechanisms are fast and reliable. Disabling them to funnel updates through your RMM adds delay without adding control. Leave browser auto-update enabled and use your RMM to verify that updates have actually applied rather than trying to manage the deployment.

← Back to all guides