Prove Okta is working — first tool + proof field

1. Why “is Okta working?” is four questions

Operators collapse four failures into one sentence. The browser never reached the Okta org. The factor failed. FastPass saw an unmanaged device. The app sign-in rule denied after a perfect password. Those are four first clicks.

This page is the night-shift desk for proof. The session factory taught the five stamps — status, assignment, policy / risk, zone, factor. Here you learn the four official surfaces you actually open, in order, when someone asks you to prove Okta is working or explain why they cannot sign in.

Hero · four tiles, one ticket

2. Mental model — four proof tools

Memorise four named objects before you click. Each tool is allowed to prove one thing. Over-claiming a field is how you disable a high-risk rule at 02:00.

3. Decision flow — ticket → first tool

Flowchart first. Do not open Security → Authentication Policies until a diamond says so.

Path · pick the branch before the menu

4. How to choose — first tool + proof field

Print this next to Admin Console. If you cannot recite the proof field, you are not ready to change anything.

5. Runbook Side A → B → C

Side A proves the hit and the five System Log fields. Side B proves the factor and the policy evaluation. Side C proves the device / FastPass posture and the app sign-in rule you would change. On a messy Sev-2, do them in this order until a field lights up.

Side A — System Log first (the hit)

1. Open Reports → System Log, not Directory

   Official: Reports → System Log (System Log; System Log filters and search). Default window is the last seven days — set From / To / Time Zone to the ticket UTC. Search the actor (username). People → Status = ACTIVE does not prove a sign-in occurred.

2. Expand the row — five fields, always

   Click the right arrow. Official Help: the expansion shows actor, client, event, request, and target. From those surfaces copy: eventType, outcome.result, actor, client.ipAddress (hover the IP in Client to filter), and debugContext (DebugContext / DebugData).

3. If the log is empty for that actor + window, stop

   Empty is a result. The browser never presented this org. Check the Okta URL, DNS, a stale bookmark to another cell, or a wrong time zone on the filter. There is no policy.evaluate_sign_on to edit.

4. Glue the attempt

   Copy transaction.id. Official query: transaction.id eq "<TRANSACTION_ID>". That pulls MFA, policy evaluation, ThreatInsight, and session-start rows for the same click. Source: System Log events for Okta ThreatInsight.

Path:     Reports → System Log
Window:   ticket From / To / Time Zone  (default is last 7 days)

# This actor, this hour
actor.alternateId eq "priya@lab.example"

# MFA result
eventType eq "user.authentication.auth_via_mfa"

# Policy / rule that matched
eventType eq "policy.evaluate_sign_on"

# SSO assertion to the app
eventType eq "user.authentication.sso"

# Same click
transaction.id eq "<TRANSACTION_ID>"

# Risk / ThreatInsight
debugContext.debugData.risk co "level=HIGH"
debugContext.debugData.threatSuspected eq "true"
eventType eq "security.threat.detected"

Side B — Authentication / MFA + policy evaluation

1. Read the official trio for auth issues

   Okta Help (Global session policy evaluation) lists three System Log events to identify and resolve authentication issues: policy.evaluate_sign_on, user.authentication.auth_via_mfa, and user.session.start. Search all three on the same transaction.id.

2. MFA row — user.authentication.auth_via_mfa

   Official Help: this event can carry Allow, Deny, and Challenge (Challenge = additional authentication required). It can include the app the user accessed and the policy rule that matched. The sign-on policy may be evaluated more than once in one sequence. Device-health Help also lists USER_AUTHENTICATION_AUTH_VIA_MFA on FastPass sign-in. Chrome Device Trust Help: this event appears only if the app sign-in policy requires MFA.

3. Session start — user.session.start

   Official: status of the first authenticator verification that establishes an identity-provider session. Incorrect authenticator → VERIFICATION_ERROR. It logs user ID, session start time, and the method used. It does not mean an access token was granted. ThreatInsight’s ThreatSuspected field also appears on this event.

4. Policy row — policy.evaluate_sign_on

   Official Help (and Classic Engine release notes on help.okta.com): triggered when the Okta sign-on policy and/or app sign-on policy are evaluated. Behavior Detection Help: open DebugContext / DebugData on user.session.start and policy.evaluate_sign_on for behavior key=value pairs (POSITIVE / NEGATIVE / UNKNOWN / BAD_REQUEST). Quote Allow, Deny, or Challenge plus the rule name.

5. SSO row — only after the broker allowed

   Official common filter: eventType eq "user.authentication.sso" (Application Access / Sign-in Success). No SSO row + healthy actor usually means assignment or they never launched the app — not a factor bug.

Side C — FastPass / Device Trust + the rule you would change

1. Read device health on the FastPass events

   Official (Device health attributes in System Log events): when users sign in with Okta FastPass, these events carry device health — POLICY_EVALUATE_SIGN_ON, USER_AUTHENTICATION_VERIFY, USER_AUTHENTICATION_AUTH_VIA_MFA, USER_SESSION_START. The Device object shows Disk Encryption Type, Jailbreak, Screen Lock Type, Secure Hardware Present. Use that against the device assurance policy — do not guess from a phone photo of Okta Verify.

2. Know FastPass vs legacy Device Trust events

   FastPass is the phishing-resistant, passwordless authenticator in Okta Verify (Android, iOS, macOS, Windows; managed and unmanaged). Official Device Trust verification events (replace Desktop Device Trust with FastPass): user.authentication.authenticate (device through a certificate), user.credential.enroll, pki.cert.issue, pki.cert.revoke. If you still see only the certificate events, the org may not have finished the FastPass cutover.

3. Open the app sign-in rule only after you can name it

   Path: Security → Authentication Policies → App sign-in → the policy → Rules → the rule System Log named. Official IF conditions include Device state (Registered), Device management, Device assurance policy, Device platform, User’s IP (network zones), and Risk. THEN Access is Denied or Allowed after successful authentication. Possession constraints include Phishing-resistant (FastPass / passkeys) and Hardware protection.

4. Zone and risk live on the same attempt

   Risk scoring Help: open DebugContext / DebugData. Example: MEDIUM because reasons=Anomalous Device, with ThreatSuspected=false. Queries: debugContext.debugData.risk co "level=HIGH" (also MEDIUM / LOW). A new office NAT that is not in Security → Networks looks high-risk. Adding the CIDR is change-control. Source: Risk scoring; Add IPs to a network zone from the System Log.

6. Five tickets as full stories

These five land every quarter. Memorise first tool + proof field. Times and identities below are lab-only. RFC 5737 addresses only.

Journey · one named deny is the ticket

OEVD-01 — Prove they hit Okta (System Log)

01:42 · P2. Priya on a hotel network. Slack already says outage. L1 drafted a new app sign-in Allow and a password reset.

First tool: Reports → System Log. Filter actor priya@lab.example, last 30 minutes, the ticket time zone.

If empty: she never reached this org. Quote “no System Log row for actor + window.” Next check is the Okta URL, a bookmark to another preview / cell, split DNS, or a captive portal — not Access is Denied.

If a row exists: copy eventType, outcome.result, actor, client.ipAddress, debugContext. You are now allowed to open the MFA and policy events on that transaction.id. Existence of a row is not an Allow.

OEVD-02 — Prove the factor (auth_via_mfa)

02:05 · P2. Password is accepted. Okta Verify push fails after last night’s phishing-resistant ship. Someone wants “SMS as a backup for Finance.”

First tool: eventType eq "user.authentication.auth_via_mfa" for that actor. Also pull user.session.start on the same transaction — official Help: wrong authenticator returns VERIFICATION_ERROR, and this event is not an access token.

Proof field: outcome.result on the MFA event (Allow / Deny / Challenge) plus the authenticator target (Okta Verify vs SMS vs FastPass). If the new rule requires phishing-resistant possession, enrolled SMS will fail even though Security → Authenticators shows two factors. Enrollment ≠ the policy accepted that factor.

OEVD-03 — Prove the device (FastPass / Device Trust)

02:20 · P2. User swears MFA is set up. Screenshot of Okta Verify. Finance still DENY. Hypothesis: unmanaged device vs a rule that wants Device: Registered, Managed.

First tool: same transaction, expand Device on the FastPass events listed in Device health attributes in System Log events. Quote Disk Encryption Type, Jailbreak, Screen Lock Type, Secure Hardware Present, and whether the device is registered / managed.

Proof field: Device.managed = false (lab) on policy.evaluate_sign_on with THEN Access is Denied. Official FastPass flow: Okta issues a challenge → Okta Verify / FastPass collects device signals and signs with the proof-of-possession key → policies evaluate on that device context. A healthy Verify install on an unmanaged laptop is working as designed when the rule requires managed.

OEVD-04 — Prove assignment (no SSO row)

02:40 · P3. New hire is ACTIVE. Finance-SaaS SAML metadata is valid. No tile. L1 wants the SAML app rebuilt.

First tool: eventType eq "user.authentication.sso" for that actor + app. Official common filter for Application Access / Sign-in Success. Also search application.user_membership.remove if they used to have the tile (Common System Log filters).

Proof field: no SSO row in the window + Assignments tab missing the joiner’s group. Official assign path: Applications and Resources → Applications → the app → Assignments → Assign to People / Assign to Groups. Valid metadata ≠ this user is assigned. Rebuilding SAML is the wrong change.

OEVD-05 — Prove the zone / risk (client.ipAddress + debugContext)

03:05 · P2. Brand-new office NAT. Everyone there is challenged or denied. Someone typed “ThreatInsight is blocking the building.”

First tool: expand Client on any of their events. Official: hover the IP → Filter. Quote client.ipAddress = 203.0.113.40 (lab). Open debugContext.debugData.risk — official example reasons include Anomalous location and Anomalous device. Compare the IP to Security → Networks (Create an IP zone / Add IPs to a network zone from the System Log).

Then rule ThreatInsight out: eventType eq "security.threat.detected" and debugContext.debugData.threatSuspected eq "true". Official outcome.result values on that event: DENY, RATE_LIMIT, ALLOW. Those events often have no username. Path: Security → General → Okta ThreatInsight settings (No Action / Log authentication attempts from malicious IPs / Log and enforce). If ThreatInsight is Log-only and threatSuspected is false, it is not this DENY.

7. Traps + close-the-ticket proof

Proof · named field, then Closed

Sources

• Okta Help — System Log (Reports → System Log; expand row; actor / event type graphs)
• Okta Help — System Log filters and search (From / To / Time Zone; expand actor, client, event, request, target; filter client IP; eventType eq "user.authentication.sso")
• Okta Help — Common System Log filters (application.user_membership.remove)
• Okta Help — Global session policy evaluation (policy.evaluate_sign_on, user.authentication.auth_via_mfa, user.session.start; Allow / Deny / Challenge; session vs app re-auth)
• Okta Help — Add an app sign-in policy rule (Security → Authentication Policies → App sign-in; Device state / management / IP / Risk; THEN Access is; phishing-resistant / FastPass)
• Okta Help — Create a global session policy (Security → Global Session Policy)
• Okta Help — Okta FastPass (phishing-resistant; device posture; challenge → Verify → policy evaluate)
• Okta Help — Configure Okta FastPass
• Okta Help — Device health attributes in System Log events (FastPass events; Disk Encryption, Jailbreak, Screen Lock, Secure Hardware)
• Okta Help — Integrate Okta with Chrome Enterprise (user.session.start, user.authentication.verify, policy.evaluate_sign_on, user.authentication.auth_via_mfa if MFA required)
• Okta Help — Replace Desktop Device Trust with Okta FastPass (user.authentication.authenticate, user.credential.enroll, pki.cert.issue / revoke)
• Okta Help — Risk scoring (DebugContext / DebugData; debugContext.debugData.risk co "level=HIGH"; Anomalous device / location)
• Okta Help — Behavior Detection System Log events (DebugContext on session start / policy evaluate; POSITIVE / NEGATIVE / UNKNOWN / BAD_REQUEST)
• Okta Help — System Log events for Okta ThreatInsight (security.threat.detected; outcome.result DENY / RATE_LIMIT / ALLOW; actor; transaction.id; threatSuspected)
• Okta Help — Configure Okta ThreatInsight (No Action / Log / Log and enforce)
• Okta Help — Create an IP zone
• Okta Help — Add IPs to a network zone from the System Log
• Okta Help — Assign app integrations (Applications → Assignments → Assign to People / Groups)
• Okta Help — Application Access report (queries System Log; outcome result)

Related: Okta session factory — ACTIVE is not allowed · Okta MFA & adaptive policies · Okta architecture & SSO · Okta practice dashboard