Okta → Tanium Automated Software Deployment — Discovery & Implementation Plan

Goal & Target Architecture

End State

When a user is added to an Okta group for a specific software (e.g., Software-Zoom), the software is automatically deployed to that user's endpoint — no manual Tanium action needed.

Target Architecture

Okta Group Add

→

Okta Workflow

→ asset tag →

Middleware

→

Tanium API

→ custom tag →

Endpoint

Recommended Approach: Custom Tags

Why custom tags? Tanium's REST API can create manual computer groups but cannot add members to existing ones. Custom tags avoid this limitation entirely. You apply a tag to an endpoint, a filter-based computer group automatically includes anything with that tag, and a standing deployment targeting that group installs the software.

How It Works

User is added to Okta group Software-Zoom
Okta Workflow fires, looks up the user's asset tag from Okta profile
Workflow calls middleware inside your FedRAMP boundary
Middleware calls Tanium API:
1. Ask question: "Get Computer Name from machines where Asset Tag Number equals AST-00042"
2. Deploy action: Run a "Set Custom Tag" package on that endpoint to apply tag Deploy-Zoom
Tanium's filter-based computer group Deploy-Zoom-Group (filter: Custom Tags containing "Deploy-Zoom") automatically picks up the endpoint
The standing Tanium Deploy deployment targeting Deploy-Zoom-Group installs Zoom on the endpoint's next check-in

Key advantage: No group membership management via API. The filter-based group is self-maintaining. You only need to apply a string tag to an endpoint, which the API can do via a package/action.

API Research Findings

What the Tanium API Can Do

Operation	REST API	API Gateway (GraphQL)	Notes
Ask a question (query sensors)	Yes	Yes	Look up endpoint by asset tag
Deploy action to specific host	Yes	Yes	Run "set tag" package on endpoint
Deploy action to computer group	Yes	Yes	Alternative: deploy directly
Create manual computer group	Yes	Yes	Can create, but…
Add member to existing group	No	Unknown	This is the gap
Manage groups (general)	Limited	Documented as supported	Need to verify in your environment

API Methods (from Tanium v2 integration docs)

Command	What It Does	Key Parameters
`tn-ask-question`	Query sensor data across endpoints	`question-text`
`tn-create-action-by-host`	Run a package on a specific host	`package-id`, `hostname` or `ip-address`
`tn-create-action`	Run a package against a group	`package-id`, `target-group-id`
`tn-create-manual-group`	Create a new group by host list	`group-name`, `computer-names`

Sources: Cortex XSOAR Tanium v2 docs, Tanium Integration Methods, Splunk SOAR Tanium REST Connector

FedRAMP Considerations

Tanium Cloud for US Government (TC-USG) is FedRAMP Authorized
Features may lag behind commercial Tanium releases — the API Gateway may or may not be available yet
Some API endpoints are limited to either Cloud or On-Prem deployments
Okta Workflows runs outside your FedRAMP boundary — it cannot call Tanium directly

Source: Tanium FedRAMP Authorization announcement

0 Phase 0: Discovery — Answer These Before Building Anything

You are the Tanium admin, so you can look all of this up yourself. Here's exactly where to find each answer.

0.1 Is the API Gateway Available? Tanium Console

The API Gateway (GraphQL) is the preferred integration method and may support group membership updates that the REST API doesn't.

Log into the Tanium Console
Look in the left navigation for "Administration" → "API Gateway" or "API Tokens"
If API Gateway appears as a module, it's available
If you don't see it, check Administration → "Tanium Solutions" (or "Modules") — look for "API Gateway" in the list
If it shows as "Not Imported" or doesn't appear at all, you'll use the Platform REST API instead

Also check: Go to Administration → "API Tokens". If you can create API tokens here, the REST API is enabled. If this section doesn't exist, API access may need to be enabled by Tanium support.

Record: API Gateway available? Yes / No | REST API / API Tokens available? Yes / No

0.2 Does an Asset Tag Sensor Exist? Tanium Interact

You need a sensor in Tanium that returns the BIOS/SMBIOS asset tag for each endpoint. This is how you'll match Okta's asset tag to a Tanium endpoint.

Go to Interact (main question bar at the top of the console)
Type this question and press Enter:
Get Asset Tag Number from all machines
If you get results with actual asset tag values, the sensor exists and is working
If Tanium says "no results" or doesn't recognize the sensor, try these alternatives:
Get Chassis Asset Tag from all machines

Get BIOS Asset Tag from all machines
If none of these return data, you can also check Administration → "Content" → "Sensors" and search for "asset" to see what's available

If no asset tag sensor exists: You'll need to create a custom sensor that reads the BIOS asset tag. On Windows endpoints this is typically pulled from wmic systemenclosure get SMBIOSAssetTag or via PowerShell: (Get-WmiObject Win32_SystemEnclosure).SMBIOSAssetTag. On Linux: dmidecode -s chassis-asset-tag.

Record: Asset tag sensor name: _______________ | Returns valid data? Yes / No

0.3 Verify Custom Tags Are Working Tanium Console

You said custom tags are available. Confirm they work and find the exact package name used to set them.

Go to Interact and run:
Get Custom Tags from all machines
Verify you see results (even if most machines return "[no results]" — that's fine, it means the sensor exists)
Now find the package that sets custom tags: go to Administration → "Content" → "Packages"
Search for Custom Tag — look for packages like:
- Custom Tagging - Add Tags
- Set Custom Tag
- Apply Custom Tags
Click on the package and note:
- The exact package name
- The package ID (in the URL or details)
- The parameter name(s) it expects (usually something like $1 = tag value)

Quick test: Pick a test endpoint. In Interact, target that single machine and deploy the custom tag package with a test value like test-tag-delete-me. Then re-run Get Custom Tags from all machines filtered to that endpoint to confirm the tag was applied. Remove the test tag when done.

Record: Custom tag package name: _______________ | Package ID: _______________ | Parameter format: _______________

0.4 Network Path: Can Anything Reach Tanium's API? Network

Okta Workflows runs in Okta's cloud. Your Tanium server is inside the FedRAMP boundary. You need something inside the boundary that can:

Receive HTTPS requests from Okta (or poll for them)
Make API calls to the Tanium server

Find your Tanium server's API URL

Your Tanium console URL is probably something like https://tanium.yourcompany.com
The REST API base URL is the same host with /api/v2/ appended
If you have API Gateway, it may be at a different port or path — check Administration → "API Gateway" for the URL

Check what can reach it

From a server or VM inside your boundary, test connectivity:

# From a Linux server inside your FedRAMP boundary
curl -k https://tanium.yourcompany.com/api/v2/server_info

# From a Windows machine inside your boundary (PowerShell)
Invoke-RestMethod -Uri "https://tanium.yourcompany.com/api/v2/server_info" -SkipCertificateCheck

If you get a JSON response (even an auth error like 401/403), the network path works. If it times out, there's a firewall between you.

If Tanium's API isn't reachable from anything: You'll need a firewall rule opened from your middleware host to the Tanium server on the API port (usually 443). Talk to your network team.

Record: Tanium API URL: _______________ | Reachable from inside boundary? Yes / No | From which host? _______________

0.5 Test API Authentication Tanium Console

Create an API token and test that you can authenticate.

Go to Administration → "API Tokens"
Click "New API Token"
Set a description (e.g., Okta-Tanium Integration)
Set an expiration (start with 90 days for testing, shorten for production)
Assign it to a persona/user that has permissions to:
- Ask questions (read sensor data)
- Deploy actions/packages
- Manage computer groups (if using group approach)
Copy the token — you'll only see it once

Test the token from a machine that can reach the Tanium API:

# PowerShell test
$headers = @{ "session" = "YOUR_API_TOKEN" }
Invoke-RestMethod -Uri "https://tanium.yourcompany.com/api/v2/server_info" -Headers $headers

If you get a JSON response with server version info: API auth is working. You're ready for Phase 1.

Note on auth header: Tanium REST API uses session: TOKEN as the auth header — not Authorization: Bearer. This is a common mistake.

Record: API token created? Yes / No | Auth test passed? Yes / No

Discovery Results — Decision Matrix

After completing 0.1–0.5, use this table to determine your path:

If…	Then…
API Gateway available + supports group updates	You can use either custom tags or direct group management. Custom tags are still simpler.
REST API only (no API Gateway)	Use the custom tag approach (recommended — this guide)
No asset tag sensor	Create a custom sensor first (see 0.2 notes), or use Computer Name as the lookup key instead of asset tag
No network path to Tanium API	Work with network team to open a firewall rule, or investigate Tanium Connect as an alternative inbound path
Can't create API tokens	Your Tanium role may not have admin rights to the API — check with your Tanium platform admin

1 Phase 1: Tanium-Side Setup

Set up everything in Tanium first. By the end of this phase, you'll be able to manually apply a tag and have software deploy automatically.

1.1 Define Your Tag Naming Convention Planning

Each software package gets its own custom tag value. Pick a consistent prefix so filter-based groups can match them.

Okta Group	Custom Tag Value	Tanium Group Name
`Software-Zoom`	`Deploy-Zoom`	`Deploy-Zoom-Group`
`Software-Slack`	`Deploy-Slack`	`Deploy-Slack-Group`
`Software-Chrome`	`Deploy-Chrome`	`Deploy-Chrome-Group`
`Software-CrowdStrike`	`Deploy-CrowdStrike`	`Deploy-CrowdStrike-Group`

Why the Deploy- prefix? Makes it easy to distinguish deployment tags from other custom tags your org might use. Also lets you create one filter group with Custom Tags containing "Deploy-" for a dashboard of all auto-deployed software.

1.2 Create Filter-Based Computer Groups Tanium Console

These groups auto-populate based on the custom tag value. No manual membership management needed.

Go to Administration → "Computer Groups"
Click "New Computer Group"
Set the type to "Filter-Based"
Name: Deploy-Zoom-Group
Set the filter:
- Sensor: Custom Tags
- Operator: contains
- Value: Deploy-Zoom
Save the group
Repeat for each software package in your naming convention table

Make sure these groups are visible to Tanium Deploy. When you create the group, ensure it's assigned to the correct management rights / module visibility so that Deploy can target it. If the group doesn't appear as a target in Deploy, check Computer Groups → edit the group → "Management Rights" and enable it for Deploy.

1.3 Create / Verify Deploy Packages Tanium Deploy

Each software needs a Deploy package. These may already exist.

Go to Tanium Deploy → "Software Packages" (or "Packages")
Search for the software (e.g., "Zoom")
If a package exists, note the package name and version
If not, create one:
- Upload the installer (MSI/EXE)
- Set silent install flags (e.g., /S, /quiet, /qn)
- Test the package on a single endpoint first

1.4 Create Standing Deployments Tanium Deploy

A standing (ongoing) deployment continuously targets a computer group. Any endpoint that joins the group gets the software.

Go to Tanium Deploy → "Deployments"
Click "New Deployment"
Select the software package (e.g., Zoom)
Target: select Deploy-Zoom-Group
Schedule: set to "Ongoing" (not one-time)
Configure any deployment options (restart behavior, maintenance windows, etc.)
Save and activate the deployment

This is the key piece. Once this deployment is active, the entire automation chain reduces to: "apply the right custom tag to an endpoint, and the software installs itself." Everything else in this guide is about automating the tag application.

1.5 Manual End-to-End Test Tanium Console

Before building any automation, verify the tag → group → deploy chain works manually.

Pick a test endpoint that does NOT already have the software
In Interact, target that single machine
Deploy the Custom Tagging package with value Deploy-Zoom
Wait 5–10 minutes (endpoints check in periodically)
Verify:
- Run Get Custom Tags from all machines filtered to the test endpoint — should show Deploy-Zoom
- Check Deploy-Zoom-Group membership — test endpoint should appear
- Check the standing deployment status — should show the endpoint as "pending" or "in progress"
- Wait for deployment to complete — software should install

Do not proceed to Phase 2 until this works. If the manual chain fails, automating it will just automate failure. Common issues: group filter not matching, Deploy not targeting the group, package install failing silently.

2 Phase 2: API Proof of Concept

Now that the manual chain works, prove you can trigger it via API. All commands below are run from a machine inside your FedRAMP boundary that can reach the Tanium API.

2.1 Authenticate API

Use the API token you created in Phase 0.

          
          # PowerShell — set up variables for all subsequent API calls
$taniumUrl = "https://tanium.yourcompany.com"
$headers = @{ "session" = "YOUR_API_TOKEN" }

# Test authentication
Invoke-RestMethod -Uri "$taniumUrl/api/v2/server_info" -Headers $headers
        

2.2 Query Endpoint by Asset Tag API

Ask Tanium: "What is the computer name of the machine with asset tag X?"

          
          # Ask Tanium a question via API
$question = @{
    query_text = "Get Computer Name from all machines with Asset Tag Number equals AST-00042"
} | ConvertTo-Json

$result = Invoke-RestMethod -Uri "$taniumUrl/api/v2/questions" `
    -Method POST -Headers $headers `
    -ContentType "application/json" -Body $question

# The response includes a question ID — save it
$questionId = $result.data.id
Write-Host "Question ID: $questionId"

# Wait a few seconds for results, then fetch them
Start-Sleep -Seconds 15
$answers = Invoke-RestMethod -Uri "$taniumUrl/api/v2/result_data/question/$questionId" -Headers $headers

# Parse the computer name from results
$answers.data.result_sets[0].rows | ForEach-Object {
    Write-Host "Computer: $($_.data[0].text)"
}
        

Adjust the sensor name. Replace Asset Tag Number with whatever sensor name you found in Discovery step 0.2. The exact sensor name must match what Tanium expects.

2.3 Apply Custom Tag via API API

Deploy the "Set Custom Tag" package to the target endpoint.

# Deploy a package to a specific host
# Replace PACKAGE_ID with the custom tag package ID from Discovery 0.3
# Replace COMPUTER_NAME with the result from step 2.2

$action = @{
    package_spec = @{
        source_id = PACKAGE_ID
        parameters = @(
            @{ key = "`$1"; value = "Deploy-Zoom" }
        )
    }
    action_group = @{ id = 1 }
    target_group = @{
        and_flag = $true
        filters = @(
            @{
                sensor = @{ source_hash_or_name = "Computer Name" }
                operator = "Equal"
                value_type = "String"
                value = "COMPUTER_NAME"
            }
        )
    }
} | ConvertTo-Json -Depth 10

$deployResult = Invoke-RestMethod -Uri "$taniumUrl/api/v2/actions" `
    -Method POST -Headers $headers `
    -ContentType "application/json" -Body $action

Write-Host "Action ID: $($deployResult.data.id)"

The parameter key format varies. Some Tanium packages use $1, others use named parameters. Check the package details in Phase 0 step 0.3 to confirm the correct parameter format.

2.4 Verify the Full Chain Tanium Console

Wait 5–10 minutes after the API action
In Interact, verify the custom tag was applied: Get Custom Tags from all machines with Computer Name equals COMPUTER_NAME
Check the filter-based computer group — endpoint should now be a member
Check the standing deployment — software should be deploying/deployed

If this works: You've proven the entire chain via API. The remaining phases are about connecting Okta to this process.

3 Phase 3: Middleware (Bridge Okta to Tanium)

Okta Workflows can't reach Tanium directly. You need a relay service inside your FedRAMP boundary.

3.1 Architecture Options Network

Option	How It Works	Pros	Cons
A: Okta Workflows → API endpoint inside boundary	Expose a small HTTPS endpoint (Azure Function, AWS Lambda in GovCloud, or VM with a web server) that Okta can call	Real-time, simple Okta Workflow design	Requires inbound HTTPS from Okta's IP ranges through your firewall
B: Okta Workflows → shared queue → poller inside boundary	Okta writes to a queue/table (SQS, Azure Queue, even a simple database). A service inside your boundary polls the queue and calls Tanium.	No inbound firewall rules needed (poller initiates outbound)	Slight delay (polling interval), more components
C: Okta Workflows → Okta API endpoint → Tanium Connect polls Okta	Okta Workflow writes to an Okta Workflows table. Tanium Connect is configured to poll that table via Okta's API.	Uses Tanium's built-in Connect module, minimal new infrastructure	Connect may not support this pattern in FedRAMP; polling delay

Recommendation: Start with Option B if you have AWS GovCloud or Azure Government. No inbound firewall rules, and the poller is a simple script. If you already have a VM inside the boundary (like the server you use for cert work), you can run the poller there.

3.2 Build the Relay Implementation

The relay's job is simple. It receives a message with:

          {
  "asset_tag": "AST-00042",
  "software_tag": "Deploy-Zoom"
}
        

And then:

Queries Tanium API for the computer name matching that asset tag (step 2.2)
Deploys the custom tag package to that computer (step 2.3)
Logs the result

This phase requires development work. The exact implementation depends on your infrastructure (Lambda, Azure Function, cron script on a VM, etc.). The API calls from Phase 2 are the core logic — the relay just wraps them in a service.

4 Phase 4: Okta Workflow

Build the Okta Workflow that triggers the whole chain.

4.1 Build the Workflow Okta Workflows

Trigger: `User Added to Group`

Outputs: user.profile.email, user.profile.assetTag (custom attribute), target.displayName (group name)

Card-by-Card

Card 1: Branching — Is this a software deployment group?
- Condition: target.displayName starts with "Software-"
- False: End flow (not all group adds should trigger deployment)
Card 2: Text > Replace — Convert group name to tag name
- Replace "Software-" with "Deploy-"
- Example: Software-Zoom → Deploy-Zoom
Card 3: Read User — Get asset tag from Okta profile
- Read user.profile.assetTag (or whatever custom attribute stores the asset tag)
Card 4: Branching — Does user have an asset tag?
- If empty: Log error "No asset tag for user" and end
Card 5: HTTP > Raw Request — Call middleware
- Method: POST
- URL: Your middleware endpoint
- Body: { "asset_tag": "{{card3.assetTag}}", "software_tag": "{{card2.output}}" }
- Auth: API key or shared secret (stored in Okta Workflows connection)
Card 6: Check response & log result

4.2 End-to-End Test Okta

Pick a test user in Okta who has an asset tag in their profile
Pick a test endpoint that matches that asset tag and does NOT have the test software
Add the user to Software-Zoom group in Okta
Watch Okta Workflow execution history for the flow to fire
Check middleware logs for the API call
In Tanium, verify:
- Custom tag Deploy-Zoom was applied to the endpoint
- Endpoint appeared in Deploy-Zoom-Group
- Software deployed successfully

If this works: You have fully automated software deployment from Okta group membership. To add a new software, just create the Deploy package, the filter group, the standing deployment, and the Okta group. The workflow handles the rest.

Alternative Approaches

Alt A: Direct Deploy via API (skip tags/groups entirely) ▶

Instead of applying a tag and relying on a standing deployment, have the middleware directly deploy the software package to the endpoint via tn-create-action-by-host.

Pro: Simpler — no groups, no standing deployments, no tags
Con: No visibility in Tanium Deploy dashboard; harder to track what was deployed where and why; no automatic re-deployment if the software is uninstalled
Con: Each API call deploys immediately — no maintenance window enforcement

Alt B: Recreate manual group each time (REST API workaround) ▶

Since the REST API can't add members to existing groups, you could: query current group members → delete old group → create new group with old members + new endpoint.

Pro: Uses native manual groups
Con: Race condition risk if two deployments happen simultaneously
Con: Brief window where the group doesn't exist (standing deployment may misbehave)
Con: Fragile — if the delete succeeds but the create fails, you've lost your group

Verdict: Not recommended. Custom tags are cleaner.

Alt C: Wait for API Gateway group management ▶

The Tanium API Gateway (GraphQL) documentation states it supports "managing groups." If it supports adding members to existing groups, this would be the cleanest path.

Action: If API Gateway is available in your FedRAMP environment (check in Phase 0), explore the GraphQL schema for group mutation operations
If it works: You could skip custom tags and directly manage manual group membership
If it doesn't: Fall back to the custom tag approach

Master Checklist

Click each item as you complete it. Progress is saved in your browser.

Phase 0: Discovery

Check if API Gateway module is available in Tanium console
Check if API Tokens section exists (REST API enabled)
Run Get Asset Tag Number from all machines in Interact — verify sensor exists and returns data
Run Get Custom Tags from all machines — verify sensor exists
Find the custom tag package name and ID in Administration → Packages
Test applying a custom tag manually to one endpoint
Identify Tanium API URL and verify network connectivity from inside boundary
Create API token with appropriate permissions
Test API authentication with server_info endpoint

Phase 1: Tanium Setup

Define tag naming convention (e.g., Deploy-<AppName>)
Create filter-based computer groups for each software
Verify Deploy packages exist for target software
Create standing (ongoing) deployments targeting the filter groups
Manual test: Apply tag to test endpoint → joins group → software deploys

Phase 2: API Proof of Concept

Authenticate to Tanium API via PowerShell
Query endpoint by asset tag via API — get computer name back
Apply custom tag to endpoint via API action
API test: Tag applied → joins group → software deploys

Phase 3: Middleware

Choose middleware architecture (endpoint, queue+poller, or Connect)
Build and deploy the relay service
Test middleware: send test payload → tag gets applied in Tanium

Phase 4: Okta Workflow

Create Okta groups with Software- naming convention
Ensure asset tag is populated in Okta user profiles
Build the Okta Workflow (trigger + lookup + middleware call)
End-to-end test: Add user to Okta group → software deploys to endpoint
Test error cases: no asset tag, invalid asset tag, endpoint offline

Okta → Tanium Deploy / Automated Software Deployment

Okta Group → Tanium Automated Software Deployment

Goal & Target Architecture

End State

Recommended Approach: Custom Tags

How It Works

API Research Findings

What the Tanium API Can Do

API Methods (from Tanium v2 integration docs)

FedRAMP Considerations

0 Phase 0: Discovery — Answer These Before Building Anything

0.1 Is the API Gateway Available? Tanium Console

0.2 Does an Asset Tag Sensor Exist? Tanium Interact

0.3 Verify Custom Tags Are Working Tanium Console

0.4 Network Path: Can Anything Reach Tanium's API? Network

Find your Tanium server's API URL

Check what can reach it

0.5 Test API Authentication Tanium Console

Discovery Results — Decision Matrix

1 Phase 1: Tanium-Side Setup

1.1 Define Your Tag Naming Convention Planning

1.2 Create Filter-Based Computer Groups Tanium Console

1.3 Create / Verify Deploy Packages Tanium Deploy

1.4 Create Standing Deployments Tanium Deploy

1.5 Manual End-to-End Test Tanium Console

2 Phase 2: API Proof of Concept

2.1 Authenticate API

2.2 Query Endpoint by Asset Tag API

2.3 Apply Custom Tag via API API

2.4 Verify the Full Chain Tanium Console

3 Phase 3: Middleware (Bridge Okta to Tanium)

3.1 Architecture Options Network

3.2 Build the Relay Implementation

4 Phase 4: Okta Workflow

4.1 Build the Workflow Okta Workflows

Trigger: User Added to Group

Card-by-Card

4.2 End-to-End Test Okta

Alternative Approaches

Master Checklist

Phase 0: Discovery

Phase 1: Tanium Setup

Phase 2: API Proof of Concept

Phase 3: Middleware

Phase 4: Okta Workflow

Trigger: `User Added to Group`