Ingest logs and data from Okta - Learn more about Ingesting logs and data from Okta for use in Cortex XSIAM. - Administrator Guide - Cortex XSIAM - Cortex

Ingest logs and data from Okta - Learn more about Ingesting logs and data from Okta for use in Cortex XSIAM. - Administrator Guide - Cortex XSIAM - Cortex - Security Operations

Cortex XSIAM 3.x Documentation

Product

Cortex XSIAM

Creation date

2025-07-15

Last date published

2026-06-04

Feature	Cloud Posture Security	Cloud Runtime Security	Cortex XDR Cloud	Cortex XSIAM NG SIEM, Cortex XSIAM Enterprise, and Cortex XSIAM Premium	Cortex XSIAM Enterprise Plus
Collect Logs	Enabled	Enabled with Data Collection add-on	Enabled with Data Collection add-on	Enabled	Enabled
Collect Configuration	Enabled	Enabled	Enabled with Cloud Posture Security or Cloud Runtime Security add-on	Enabled with Cloud Posture Security or Cloud Runtime Security add-on	Disabled

Prerequisite

Administrator privileges: Your Okta user must have a role capable of creating API tokens, such as Read-only Administrator, Super Administrator, or Organization Administrator. For more information, see the Okta Administrators Documentation.

To receive logs and configuration data from Okta, configure the Data Sources & Integrations settings in Cortex XSIAM. Once enabled, the system immediately begins ingesting activity logs and identity configuration metadata, according to your configuration settings.

Activity logs are searchable in the okta_sso_raw dataset and normalized to xdr_data or saas_audit_logs.

When enabled with a Cloud Posture Security or Cloud Runtime Security add-on, activity logs are also searchable using advanced Identity Security queries using Cortex Query Language (XQL). For more information, see Perform advanced Identity Security investigations using XQL.

Activity logs are also searchable using advanced Identity Security queries using Cortex Query Language (XQL). For more information, see Perform advanced Identity Security investigations using XQL.
Configuration data is used for Identity Security visibility and is searchable in Identity Security → Identity Asset Inventory and using the ciem_permissions_with_last_access dataset.

The same Okta domain, API token, and permissions are used for both log and configuration collection, as both features utilize the same Okta API.

Perform these steps in your Okta Admin Console to prepare for the connection.

Identify your Okta Domain:
1. From the Okta Dashboard, click the down arrow under your name in the top-right corner.
2. Copy the Org URL, such as https://example.okta.com, and save it for the Okta Domain field in Cortex XSIAM.
For more information, see the Okta Documentation.
Obtain your authentication token in Okta:
1. Select Security → API → Tokens, and click Create token.
2. Set the following parameters for the token:
  - What do you want your token to be named?: Specify the name for your token, which is used for tracking API calls.
  - API calls made with this token must originate from: Select Any IP.
3. Click Create token. You may need to login to Okta again using your MFA administrator credentials.
4. Your token is successfully created. Copy the Token Value and record it immediately. You will need this for the TOKEN field in Cortex XSIAM. Once you close the dialog box by clicking Ok, got it, you won't be able to access the token again and will have to create a new one if you didn't record it.

Select Settings → Data Sources & Integrations.
On the Data Sources & Integrations page, click + Add New, search for Okta, then hover over it and click Add.
Integrate the Okta authentication service with Cortex XSIAM:
1. Enter the Okta Domain (Org URL) and Token obtained in Step 1.
2. Collect Logs: Select this option to ingest activity logs.
3. (Optional) Define an Event Filter to configure collection for events of your choosing.
  - All events are collected by default unless you define an Okta API Filter expression, such as filter=eventType eq “user.session.start”.
  - For Okta information to be woven into authentication stories, “user.authentication.sso” events must be collected.
4. Collect Configuration: Select this option to provide deep visibility into identities and permissions, offering comprehensive insights into users, user groups, and applications. It specifically highlights the permissions granted to Okta users in cloud environments, centralizing group memberships to secure your identity landscape.
5. Test the connection.
6. Click Enable.

Data is routed differently depending on which collection option is enabled:

Activity Data (using Collect Logs)

XQL: Searchable using the okta_sso_raw dataset.
Normalization: Depending on the event type, data is normalized to either xdr_data or saas_audit_logs datasets.
Enabled with a Cloud Posture Security or Cloud Runtime Security add-on: Searchable using advanced Identity Security queries using Cortex Query Language (XQL). For more information, see Perform advanced Identity Security investigations using XQL.

Configuration data (using Collect Configuration)

Identity inventory: Access the data in the Identity Asset Inventory within the Cortex Cloud Identity Security module (Identity Security → Identity Asset Inventory).
XQL: Use the following dataset for CIEM (Cloud Infrastructure Entitlements Management) visibility: ciem_permissions_with_last_access