Okta System Log Detection Guide: Event Types, Collection and SOC Detections

When an attacker gets into an Okta tenant they inherit every application behind it, and the Okta System Log is usually the only place the takeover is visible before it spreads. The log records sign-ins, factor changes, admin actions, policy edits, API token use and OAuth activity in one schema, but it keeps only 90 days, streams on a best-effort basis, and needs detection logic that understands Okta's own fields. This guide explains the LogEvent structure, how to collect the log without gaps, which event types matter, and how to build and test detections for help desk takeovers, session theft, rogue identity providers and abused API tokens. It is for detection engineers and identity security teams. Configuration hardening is covered in the Okta Security Hardening Guide; this page goes deeper on the log itself.

Key takeaways

• Collect continuously or lose it. The System Log API returns nothing older than 90 days, and log streams are at-least-once with no replay, so a SIEM copy with gap monitoring is mandatory.
• Use polling requests for ingestion. Polling (no until, ascending order) follows persistence time and never skips late events; bounded queries can miss delayed records.
• Build on fields, not display messages. eventType, outcome.result, securityContext.isProxy, client.ipAddress, authenticationContext.externalSessionId and target[].type carry the detection logic.
• Admin and factor changes are the high-value events. MFA resets, privilege grants, new identity providers and policy edits are rare, high-signal and were central to the 2023 Super Admin takeovers.
• Treat API tokens and OAuth service apps as identities. system.api_token.create and token use outside allowed network zones are as important as human sign-ins.

The LogEvent schema in practice

Every System Log record is a LogEvent object. The fields below are the ones detection logic depends on; all come from Okta's management API specification.

Okta publishes a catalogue of more than 1,200 event types, tagged where they are Identity Engine only, eligible for event hooks, or carry a changeDetails object showing before and after values. Event types that include changeDetails, such as policy.lifecycle.update, are the most useful for configuration drift detections because they show exactly what changed.

Collecting the log without gaps

1. Create a dedicated collector identity: prefer an OAuth 2.0 service app with only the okta.logs.read scope and a private key credential over an SSWS API token, which inherits the full permissions of the admin who created it. See the SaaS API Token Security Guide.
2. Poll, do not page by time: Okta warns that manually stepping since and until windows can skip or duplicate events. Persist the last next link and resume from it after restarts.
3. Deduplicate on uuid (the stream's event ID) and order on published, because both streams and polling can deliver out of order.
4. Monitor the pipe: alert on system.log_stream.lifecycle.deactivate, on collector HTTP 429 errors, and on any gap of more than 15 minutes in a normally busy tenant.
5. Run both where practical: a stream for latency and a polling collector as the system of record means a deactivated stream does not lose data, since the stream cannot replay.
6. Keep at least a year in the SIEM: many identity investigations start months after initial access, long after Okta's 90 days.

Query syntax matters for both collection and hunting. The filter parameter takes SCIM-style expressions (for example eventType eq "user.mfa.factor.reset_all" or eventType sw "system.idp.lifecycle"), q takes up to 10 keywords of 40 characters each, limit runs from 0 to 1,000, and an individual query times out after 30 seconds. Okta hashes the clientSecret value in the log, so log content is not a secret store, but treat exported logs as sensitive personal data all the same.

Event types that matter

Detections to build

Help desk and factor takeover

• Reset then sign in from somewhere new: user.mfa.factor.reset_all or user.mfa.factor.deactivate on an account, followed within a few hours by user.mfa.factor.activate and a user.session.start from an IP, ASN or device not seen for that user in 30 days. Weight it heavily when the target holds an admin role. This is the pattern in the help desk campaigns; see the Help Desk Social Engineering Incident Playbook and the MGM Resorts breach.
• Push fatigue: several user.mfa.okta_verify.deny_push events or failed user.authentication.auth_via_mfa results for one user in a short window, then a success. See the MFA Fatigue and Bypass Guide.
• Phishing-resistant factor declined a phish: user.authentication.auth_via_mfa with outcome FAILURE and the FastPass phishing reason means someone is running an adversary-in-the-middle page against that user. The credential is likely compromised even though the sign-in failed. See the AiTM Phishing Guide.

Privilege and configuration

• Any admin grant outside change control: user.account.privilege.grant, group.privilege.grant and app.oauth2.client.privilege.grant, enriched with the actor's session age and IP history. Super Administrator grants should page someone.
• Policy weakening: policy.rule.update or policy.lifecycle.update where changeDetails shows a factor requirement removed, a network zone widened, or session lifetime increased; policy.rule.deactivate on any sign-on or MFA rule.
• New identity provider: any system.idp.lifecycle.create or update, and any user.authentication.auth_via_IDP if you do not use inbound federation. Okta's 2023 advisory describes attackers adding a second, attacker-controlled IdP and changing the username mapping to sign in as real users.

Session theft and access patterns

• Proxy and hosting sign-ins: user.session.start or user.session.access_admin_app where securityContext.isProxy is true or the ASN belongs to a hosting provider, for any administrator.
• Session reused from a new network: group events by authenticationContext.externalSessionId and alert when one session shows two client IPs in different ASNs or countries in a short period, alongside Okta's own security.session.detect_client_roaming. The Okta support system breach was spotted when a customer saw an admin sign-in attempt using a session cookie stolen from a support file. See the Session Hijacking and Cookie Theft Guide.
• Password spraying: many user.session.start failures from one IP or ASN across many users, plus security.threat.detected and security.attack.start from ThreatInsight.

Non-human identities

• New SSWS token: system.api_token.create creates an unscoped token carrying its creator's admin rights. Alert on every creation by a human admin, and on creations by accounts with recent factor resets.
• Token used from outside its zone: system.api_token.request_outside_allowed_range means a token with a network restriction was used from elsewhere, which is either a leak or a broken integration; both need action.
• Token or service app behaving differently: profile actor.type of API token and OAuth client actors by event type and source IP; alert on a token that suddenly lists users or groups at volume, or calls admin APIs it has never called. ATT&CK v20 maps cloud account discovery (T1087.004) to this log source.

The NHI side of identity providers is discussed further in the ITDR Guide.

Mapping detections to ATT&CK and frameworks

In control frameworks the System Log supports NIST CSF 2.0 PR.PS-04 (log records generated and available), DE.CM-03 (monitoring personnel activity), DE.AE-02 and DE.AE-03 (analysis and correlation); NIST SP 800-53 Rev. 5 AU-2, AU-6, AU-11, AU-12 and SI-4, with AC-2 for account lifecycle monitoring; CIS Controls v8.1 Control 8 Audit Log Management; and ISO/IEC 27001:2022 Annex A 8.15 Logging and 8.16 Monitoring activities.

Rolling out and testing detections

1. Baseline first (weeks 1 to 2): ingest 90 days of history with a bounded backfill, then switch to polling. Build per-user and per-token baselines of IP, ASN, country, device and event types.
2. Deploy high-signal rules in alert mode (weeks 2 to 4): privilege grants, identity provider changes, policy rule changes, API token creation and log stream deactivation. These are rare enough to alert on directly.
3. Tune behavioural rules in shadow mode (weeks 4 to 8): reset-then-new-sign-in, session roaming and proxy sign-ins run silently, with results reviewed weekly before alerts go to the SOC.
4. Test with a preview tenant or test accounts: trigger each event deliberately (reset a test user's factors, create and revoke a test API token, add and remove a test IdP) and measure time to alert.
5. Roll back safely: keep rules in version control so a noisy rule can be returned to shadow mode without losing its logic, and never disable a configuration-change rule without a replacement.

Decision guidance: small organisations with one Okta tenant and few admins can alert on every admin, policy and IdP event and review them by hand. Large organisations with many admins, automation and Okta Workflows need allowlists by actor and change ticket, and benefit from Identity Threat Protection signals (user.risk.detect, policy.auth_reevaluate.fail) as inputs rather than as the only detection. Choose log streaming when you run Splunk Cloud or an AWS event pipeline and want low latency; choose polling when you need a reliable system of record or a different SIEM. Many teams need both.

Metrics:

• Ingestion lag from published to SIEM, by hour (target under 10 minutes).
• Gaps detected per month in the Okta feed (target zero unexplained).
• Share of admin, policy and identity provider changes matched to a change ticket.
• Number of SSWS API tokens and their age, with the share replaced by scoped OAuth service apps.
• Time from a test factor reset to SOC alert in the quarterly exercise.

Common failure patterns

• Relying on Okta's 90 days: the investigation starts in month four and the initial access has aged out. Always hold your own copy.
• A deactivated stream nobody noticed: after two failed retries the stream stops, and because streams cannot replay, the gap is permanent unless a polling collector filled it.
• Collector on an admin's SSWS token: the token carries that admin's full rights, breaks when the admin leaves, and is itself an attractive target.
• Rules on displayMessage or target[0]: display text and target positions vary by event type; rules silently stop matching.
• Treating ThreatInsight as the detection programme: Okta's signals catch spraying and known-bad IPs, not a convincing help desk call followed by a factor reset from a residential proxy.
• No correlation with the apps: the Okta session is the start of the story. Pivot on user and IP into the downstream application logs, for example the Microsoft 365 Unified Audit Log Guide for Detection.

Lessons from incidents

• Super Admin takeovers in 2023: Okta's cross-tenant impersonation advisory (31 August 2023, updated March 2024) describes help desk resets of Super Admin factors, sign-ins through anonymising proxies, privilege grants, removal of MFA from policies and a second IdP for impersonation. Each step produced a System Log event listed on this page; the gap was alerting, not logging.
• Stolen support session tokens: in the Okta support system breach a customer's own monitoring of admin sign-ins caught the stolen-cookie attempt, which is why session-to-network correlation for administrators is worth building even with phishing-resistant MFA in place.

Practitioner checklist

• Ingest the System Log with a polling collector using an OAuth service app scoped to okta.logs.read.
• Deduplicate on uuid, order on published, and alert on feed gaps and system.log_stream.lifecycle.deactivate.
• Retain at least 12 months of Okta events in the SIEM.
• Alert on every admin privilege grant, identity provider change, policy rule change and API token creation.
• Correlate factor resets with subsequent sign-ins from new IPs, ASNs or devices, prioritising administrators.
• Track sessions by externalSessionId and alert on network changes within a session.
• Profile API token and OAuth client actors and alert on new APIs, volumes or source networks.
• Test each rule quarterly with deliberate events from test accounts and record time to alert.
• Replace remaining SSWS tokens with scoped OAuth service apps and track the count down.

Standards and references

• Okta: Management API OpenAPI specification (System Log, LogEvent)
• Okta Developer: System Log query
• Okta Developer: Event types catalogue
• Okta Help: About log streaming
• Okta Security: Cross-Tenant Impersonation, Prevention and Detection
• MITRE ATT&CK: Conditional Access Policies
• MITRE ATT&CK: Multi-Factor Authentication Request Generation

Related NHI Mgmt Group resources: Okta Security Hardening Guide · Identity Provider Tenant Compromise Playbook · ITDR Guide · Scattered Spider Threat Actor Profile · Detection Engineering Guide