WSUS Third Party Patch Management | A Comprehensive Guide

TL;DR

• Native WSUS only patches Microsoft products, leaving browsers, PDF readers, collaboration tools, Java runtimes, and hundreds of third-party applications outside its default management capabilities.
• Third-party patch management with WSUS requires additional technologies, such as SCUP-compatible catalogs, vendor publishing services, or specialized patch management solutions that publish updates into WSUS.
• The guide explains the complete deployment process, including catalog synchronization, update publishing, code signing, client configuration, testing, approval workflows, deployment, verification, and compliance reporting.
• Security and compliance depend heavily on third-party patching, since many cyberattacks target vulnerabilities in widely used applications like Adobe Acrobat, Google Chrome, Zoom, Mozilla Firefox, Java, and 7-Zip rather than Windows itself.
• Organizations should understand WSUS limitations, including Windows-only infrastructure, manual catalog management, limited automation, lack of native support for many third-party vendors, and increasing administrative overhead in hybrid environments.
• The guide compares several approaches, including native WSUS, Microsoft Configuration Manager (SCCM/MECM), System Center Updates Publisher (SCUP), vendor update catalogs, and modern cloud-native patch management platforms that automate both Microsoft and third-party application updates.
• Best practices include risk-based prioritization, staged deployments, pilot testing, rollback planning, code-signing validation, automated reporting, regular catalog maintenance, and integrating third-party patching into a broader vulnerability management program.
• For organizations with remote or hybrid workforces, modern cloud-native patch management platforms provide centralized management, real-time visibility, automated compliance reporting, and third-party application patching without requiring on-premises WSUS infrastructure or VPN connectivity.

Organizations use Windows Server Update Services (WSUS) as a local, on-premises repository to manage Microsoft updates. But if your vulnerability scanners are lighting up with unpatched instances of Adobe Reader, Chrome, Java, Zoom, 7-Zip, and other non-Microsoft applications, you already know the limitation of your patching setup: native WSUS only handles Microsoft updates and nothing else.

To fill this security gap, you must extend WSUS capabilities. A common approach is to use Microsoft Configuration Manager’s Third-Party Software Update Catalogs feature to subscribe to vendor catalogs and sync their metadata into WSUS. That done, you can deploy those third-party updates via the same console, collections, and maintenance windows as you use for Windows patches.

This guide shows how to integrate, configure, and automate third-party patch management using Microsoft Configuration Manager (ConfigMgr/SCCM) and advanced third-party tools.

Prerequisites and Environment Setup

For third-party patching through WSUS, confirm the following:

Additional Requirements When the SUP Is Remote from the Top-Level Site Server

If your SUP runs on a separate server from the top-level Configuration Manager site server, you must also attend to the following:

Enable Third-Party Updates on the SUP

When you enable the Third-Party Software Updates feature on the SUP, it changes how the SUP synchronizes update catalogs. By default, WSUS only syncs Microsoft update metadata. Activating this feature tells the SUP to import, process, and display application metadata from supported third-party software vendors as well. As a result, you can manage both Microsoft and non-Microsoft updates from the same Configuration Manager console.

To enable the third-party software updates feature on the SUP in Configuration Manager, follow these steps:

1. Open your Configuration Manager console and navigate to the Administration
2. Expand Site Configuration and select the Sites
3. Select your top-level site. On the ribbon, click Configure Site Components, and select Software Update Point from the dropdown menu.
4. In the Software Update Point Component Properties dialog box, click on the Third-Party Updates
5. Check the Enable third-party software updates

Enabling this feature is a one-time change that applies to your entire Configuration Manager hierarchy.

However, this checkbox alone doesn’t do anything until you address these dependencies:

• The Server-Side Trust: WSUS must have a code-signing certificate to digitally sign third-party updates before they are published to clients.
• The Client-Side Trust: Managed devices must trust that certificate and be configured to accept third-party software updates.

 Configure the WSUS Signing Certificate

Third-party patches aren’t Microsoft-signed. So, endpoints will reject them unless they are signed by a trusted internal authority. The WSUS signing certificate (code-signing certificate) satisfies this requirement.

Automatically Manage the WSUS Signing Certificate

If your organization doesn’t require a certificate from a specific certification authority (CA) or an existing PKI, select “Configuration Manager manages the certificate”. Configuration Manager automatically creates a self-signed ‘Third-Party WSUS Signing’ certificate during the synchronization process and records the operation in wsyncmgr.log. It then uses this certificate to sign third-party updates published through WSUS.

1. In the Configuration Manager console, go to the Administration
2. Expand Site Configuration and select the Sites
3. Select the top-level site in the hierarchy. On the ribbon, click Configure Site Components, and select Software Update Point.
4. On the Third-Party Updates tab, select Configuration Manager manages the certificate.
5. A new certificate of type ‘Third-party WSUS Signing’ is created in the Certificates node under Security in the Administration

When to use: Choose this path for environments with simpler infrastructure or relaxed compliance requirements. Or situations where you don’t have access to a PKI.

 Manually Manage the WSUS Signing Certificate

If your organization requires all signing certificates to trace back to an internal certification authority (CA), select “Manually manage the certificate”. Choosing this path means that you will utilize your enterprise PKI (such as Active Directory Certificate Services) to generate, issue, and manage the certificate used to sign third-party updates. This takes longer and you would also have to re-validate the certificate as it nears expiration, but it’s the only option for strict compliance environments.

When to use: Choose this option in environments with rigid compliance requirements, strict change control, or where self-signed certificates are blocked by default.

The workflow:

1. Generate a code-signing certificate template from your internal Enterprise Certificate Authority (CA). Ensure that the Extended Key Usage (EKU) contains Code Signing (1.3.6.1.5.5.7.3.3).
2. Request and export the certificate from the CA with its private key in a .pfx format.
3. Use System Center Updates Publisher (SCUP) or a similar tool to configure the certificate.
4. In the Configuration Manager console, go to the Administration
5. Expand Site Configuration and select the Sites
6. Select the top-level site in the hierarchy. On the ribbon, click Configure Site Components, and select Software Update Point.
7. On the Third-Party Updates tab, select Manually manage the certificate.

 Enable Third-Party Updates on the Clients

Once your server infrastructure can handle third-party updates, the next step is to configure your managed devices to accept them.

To do this, create and deploy a custom client settings policy in Configuration Manager. Run the following steps for each custom client setting you want to use for third-party updates:

1. Go to the Administration workspace and select the Client Settings
2. Select an existing custom client setting or create a new one.
3. Select the Software Updates tab on the left side. f you don’t have this tab, make sure that the Software Updatesbox is enabled.
4. Locate the setting labeled Enable third-party software updates and switch it to Yes.
5. Deploy the custom device client settings policy to the device collections that should receive third-party updates.

Setting this option to “Yes” does the following:

• It configures the local Windows Update Agent policy on the target endpoints to “Allow signed updates from an intranet Microsoft update service location”.
• It installs the WSUS signing certificate to the Trusted Publisher store on the client. You can monitor certificate management activities in the updatesdeployment.log file on the client machines.

Add a Custom Catalog

Many hardware and software vendors publish dedicated catalogs that contain the metadata for their products. Configuration Manager supports two types of catalogs:

• Partner catalogs: Pre-registered catalogs provided by vendors that participate in Microsoft’s partner program.
• Custom catalogs: Any other vendor catalog is a custom catalog.

To add a custom third-party update catalog to Configuration Manager, follow these steps:

1. Go to the Software Library workspace in the Configuration Manager console.
2. Expand Software Updates and select the Third-Party Software Update Catalogs
3. Click Add Custom Catalog on the ribbon.
4. On the General page, enter the catalog URL provided by the software vendor (it must begin with https://), along with the publisher name, catalog name, and description.
   You can get the download/catalog URL from the vendor’s documentation. If this URL is wrong or outdated, the catalog will not be imported.
5. Review the summary page and complete the wizard.

The catalog is added to Configuration Manager but it isn’t active yet. You still have to subscribe to it.

Subscribe to a Third-Party Catalog and Sync Updates

Adding a catalog registers it with Configuration Manager. When you subscribe to it, the metadata for every update in the catalog are synced into the WSUS servers for your SUPs. This enables the clients to determine which updates are applicable.

Follow these steps to subscribe to a third-party catalog and sync updates:

1. In the Configuration Manager console, navigate to the same location as adding the catalog: Software Library > Software Updates > Third-Party Software Update Catalogs.
2. Select the catalog (partner or custom) from the list and click Subscribe to Catalog in the ribbon.
3. On the wizard, review and approve the catalog’s certificate (type Third-party Software Updates Catalog). If the vendor changes the certificate, you’ll have to re-approve the new one. Synchronization fails if you forget this (status 11508, see the Known Issues and Troubleshooting section).
4. For v3 catalogs, choose the categories and staging options. See the Third-Party v3 Catalog Options section for details.
5. Set a sync schedule for download checking, such as daily, monthly, or custom.
6. Complete the wizard.
7. Once the catalog is downloaded, you have to manually trigger a software update sync to synchronize the product metadata from the WSUS database into the Configuration Manager database. Go to Software Library > Software Updates > right-click the top-level All Software Updates Then on the Home tab, in the All Software Updates group, click Synchronize Software Updates. You can also monitor it from the Monitoring workspace.
8. Configure which products/classifications to synchronize under SUP product settings, then sync again to pull update metadata. To do so, go to Administration > Site Configuration > Sites > select your top-level site. Then on the Home tab, in the Settings group, click Configure Site Components > Software Update Point, then the Products and Classifications tabs.
9. Once synchronization completes, navigate to Software Library > Software Updates > All Software Updates. Your third-party updates will now appear in the master update pool with a blue arrow icon, indicating that they exist as metadata-only definitions (unless you choose to publish them).

Deploy and Manage Third-Party Patches Through WSUS

Now that third-party updates are in the All Software Updates node, you can choose the ones you want to publish for deployment. On publishing, the update’s binary files are downloaded from the vendor and stored in the WSUSContent directory on the top-level SUP.

Follow these steps to publish and deploy third-party software updates:

1. In the Configuration Manager console, go to the Software Library
2. Expand Software Updates and select the All Software Updates
3. Use Add Criteria to filter the list of updates (for example, by Vendor).
4. Select the third-party updates you intend to deploy and then select Publish Third-Party Software Update Content. This downloads vendor binaries into WSUSContent.
5. Run a manual sync to flip the status of the published updates from metadata-only to deployable. To do so, go to Software Library > Software Updates > All Software Updates. Then on the Home tab, in the All Software Updates group, click Synchronize Software Updates.
   Watch SMS_ISVUPDATES_SYNCAGENT.log for progress, located on the top-level SUP in the site system Logs folder.
6. Now deploy the updates using the Deploy Software Updates wizard, as discussed here. Remember to choose Download software updates from the internet on the Download Locations page. In this scenario, the content is already published to the SUP, which is used to download the content for the deployment package.
7. Run a Software Updates Scan Cycle on a test client from the Configuration Manager control panel before validating compliance at scale.

Tip: Treat third-party deployments like Patch Tuesday: Pilot → Phase → Production. Always confirm stability before rolling out to full production.

From Subscription to First Deployed Patch: A Tentative Timeline

The following data is based on elapsed time from a rollout, roughly 200 managed endpoints, single vendor catalog:

The technical steps are almost the same from a 50-endpoint pilot to a 500-endpoint rollout, but ring size and pilot soak time vary.

Third-Party v3 Catalog Options

Third-party v3 catalogs provide options for controlling update synchronization, staging, and publishing. Here is how they compare to legacy catalogs:

It’s apparent that the v3 catalog format supports categorized updates, unlocking two things that legacy catalogs can’t do:

• Selective category sync: sync only the update categories you need instead of the entire catalog.
• Automatic content staging: when you are certain that you’ll deploy a category, you can configure it to auto-download binaries and publish to WSUS.

Configure these options when subscribing to a third-party catalog, or later through properties.

To configure while subscribing:

• On the Select Categories page: Choose the Select categories for synchronization option and then select the categories you want to synchronize into Configuration Manager.
• On the Stage Update Content page: Choose the Stage the content for selected categories automatically option and then select the update categories for which you want to auto download content to the WSUSContent directory on the top-level SUP. It is recommended that you auto-stage content only for updates that you are likely to deploy. Else it’s safer to select the Do not stage content

Check the vendor’s documentation to see whether they support v3 catalogs. Vendors like Dell, HP, and Lenovo use the v3 schema, so admins can select the products, languages, and update categories they want to synchronize.

Monitoring and Reporting on Third-Party Updates

Here is how you can monitor sync progress, deployment status, and compliance rates for third-party updates:

 Benefits of Using a Third-Party Patch Management Tool with WSUS

Native Configuration Manager can handle catalog subscription and distribution but it cannot tackle “which of my 200 applications have available patches”, “test before deploy”, and “audit-ready reporting” at scale. For that, consider pairing WSUS with a dedicated third-party patch management tool. Benefits include:

• Broader application coverage: Get access to hundreds of pre-packaged third-party applications instead of staying restricted to a handful of Microsoft partner catalogs and manually having to locate vendor catalogs and URLs.
• Ready-to-deploy packages: Installation commands, detection rules, version checks, exit code handling, and application-specific logic are already built and tested, relieving you of manual packaging work.
• Automatic dependency handling: If a third-party application has certain runtimes and prerequisite components as dependencies, dedicated patch management tools automatically detect, package, and deploy them along with the primary application.
• Built-in testing and phased deployments: Third-party tools let you roll out updates in stages. Built-in pilot groups, or update rings, make it easy to test updates on a small group of devices first. In this way, you can catch compatibility issues before they hit production.
• Centralized management: Subscribe to catalogs, publish updates, approve deployments, and review compliance from one console instead of managing each vendor separately.
• Improved reporting and visibility: With detailed reporting, you can track patch compliance, deployment status, and missing updates easily. These reports support both day-to-day operations and compliance reporting.

The best part is, these tools sit on top of the same WSUS infrastructure. They publish updates to the same content store and use the same client-side mechanisms. You’re extending the platform, not replacing it.

Enterprise-Wide Inventory and Discovery

Dedicated third-party patch management tools continuously inventory software across physical and virtual endpoints to identify installed applications and their versions. They discover software by scanning Windows registry uninstall keys, installed programs, file metadata, and other system information, then compare the results against their application catalog to determine which products are missing updates. Advanced tools also cross-reference installed software against a vulnerability database. This matters because an app with a known CVE but no vendor patch yet represents a risk, while catalog-only visibility does not flag it until a fix exists.

Configuration Manager’s built-in scheduled hardware inventory gives a baseline, but it’s a point-in-time snapshot. Dedicated patch management solutions perform more frequent discovery. This continuous inventory gives you a near real-time view of outdated software and can uncover shadow applications that might otherwise be missed.

 Automate and Extend WSUS Patch Management

Automation handles repetitive routine tasks efficiently.

Configuration Manager PowerShell Cmdlets

You can automate your third-party maintenance tasks by using administrative PowerShell commands, which can be executed from the Configuration Manager site drive:

# Query all registered third-party update catalogs

Get-CMThirdPartyUpdateCatalog

# Force an immediate processing sync on a specific catalog asset

Set-CMThirdPartyUpdateCatalog -Name “Vendor Catalog Name” -SyncNow

# Configure Software Update Client settings to enable third-party components

Set-CMClientSettingSoftwareUpdate -DefaultSetting -EnableThirdPartyUpdates $true

Automation Best Practices

Plan automation around scheduled catalog syncs, automatic deployment rules for categories you want to auto-approve, and maintenance windows, ensuring installations occur only during approved periods. Updates should progress to the next phase based on deployment success and compliance in the preceding phase, not on fixed calendar dates.

• Automatic Deployment Rules (ADRs): Create dedicated ADRs for third-party updates and configure them to target specific vendors, products, or severity levels. Once a catalog synchronization completes, ADRs can automatically approve updates, create software update groups, download content, and deploy the updates to the appropriate collections.
• Phased deployments: Roll out updates in stages instead of deploying them organization-wide at once. For example, deploy updates to an IT pilot collection first, then advance to a staging group upon success, and finally deploy to production. This limits the impact of problematic updates.

 Manage Subscriptions and Catalogs

You should regularly review your active catalog lists to keep your site database optimized.

WSUS Alternatives for Third-Party Patching

Sysadmins debate whether to extend WSUS or move to a different patch management platform entirely. This conversation comes up frequently in community forums, with participants complaining about limited third-party application coverage, a lack of cross-platform support, and non-audit-ready reporting.

So when to stay on WSUS vs. switch? The right answer depends on various factors, including your organization’s size, software portfolio, environment, budget, and compliance requirements.

• Consider a cloud-native approach if you’re moving to a remote-first workforce, migrating workloads to the cloud, or already managing endpoints with Microsoft Intune. Third-party patching can be handled through Intune’s Enterprise App Management, WinGet, or a cloud-based patch management platform.
• Choose a dedicated patch management platform if you want centralized, push-based patching for servers and endpoints without depending on WSUS. These solutions provide cross-platform support, wide third-party application coverage, automated packaging, rich reporting, and support for devices both on and off the corporate network.
• Extend WSUS and Configuration Manager if you have a dominant on-premises Windows environment, defined server patching workflows, limited internet bandwidth, and investment in Configuration Manager. For smaller environments with a handful of common third-party applications, extending WSUS with a catalog subscription works well.

Action1: A Cloud-Native Alternative

Action1 is a cloud-native platform that patches Windows, macOS, and Linux endpoints along with 600+ third-party applications, without a VPN, on-premises servers, and an SCCM/Intune/WSUS deployment. It:

• Uses bandwidth-efficient peer-to-peer technology to distribute updates across networks
• Patches offline/remote endpoints as they come online
• Auto-discovers and prioritizes missing patches on endpoints
• Allows packaging and patching of applications outside the native Action1 catalog
• Custom software repository for packaging and patching applications outside its native catalog
• First 200 endpoints free with no feature limits

15 Known Issues and Troubleshooting

Here are some known issues with WSUS third-party update integration:

• Certificate trust on the console machine
  The machine running the console downloads updates from WSUS and must trust the signing certificate itself, not just the SUP or clients. A missing trust causes signature failures when downloading third-party updates.
• Metadata-only updates from outside tools
  If a metadata-only update was added to WSUS by a tool or script other than Configuration Manager’s third-party update synchronization (for example, an older SCUP import), the Publish Third-Party Software Update Content action will fail. If the update is available through a subscribed third-party catalog, republish it using that catalog. Otherwise, keep managing it through the original process.
• Proxy-related signature failures
  When the third-party software update synchronization service on the top-level SUP needs a proxy server for internet access, digital signature checks may fail. This is a WinHTTP configuration issue, not a certificate problem.
• CMG content delivery gap
  If you are using Cloud Management Gateway for content storage, disable the “Download delta content when available” client setting. If it is enabled, clients won’t download content for third-party updates.

Status Message Reference