Study guide
2.1 Sensors: Execution Model, Output Structure and Data Types
Tanium Certified Operator TCO
Track your progress as you read
Finished sections get a check mark.
1 Tanium Certified Operator Exam and Platform Foundations
1.1 The Tanium Certified Operator Exam: Blueprint, Logistics and Certification Path 1.2 Tanium Platform Components, Client Registration and Linear Chain Peering
2 Asking Questions (22% of the TCO Blueprint)
2.1 Sensors: Execution Model, Output Structure and Data Types 2.2 Parameterized Sensors and Question Parameter Syntax 2.3 Issuing Questions in Interact: Ask a Question, Question Builder and Question Anatomy 2.4 Creating Saved Questions: Reissue Intervals, Merge and Drill-Down Flags, and RBAC 2.5 Defending Tanium as an Efficient User of Network Resources
3 Refining Questions (23% of the TCO Blueprint)
3.1 Targeting Endpoints: from and with Filters, Operators and Boolean Logic 3.2 Drilling Down into Question Results 3.3 Merging Questions to Add Columns 3.4 Computer Groups: Management versus Filter, Dynamic versus Manual 3.5 Custom Tags and Tag-Based Grouping
4 Taking Action (15% of the TCO Blueprint)
4.1 Packages: Anatomy, Command Syntax, Parameters and File Distribution 4.2 Deploying Actions: Entry Points, Targeting, Distribution and Approval 4.3 Verifying Endpoint State and Automating with Scheduled Recurring Actions
5 Navigation and Basic Module Functions (23% of the TCO Blueprint)
5.1 Console Layout, the Main Menu and Where Things Live 5.2 Operations Modules: Deploy, Patch, Asset, Performance and Provision 5.3 Security and Risk Modules: Threat Response, Comply, Enforce, Reveal, Discover and Integrity Monitor 5.4 Interpreting Module-Specific Historical Results and Tanium Data Service 5.5 Choosing the Right Area: Client Status, Direct Connect and Action History 5.6 Content Sets, Roles and Personas: Why You Can See What You Can See
6 Report Generation and Data Export (17% of the TCO Blueprint)
6.1 Exporting Question Results: CSV, Headers, Flatten Rows and Copy 6.2 Creating Reusable Reports with Tanium Reporting 6.3 Dashboards, Boards and Metric Sources: Trends, Its Replacement and Migration 6.4 Scheduled Delivery and Exporting to External Systems with Tanium Connect
2.1 Sensors: Execution Model, Output Structure and Data Types
Key Takeaways Explain This Topic AI
Sensors are read-only scripts that the Tanium Client runs locally on the endpoint, capturing standard output in memory rather than writing persistent files, and never modify system state.
Sensor scripts are cryptographically signed by Tanium and verified by the client before execution under LocalSystem on Windows or root on macOS, Linux and UNIX.
Sensors return single-column or multi-column output with an assigned data type (String, Version, Numeric, Date, IP Address, Hash) that determines which filter operators are available.
Max Sensor Age is set in the sensor configuration and applies to every question that uses the sensor, while Maximum Data Age is set on a sensor when you issue one question and applies only to that question.
Interact interprets a sensor error string such as TSE-Error as the value 0 when a numeric operator is used, so a 'less than' filter can wrongly match endpoints whose sensor failed.
Last updated: August 2026
2.1 Sensors: Execution Model, Output Structure and Data Types
Quick Summary: A Sensor is a lightweight, read-only script executed on-demand in local endpoint RAM by the Tanium Client. Sensors collect real-time endpoint state (such as running processes, registry values, or network connections) without writing persistent data to disk. All sensors must be cryptographically signed by the Tanium Server and verified by the Tanium Client before executing under privileged local accounts ( LocalSystem on Windows, root on macOS/Linux). Understanding sensor execution mechanics, output column schemas, data types, and the two caching controls ( Max Sensor Age and Maximum Data Age ) is essential for blueprint objectives AQ-1 and AQ-2, which ask you to query endpoints for real-time information and use basic Tanium features to gather relevant information.
1. What is a Tanium Sensor?
In the Tanium architecture, a Sensor is the fundamental telemetry gathering unit. When an operator asks a question in the Tanium Console, the Tanium Server broadcasts the request down through the linear peer-to-peer chains. Upon receiving the question, each Tanium Client determines whether it needs to execute the underlying sensor code to answer the query. +-----------------------------------------------------------------------------------+
- | TANIUM SENSOR PARADIGM |
- +-----------------------------------------------------------------------------------+
- | * Execution Location : Local Endpoint RAM (Volatile Memory) |
- | * Security Context : LocalSystem (Windows) / root (macOS/Linux/Unix) |
- | * Modification State : Strictly Read-Only (State Inspection Only) |
- | * Delivery Mechanism : Cryptographically Signed Code Distributed via Linear Chain|
- | * Output Model : Standard Output (stdout) Captured and Parsed into RAM |
- +-----------------------------------------------------------------------------------+
- Key Architectural Characteristics
Local RAM Execution: Sensors execute entirely on the target endpoint. The Tanium Client invokes the appropriate scripting interpreter (such as PowerShell, VBScript, POSIX Shell, or Python), captures the script's standard output ( stdout ), and buffers the result in memory. No temporary files or database writes are persisted to the endpoint storage during standard sensor execution.
Read-Only Philosophy: By strict design and security governance, sensors are strictly read-only. A sensor inspects, reads, queries, and reports system state—it does never modify system configurations, alter registry entries, delete files, or start/stop services. Modifying endpoint state is exclusively reserved for Packages and Actions .
Interpreter Support Across Platforms: Tanium provides cross-platform sensor support using native or embedded scripting engines:
Windows: PowerShell ( .ps1 ), VBScript ( .vbs ), Command Shell ( .bat / .cmd ), and Tanium-native C/C++ engine primitives.
Linux / UNIX (RHEL, Ubuntu, AIX, Solaris, SUSE): POSIX Shell ( sh / bash ), Python, and compiled binary utilities.
macOS: POSIX Shell ( zsh / bash ), Python, and AppleScript/native binaries.
2. Sensor Execution Security & Cryptographic Signature Verification
Because sensors execute with the highest local privileges on an endpoint— LocalSystem ( NT AUTHORITY\SYSTEM ) on Windows and root (UID 0) on POSIX platforms—rigorous execution security controls are enforced at every layer of the Tanium platform.
The Cryptographic Trust Chain
Every sensor script authored or imported into the Tanium Console is digitally signed by the Tanium Server using an internal private key. The Tanium Client installation includes a corresponding public key file ( tanium.pub ) placed in the client directory during deployment. [Tanium Server / Console]
- │
- │ 1. Sensor Script Authored / Imported
- ▼
- [Cryptographic Signing Engine] ──── Uses Private Key to generate digital signature
- │
- │ 2. Signed Sensor Payload Broadcast over Linear Chain (Port 17472)
- ▼
- [Tanium Client on Endpoint]
- │
- ├─► 3. Verifies Signature against local 'tanium.pub' public key
- │ ├── Signature Invalid / Tampered ──► REJECT Execution & Log Security Alert
- │ └── Signature Valid ───────────────► Proceed to Execution Step
- ▼
- [Privileged Execution in RAM]
- │ (Runs as LocalSystem / root)
- ▼
- [Standard Output Parsing & Response Token Generation]
- Security Guardrails
Signature Verification: When a client receives a sensor execution instruction, it validates the cryptographic signature against its local tanium.pub key before spawning any subprocess. If the signature is missing, invalid, or corrupted by in-flight tampering, execution is immediately halted, and an error is logged.
Tamper-Resistant Content: Sensor scripts stored on the Tanium Server cannot be modified in transit by intermediary network devices or malicious proxy nodes. Every peer in the linear chain inspects the payload signature independently.
Restricted Execution Context: The Tanium Client ensures sensor processes cannot be hijacked by lower-privileged interactive users logged into the operating system.
3. Core Built-In Sensors
Tanium ships with hundreds of pre-built, out-of-the-box sensors maintained in standard content sets (such as Default Content , Core Content , and Initial Content ). The table below outlines the core built-in sensors tested on the TCO exam:
Sensor Name Platform Output Description Sample Output
Computer Name Windows / Linux / macOS Returns the netbios name or FQDN of the endpoint. PROD-DB-01.corp.internal
IP Address Windows / Linux / macOS Returns all active IPv4/IPv6 addresses bound to network adapters. 10.10.40.155 , 192.168.1.50
Operating System Windows / Linux / macOS Returns the full operating system name, edition, and kernel/service pack build. Windows Server 2022 Datacenter
Running Processes Windows / Linux / macOS Returns a multi-column list of active processes, including process IDs, names, and paths. svchost.exe 1044 C:\Windows\System32\svchost.exe
Installed Applications Windows / Linux / macOS Queries registry hives (Windows) or package managers (RPM/dpkg) for installed software. Google Chrome 124.0.6367.60
Disk Free Space Windows / Linux / macOS Returns storage volume letters/mount points, total capacity, and free space. C: 120 GB Total, 45 GB Free (37%)
Tanium Client Version Windows / Linux / macOS Returns the current installed binary version of the local Tanium Client. 7.6.1.1252
- Uptime Windows / Linux / macOS Measures elapsed time since the operating system last booted. 14 days, 06:22:15
- CPU Utilization Windows / Linux / macOS Measures real-time processor load across all logical CPU cores. 18%
- 4. Single-Column vs. Multi-Column Sensor Outputs
Sensors are categorized by the structural format of the data they return to the Tanium Client and Server. +---------------------------------------------------------------------------------------+
- | SENSOR OUTPUT STRUCTURES |
- +---------------------------------------------------------------------------------------+
- | SINGLE-COLUMN SENSOR | MULTI-COLUMN SENSOR |
- | -------------------- | ------------------- |
- | * Returns 1 data element per record | * Returns delimited composite records |
- | * Direct scalar mapping | * Parsed into discrete named table columns|
- | * Example: `Computer Name` | * Example: `Running Processes` |
- | Output: "WIN-SRV-01" | Output: "explorer.exe | 4120 | C:\..." |
- | | |
- | SINGLE-ROW OUTPUT | MULTI-ROW OUTPUT |
- | ----------------- | ----------------- |
- | * Exactly 1 value per endpoint | * Multiple records per single endpoint |
- | * Example: `Tanium Client Version` | * Example: `Installed Applications` |
- | Node 1 -> "7.6.1.1252" | Node 1 -> ["Chrome", "Slack", "Excel"] |
- +---------------------------------------------------------------------------------------+
- Single-Column Sensors
A single-column sensor outputs a discrete scalar value. For example, the Operating System sensor returns a single text line per machine. When viewed in the Tanium Interact results grid, this creates a single column named Operating System .
Multi-Column Sensors
A multi-column sensor returns structured records containing multiple fields separated by an internal delimiter (typically a pipe | or tab character). Tanium's sensor parser automatically unpacks the output string into separate, individual columns in the results grid.
For example, the sensor Network IP Connections returns:
- Column 1: Protocol ( TCP / UDP )
- Column 2: Local IP ( 0.0.0.0 )
- Column 3: Local Port ( 443 )
- Column 4: Remote IP ( 198.51.100.24 )
- Column 5: Remote Port ( 51234 )
- Column 6: Process Name ( httpd.exe )
- Single-Row vs. Multi-Row (Multi-Valued) Outputs
Single-Row: The sensor returns at most one record per endpoint (e.g., Computer Name , Chassis Type , Primary Owner User ).
Multi-Row: The sensor returns dozens or hundreds of lines from a single endpoint (e.g., Running Processes , Installed Applications , Open Ports ). In the Tanium Console results grid, each unique value is counted and aggregated across the fleet, allowing operators to immediately spot outliers or widespread software versions.
5. Sensor Data Types and Operator Compatibility
When a sensor is authored, each output column is assigned an explicit Data Type . The assigned data type determines which comparison operators are available in the Question Bar, Question Builder, and Saved Question filters.
Data Type Description Available Filter Operators Real-World Example
String Alphanumeric text data (case-insensitive by default in Tanium). equals , does not equal , contains , does not contain , starts with , ends with , matches regex Operating System contains Server
Version Dot-delimited version strings evaluated using semantic version hierarchy. version equals , version is greater than , version is less than , version is at least Tanium Client Version < 7.6.0.0
Numeric (Integer / Real) Discrete numerical values evaluated arithmetically. equals , is greater than , is less than , is between , <= , >= Disk Free Space:Free Space (GB) < 15
Date / Time ISO timestamps or localized date/time values. is before , is after , is in the last , is between OS Install Date is before 30 days ago
IP Address IPv4 or IPv6 network addresses evaluated as octets/subnets. equals , is in range , is in subnet (CIDR) , contains IP Address is in subnet 10.10.0.0/16
Hash / Checksum Cryptographic digest strings (MD5, SHA-1, SHA-256). equals , does not equal , contains File MD5 Hash equals d41d8cd98f00b204e9800998ecf8427e
Important
Version vs. String Sorting on the Exam: If a version number is stored as a String , alphabetical sorting fails on multi-digit segments: "10.0.0" would be evaluated as less than "9.0.0" because '1' precedes '9' alphabetically. However, when typed as Version , Tanium evaluates the numerical value of each delimited token ( 10 > 9 ), ensuring accurate operational patch and build comparisons.
6. Result Caching: Max Sensor Age and Maximum Data Age
Re-running an expensive script on every question would be wasteful, so a Tanium Client may answer from a cached sensor result instead of executing the script again. Two settings control how old that cached result is allowed to be, and the TCO exam expects you to know which is which.
- Setting Where you set it Scope of effect
- Max Sensor Age In the sensor configuration Applies to every question that uses that sensor
- Maximum Data Age On a sensor when you issue a question Applies only to that question
Both control the maximum time for which Tanium Clients can use a cached result for a sensor instead of re-executing it for a fresh result. [Question arrives at the Tanium Client]
- |
- v
- [Is there a cached result for this sensor?]
- / \
- [YES] [NO]
- | |
- v |
- [Is the cached result younger than the applicable age limit?]
- / \ |
- [YES] [NO] |
- | | |
- v v v
- [Return the cached value] [Run the sensor script,
- cache the result, return it]
- Tuning guidance
Static attributes — serial number, BIOS version, chassis type, installed memory — rarely change, so a long age limit costs nothing and saves endpoint CPU.
Volatile attributes — running processes, CPU consumption, logged-in users — need a short limit or the answer is stale before you read it.
Do not lower the defaults for sensors used in saved questions that periodically reissue, in questions you use to deploy actions, or in questions that define membership in computer management groups and filter groups. Tanium calls this out explicitly as a best practice: a lower Max Sensor Age or Maximum Data Age increases CPU usage on endpoints , and those three uses re-run constantly.
Tip
If you need genuinely fresh data for one investigation without changing platform-wide behaviour, set Maximum Data Age on that question rather than editing the sensor's Max Sensor Age . Editing the sensor changes the behaviour of every saved question, computer group and scheduled action that uses it.
7. Runtime Safety Safeguards
Sensors run on production endpoints under privileged accounts, so the Tanium Client constrains them rather than trusting them. +---------------------------------------------------------------------------------------+
- | SENSOR EXECUTION SAFEGUARDS |
- +---------------------------------------------------------------------------------------+
- | 1. Execution timeout : the client terminates a sensor process that overruns |
- | 2. Resource throttling : background execution at lowered process priority |
- | 3. Interpreter isolation : subprocess spawning with a controlled environment |
- | 4. Error trapping : failures surface in the grid instead of hanging the client|
- +---------------------------------------------------------------------------------------+
- Sensor execution timeouts
The Tanium Client enforces an execution timeout on sensor scripts. A script that hangs on a blocked WMI call, waits on an unreachable network resource, or loops indefinitely is terminated rather than allowed to hold endpoint resources. The endpoint then returns an error string for that sensor instead of a value. The timeout is a client configuration setting rather than a fixed constant, so treat the behaviour as the exam-relevant fact: a slow sensor degrades into an error result, it does not stall the fleet.
Reading error results in the grid
Error strings are results too, and Interact will show them:
Result you see What it usually means
[no results] The endpoint answered but the sensor produced nothing applicable — for example a Windows-only sensor on Linux, or a question whose regular expression exceeded the client's processing limit
TSE-Error and similar error strings The sensor script failed on that endpoint. Note that if you filter with an operator that evaluates integers, Interact interprets an error string as the value 0 , which can make an error row satisfy a "less than" filter
Blank or missing endpoints The endpoint did not answer at all — offline, unreachable, or its client is not running
Important
The TSE-Error behaviour is a genuine exam trap. A filter such as installed application version[chrome] <= 12 will evaluate to true on an endpoint that returned an error, because the error string is interpreted as 0. Always sanity-check counts that look implausibly high after a numeric filter.