Okta eventType List: The Events Responders Need
The Okta System Log eventTypes that matter in an incident, grouped by attack stage, with the fields to read and the Classic vs Identity Engine differences.
TL;DR. Okta's catalog lists well over a thousand eventTypes; an identity investigation lives on about forty of them. Sign-ins (user.session.start, user.authentication.auth_via_mfa), push prompts (system.push.send_factor_verify_push, user.mfa.okta_verify.deny_push), factor changes (user.mfa.factor.reset_all, user.mfa.factor.activate), admin grants (user.account.privilege.grant), tokens (system.api_token.create), federation (system.idp.lifecycle.create, user.authentication.auth_via_IDP) and app access (user.authentication.sso). Read each with its outcome, client, securityContext and authenticationContext fields, never the eventType alone.
Every eventType below was checked against Okta's published event types catalog (also downloadable as CSV). Descriptions are my own summaries; the catalog remains the reference.
The fields you read on every event
An eventType tells you what happened. The rest of the LogEvent tells you whether it was the real user:
| Field | Why it matters |
|---|---|
published | UTC timestamp; your timeline's spine |
actor.alternateId, actor.type | who did it (a user, an API token's owner, the system) |
target[] | who or what it was done to: user, app, IdP, policy, authenticator |
outcome.result, outcome.reason | SUCCESS, FAILURE, ALLOW, DENY… and why |
client.ipAddress, client.userAgent.rawUserAgent | source and browser |
securityContext.asNumber, asOrg, isp, isProxy | network owner (ASN), proxy flag |
authenticationContext.externalSessionId | the session (externalSessionId) |
authenticationContext.rootSessionId | the root of an interactive session, survives factor changes |
debugContext.debugData | privilegeGranted, factor, behaviors, risk, threatSuspected, tunnels, requestUri |
transaction.id, uuid | group related events; cite the exact event |
A caution about debugData: it is diagnostic context, not a stable contract, and its keys vary between orgs and releases. Treat it as a strong hint, not as a schema.
On sessions, Okta Security notes that externalSessionId can change after factor lifecycle events, while rootSessionId follows the whole interactive session (Okta Security: rootSessionId). Pivot on both.
Sign-in and MFA
| eventType | What it records | Read with |
|---|---|---|
user.session.start | sign-in to Okta (success or failure) | outcome.reason, IP, ASN, user agent |
user.authentication.verify | user identity verification | outcome, IP |
user.authentication.auth_via_mfa | MFA verification | debugData.factor, outcome |
policy.evaluate_sign_on | sign-on policy evaluation | debugData.behaviors, risk |
system.push.send_factor_verify_push | an Okta Verify push was sent | count per user per minute |
user.mfa.okta_verify.deny_push | the user rejected a push (Classic Engine) | burst, then an accepted push |
user.mfa.okta_verify | Okta Verify verification | outcome |
user.mfa.attempt_bypass | attempt to bypass a factor | actor, IP |
user.account.lock | account locked after failures | preceding failures |
The catalog entry for user.mfa.okta_verify.deny_push notes that it is emitted by Classic Engine API flows; in Okta Identity Engine a rejected push shows up as user.authentication.auth_via_mfa with a failure outcome. A push-fatigue detection that only watches deny_push is blind on OIE orgs. More in MFA fatigue detection.
Factors and passwords
| eventType | What it records | Why responders care |
|---|---|---|
user.mfa.factor.reset_all | all factors of a user reset | the helpdesk social-engineering pivot |
user.mfa.factor.deactivate | one factor removed | same, when the actor is not the user |
user.mfa.factor.activate | a new factor enrolled | attacker's own device after a reset |
user.account.reset_password | password reset by an admin | actor ≠ target is the signal |
user.account.update_password | password changed | who changed it, from where |
device.enrollment.create | new Okta Verify device registered | new device right after a reset |
The sequence reset by someone else → new factor from a new network is covered in helpdesk social engineering and factor resets.
Sessions and threat signals
| eventType | What it records |
|---|---|
security.session.detect_client_roaming | Okta detected a roaming session |
user.session.context.change | the session's context changed enough to warrant policy re-evaluation |
policy.auth_reevaluate.fail | continuous access evaluation found a policy violation |
user.session.clear | an admin cleared a user's sessions |
user.session.end | sign-out |
security.threat.detected | request from an IP that ThreatInsight classed as malicious |
security.attack.start | ThreatInsight detected that the org is under attack |
security.breached_credential.detected | a credential associated with a known breach was used |
user.account.report_suspicious_activity_by_enduser | the user clicked "report suspicious activity" |
user.risk.detect, user.risk.change | user risk detected or changed |
See session hijacking detection and password spraying detection.
Administration and persistence
| eventType | What it records | Key detail |
|---|---|---|
user.session.access_admin_app | Admin Console opened | first admin access after a reset |
user.account.privilege.grant | admin privileges granted to a user | debugData.privilegeGranted |
group.privilege.grant | admin privileges granted to a group | then look at group membership |
user.account.privilege.revoke | all admin privileges revoked | cleanup, by whom |
system.api_token.create | new API token | carries its creator's rights |
system.api_token.revoke | token revoked | |
user.session.impersonation.grant / .initiate | support impersonation enabled / started | was it requested by your team? |
user.lifecycle.create | new user created | new account then admin grant |
policy.lifecycle.update, policy.rule.update | policy or rule changed | MFA removed from a rule? |
policy.lifecycle.deactivate, policy.rule.deactivate | policy or rule disabled | |
security.authenticator.lifecycle.deactivate | authenticator disabled org-wide | |
zone.update, security.threat.configuration.update | network zone or ThreatInsight changed | blocklist removed? |
Details in admin role and API token abuse.
Federation
| eventType | What it records |
|---|---|
system.idp.lifecycle.create / .activate | identity provider created / activated |
system.idp.lifecycle.update | identity provider changed |
system.idp.key.create | IdP signing key added |
system.idp.lifecycle.read_client_secret | IdP client secret read |
user.authentication.auth_via_IDP | user signed in through an external IdP |
user.authentication.auth_via_inbound_SAML | inbound SAML authentication |
Okta Security lists system.idp.lifecycle.create and user.authentication.auth_via_IDP among the events to monitor for cross-tenant impersonation (Okta Security).
Application access
| eventType | What it records |
|---|---|
user.authentication.sso | SSO into an application (target holds the app) |
app.oauth2.token.grant, app.oauth2.as.token.grant | OAuth token issued |
SSO tells you which application was opened, not what was done there; continue in that application's own logs.
How the analyzer uses these
The analyzer groups these eventTypes into categories for filtering (authentication, MFA, sessions, admin and IdP, policies and security, app access, users and accounts), and its 25 detection rules are written against them: thresholds (bursts of pushes or failures), sequences (a reset, then an enrollment), and follow-ups (SSO into a sensitive app after a high-severity finding). The rules are data, visible on the home page, so you can check exactly which eventTypes and fields each one reads.