Other resources

Release Notes

Video Tutorial

Support Knowledge Base
(login required)

Patch overview

Use Patch to manage operating system patching across your enterprise at the speed and scale of Tanium™. You can deploy a single patch to a computer group immediately. You can also perform more complex tasks, such as using advanced rule sets and maintenance windows to deliver groups of patches across your environment at specified times.

You can define custom workflows and schedule patches based on rules or exceptions built around patch lists, blacklists, and maintenance windows. For example, you might always apply critical Microsoft patches to all machines except for datacenter servers, or always exclude .NET patches, or install patches during non-working hours.

Patch generates in-depth reports and returns current patch applicability results from every endpoint. For any patch or patch list deployment, the following details are provided:

  • The patch details, such as severity, release date, applicable Common Vulnerabilities and Exposures (CVE), files, and links to knowledge base articles.
  • The status of the patch, split out by computer group.
  • The assigned patch lists or blacklists for the patch.

Patch scanning options

You can choose from several scan methods to determine the installed and missing patches across your network. Scan configurations define a scan method, scan frequency, and the computer groups that are being scanned, known as an enforcement. One scan configuration is applied to an endpoint. If an endpoint is included in multiple computer groups, the highest priority scan configuration is applied.

Review the following list of scanning options to decide the best method to use for each computer group.

Table 1:   Available patch scanning options
Scan method Platform OS Updates included Client impact Connectivity Details
Offline CAB file1 Windows
  • Security Updates
  • Service Packs
  • Update Rollups
Moderate, during scanning activity The CAB file is stored locally by the Tanium Client.
  • Requires 600+MB download of CAB file.
  • Does not include routine updates, out of band fixes, hotfixes, and enhancements that are included with WSUS or Online to Microsoft scan methods.
Online to Microsoft Windows
  • Scanning: Critical Updates, Security Updates, Definition Updates, Update Rollups, Service Packs, Tools, Feature Packs, Updates, Upgrades, Drivers
  • Installing: Critical Updates, Security Updates, Update Rollups, Service Packs, Tools, Updates
  • Moderate, during first scan
  • Low, subsequent
The Tanium Client must contact Microsoft directly.
  • Requires additional network traffic to Microsoft directly.
  • Feature Pack and Driver updates should be blacklisted for installation.
Tanium Scan Windows 7 or later
  • Critical Updates
  • Feature Packs
  • Security Updates
  • Service Packs
  • Tools
  • Update Rollups
  • Updates
  • Moderate, during first scan
  • Low, subsequent
A client database file is stored locally by the Tanium Client. The Patch service is configured to synchronize update metadata and detection rules from Microsoft Update or a Microsoft WSUS server.
Windows Server Update Services (WSUS) Scan Windows
  • Scanning: Critical Updates, Security Updates, Definition Updates, Update Rollups, Service Packs, Tools, Feature Packs, Updates, Upgrades, Drivers
  • Installing: Critical Updates, Security Updates, Update Rollups, Service Packs, Tools, Updates
Low The Tanium Client must contact the WSUS server.
  • Must deploy and configure one or more WSUS servers.
  • Updates must be approved in WSUS prior to scanning or deployment.
  • Feature Pack and Driver updates should be blacklisted for installation.
Repository Scan2
  • Red Hat
  • CentOS
  • Oracle Linux
  • Amazon Linux
All updates in the Yum repositories Moderate, during scanning activity The Tanium Client must contact the Yum repositories for scanning as well as patch downloads.
  • Must deploy and configure one or more Yum repositories.
  • Updates must be maintained in the Yum repositories.
Tanium Scan2
  • Red Hat
  • CentOS
  • Oracle Linux
All updates in the Yum repositories Moderate, during scanning activity The Tanium Client stores the repository scanning logic locally.
  • Internal or external Yum repositories can be used.
  • Only the Tanium Server needs connectivity to the Yum repositories.

1 Offline CAB file includes only Security Updates, Service Packs, and Update Rollups updates. Because other scan methods include more updates than Offline CAB file includes, if you change the scan configuration technique on an active deployment from Offline CAB file to another technique, additional patches might be installed on endpoints.

2 For more information, see Tanium dependencies and Linux scan techniques.

If you are using Microsoft System Center Configuration Manager (SCCM) with your WSUS server, do not use Tanium for WSUS scanning with the same server.

Patch lists and blacklists

A patch list contains patches that can be applied. A blacklist contains patches that must be excluded. Patch provides a baseline reporting patch list for each supported operating system. You can also create patch lists and blacklists. These lists can be determined by any detail included in the patch information.

For example, you could

  • Create lists based on severity, prioritize the most critical and most recent updates first.
  • Focus only on CVE issues.
  • Create lists based on the month or a specific release date.

As new patches come out, you can use dynamic rules to automatically assess and populate patches to the appropriate lists. You can iteratively develop these lists by creating new versions. You can deploy any version of the list as needed.

Superseded patches

Each patch includes a column that indicates if the patch has been superseded, or effectively replaced by a newer patch. A patch is marked as superseded when a single endpoint reports that the patch is superseded. Including superseded patches in patch lists can be useful when you want to find or install a specific patch that was superseded. For example, you might need to find or install superseded patches when they are referenced in a security advisory recommendation. Superseded patches are automatically included in blacklists.

Microsoft update and servicing details

Microsoft provides software patch updates in different ways depending on the operating system of the endpoint. Microsoft changes these terms occasionally, and it is important to understand how these policies affect your patching processes.

  • Windows 10, Windows Server 2016, and Windows Server 2019
    • Feature Updates: Feature builds are essentially a new build of Windows 10. These upgrades are published twice a year with a target of March and September of each year (for example 1709, 1803, 1809, 1902, 1909). Consider the following Tanium capabilities when you select a solution for Windows feature updates.
    • 2019-XX Cumulative Update: Released monthly, a cumulative update supersedes any previous cumulative update for Windows 10. Contains all security and non-security fixes for the month and all previous months.
  • Windows 7, 8.1, 2008, 2008R2, 2012, 2012R2
    • 2019-XX Security Monthly Quality Rollup: Package is a cumulative update for current and all previous months. Only the current month will be applicable. All previous versions are superseded.
    • 2019-XX Security Only Quality Update: Security updates for the specified month only. Does not include updates from any previous month. Previous monthly updates will still be applicable and needed.
    Do not deploy both the Security Monthly Quality Rollup and the Security Only Quality Update for the same month at the same time. If both updates are targeted to an endpoint, the Windows Update Agent installs the Security Monthly Quality Rollup, and the Security Only update is ignored. The download size increases without any benefit.

For more information, see Exclude patches with blacklists.


Deployments compile patches, typically from lists, and then distribute Patch packages to the target computers. You can configure deployment options to set when and how patches are installed or uninstalled.

For example, you might want to restart an endpoint after patches are installed to apply the changes. If a patch comes out that would normally be blacklisted but is needed for some reason, you can override the blacklist for that specific deployment rather than making a new version the blacklist. In urgent situations, you can even override a closed maintenance window.

You can choose whether to restart the endpoint after patch installation, to inform the user about the restart, and to allow the user to postpone the restart.

Maintenance windows

Maintenance windows designate the permitted times that the targeted computer groups are open for patches to be installed or uninstalled. You can have multiple maintenance windows, even with overlapping times. Maintenance windows do not interfere with each other. For a patch deployment to take effect, the deployment and maintenance window times must be met.

Consider establishing a maintenance cycle that keeps your endpoints as up-to-date as possible. You can avoid many security risks with good operational hygiene. Some considerations might include coordinating with the Microsoft Patch Tuesday releases, on weekends, or outside the core work hours for your network.

Repository snapshots

A Yum repository snapshot captures point-in-time metadata that determine patch versions and their dependencies, and provide control over dependencies for Linux endpoint patches.

Repository snapshots are not recommended for the official CentOS mirrors. Those mirrors might not have all of the required dependencies that a snapshot lists after a certain amount of time. For best results with CentOS, create and maintain a metadata source repository and manage packages. Snapshots are not supported for Amazon Linux.

Repository snapshots have the following requirements:

  • Minimum Patch version:
    • For deployments to Red Hat and CentOS Linux endpoints, Patch 2.4.1.
    • For deployments to Oracle Linux endpoints, Patch 2.4.3.
  • The Patch process must be running on all Linux endpoints. For more information, see Patch process is not running.
  • Patch must be enabled for Linux endpoints. For more information, see Enable Patch for Linux endpoints.
  • You must use the Tanium Scan for Linux scan method. For more information, see Tanium Scan.
  • You must create a repository snapshot. For more information, see Manage Linux repository snapshots.
  • You must create a scan configuration with the Deployment Snapshots option enabled. For more information, see Create a scan configuration.

Integration with other Tanium products

Patch integrates with other Tanium products to provide additional features and reporting.


Patch has built in integration with Tanium™ Trends for additional reporting of patch data. The Patch board displays information about missing patches, service-level-agreement (SLA) based compliance reports, time between a patch release and its installation, endpoint status, and scan errors. The following panels are in the Patch board:

  • Patch Coverage
  • Patch Visibility
  • Workstations - Mean Time to Patch
  • Servers - Mean Time to Patch
  • Missing Patches by Severity - Latest
  • Missing Patches by Severity - Last 90 days
  • Online Endpoints - Patch Compliance
  • Historical - Patch Compliance
  • Online Endpoints - 30 Day SLA Compliance
  • Historical - 30 Day SLA Compliance
  • Days Since Last Patch Scan
  • Scan Errors - Last 7 Days

For more information, see Tanium Trends User Guide: Importing the initial gallery.