Tanium Client concepts


When you first deploy the Tanium Client to an endpoint, the client initiates a connection to Tanium™ Cloud the Tanium Server or Tanium Zone Server that is assigned to it in the initial configuration. During initial registration, the Tanium Client establishes a unique ID, and Tanium Cloud the server sends it the latest client settings, a list of nearby peers, and the latest definitions for sensors, questions, and scheduled actions. By default, the initial registration status is configured to reset at randomized intervals of two to six hours, forcing the Tanium Client to re-initialize registration. Repeating the initial registration ensures that Tanium Cloud the server applies the latest settings and the clients select optimal peers.

The Tanium Client also re-registers with Tanium Cloud the server through a normal registration, which occurs by default at a randomized interval of 30 to 90 seconds. During a normal registration, the Tanium Client reports its current state of questions, actions, and settings to Tanium Cloud the server. In response, Tanium Cloud the server sends new questions, actions, or settings to apply. In environments with numerous endpoints, normal registrations are the primary way that Tanium Clients receive new questions, actions, and settings.

Client peering

In an enterprise network, Tanium Clients establish peer relationships with each other in a linear chain. Peer connections are continuous, long-lived connections that the clients use to exchange Tanium messages and files. During registration, Tanium Cloud the server sends the Tanium Client a peer list of other Tanium Clients with which it can try to establish a peer connection. The Tanium Client uses the list to determine which peers are the most optimal neighbors within the linear chain.

To customize client peering settings to suit your deployment, see Configuring Tanium Client peering.

Forward and backward leaders

By design, one forward leader and one backward leader terminate opposite ends of the linear chain. Other than at registration, only leaders establish direct connections with Tanium Cloud the Tanium Server or Zone Server. Tanium Cloud The server passes sensors, questions, and scheduled actions to the backward leader, which passes them to its forward peer, which in turn passes them to its forward peer, and so on, until they reach the forward leader. The forward leader returns the question answers and the scheduled action statuses to Tanium Cloud the server.

Tanium Clients establish outgoing connections to backward peers for file distribution (see File distribution).

Figure  1:  Tanium Client linear chain

Forward and backward reflection

Tanium peer communication is designed to accommodate new clients that come online, to route around clients that are removed or stop communicating effectively, and to reflect around network-level blockages, such as firewall blocking. Forward reflection occurs if a Tanium Client cannot establish an outgoing connection to a forward peer in its peer list: the client establishes its forward connection to Tanium Cloud the server instead and becomes a forward leader. Similarly, backward reflection occurs if a Tanium Client cannot establish an outgoing connection to a backward peer: the client establishes a backward connection to Tanium Cloud the server and becomes a backward leader.

LAN and WAN connections

Client peering results in a profound reduction in connections and bandwidth over WAN links. The following figure illustrates the proportions of the savings in a large enterprise network that has subnets in a data center, headquarters, and branch office, as well as VPN connections from remote workers. Other than during registration, only the remote VPN clients and leaders, depicted in bright red, connect to Tanium Cloud the server over the WAN (the internet, in this example). The remaining clients, depicted in darker red, share data over peer connections on the LAN for each subnet.

Figure  2:  Client peering in an enterprise network


Satellites are specific Tanium Clients that you designate to run certain targeted, secure workloads on behalf of the Module Server,Tanium Cloud, such as non-line-of-sight scans in Discover or remote authenticated scans in Comply.

Figure  3:  Tanium Client designated as a satellite

For example, suppose you have a lab network with unmanaged endpoints on a subnet separated from your main network, and you want to use Comply to perform scans on the lab endpoints. Also suppose you are using a managed endpoint with multiple network interface controllers (NICs) to bridge the lab subnet to the main network. You can designate that endpoint as a satellite and then configure Comply to use it to perform scans on the unmanaged endpoints.

Because the server Tanium Cloud might need to send sensitive, encrypted data (such as credentials) to a satellite when running a workload, you must verify each endpoint that you designate as a satellite to prevent spoofing attacks. Any such sensitive data is never sent using the linear chain, nor is it stored on-disk on the satellite.

Designating and using satellites requires Direct Connect version 2.1 or later.

For more information about managing satellites, see Tanium Direct Connect User Guide: Managing satellites.

File distribution

Tanium Cloud The Tanium Server distributes files (through a Zone Server, if one is deployed) to managed endpoints when you deploy actions that use those files. For example, if you deploy an action to upgrade Windows, Tanium Cloud the Tanium Server distributes a package that includes the Windows patch file. Tanium Clients running on the endpoints optimize the file distribution process through peering and caching.

File distribution among peers

Peering reduces the number of files that Tanium Cloud the Tanium Server distributes over WAN links. Instead of sending files to all managed endpoints, Tanium Cloud the Tanium Server sends files only to the backward leader of each linear chain. Each backward leader then relays the files over a high-speed LAN connection from one forward peer to another until they reach the forward leader.

Chunk caching

Caching enables clients to redistribute files in multiple small pieces known as chunks. Each client maintains an local cache of the file chunks that Tanium Cloud the Tanium Server previously distributed to the linear chain. When the same files are requested later (for example, when an action runs again), clients can use the cached chunks, instead of requesting that Tanium Cloud the Tanium Server redistribute the files again.


Tanium Cloud Tanium Core Platform supports Transport Layer Security (TLS) for encrypted communication in connections from Tanium Clients to Tanium Cloud the Tanium Server or Zone Server. Tanium Client 7.4 or later uses TLS communication by default between client peers. For details, see the Tanium Core Platform Deployment Reference Guide: Setting up TLS communication.