Okta Detection False Positives: VPNs, Mobile, Tuning
Why Okta identity detections misfire on corporate VPNs, mobile networks and helpdesk work, what the analyzer cannot see, and how to verify each finding.
TL;DR. Identity detections are heuristics. The most common false positives come from corporate VPNs and security gateways that egress from cloud networks (hosting-provider and multi-network session findings), phones switching between Wi-Fi and mobile data (one session, two ASNs), and genuine helpdesk resets. The most common false negatives come from incomplete exports, distributed attacks spread over many IPs, and techniques the rules do not cover yet. Verify every finding with the people involved, and read a clean verdict as "nothing matched", never as "nothing happened".
I would rather you trust the analyzer a little less and use it well. This page lists what it cannot see and where it over-reacts, rule by rule.
Limits of the data
- 90-day retention. The System Log API does not return events older than 90 days (Okta Developer). An IdP created four months ago, or the first steps of a slow intrusion, are simply not in the export.
- Filtered exports. An export searched on one user misses the helpdesk agent who reset them and the admin who promoted them. Export the whole org.
- Late events. Okta notes that some events for a recent time range may be delayed. Re-export the last hours later during a live incident.
- CSV fidelity. Flattened CSVs drop or rename fields. The analyzer reads LogEvent-path headers and
_rawcolumns; Sentinel's flattenedOkta_CLcolumns are not mapped yet. Prefer API JSON. debugDatais not a contract. Fields such asprivilegeGranted,behaviors,risk,threatSuspectedandtunnelsvary between orgs and releases. Rules that read them can go quiet if a field changes name.- Short history, weak baselines. "New network for this user" is computed from the export itself. With two days of history, every network is new.
Limits of the detections
The 25 rules are listed with their severities on the home page. What they do not do (yet):
| Not covered | Workaround |
|---|---|
| Distributed spraying over many IPs (grouping is per IP) | group failures by ASN and user agent by hand, see password spraying |
| Impossible travel / new country per user | sort a user's sign-ins by time in the event table |
risk = HIGH or behaviors as a detection | visible in the event detail; filter by user |
| OAuth app consent and client-credential abuse | search app.oauth2.* events |
| Group rule and routing rule changes | review the attacker's admin session in full |
| New user created then immediately made admin | check user.lifecycle.create next to admin-grant findings |
| Every inbound IdP sign-in | list user.authentication.auth_via_IDP for any new IdP |
| What happened inside downstream apps | use that app's own logs |
False positives, rule by rule
Hosting provider and anonymizer sign-ins
access.hosting_provider matches keywords in securityContext.asOrg and isp (hosting, VPS, data centre, and the names of large cloud and hosting providers). It fires when:
- your corporate VPN or secure web gateway egresses from a cloud provider;
- staff use a personal VPN or a privacy relay;
- a CI system or script signs in interactively from the cloud (itself a finding worth fixing).
access.anonymizer reads securityContext.isProxy and the tunnels data in debugData. Commercial VPNs are anonymizers from Okta's point of view.
Tuning: list your VPN and gateway egress IPs and ASNs before the incident, and check every hosting-provider finding against that list first. For prevention, Okta's enhanced dynamic zones can block anonymizer categories while allowing your known networks.
One session, several networks or browsers
session.multi_asn (high) and session.multi_user_agent (medium) group events by externalSessionId over 12 hours. Legitimate causes:
- mobile devices moving between Wi-Fi and the carrier network (two ASNs, same user agent);
- connecting to the VPN mid-session;
- browser auto-updates during a long session (two user-agent strings differing only by version);
- dual-stack IPv4/IPv6 connectivity where the two paths are announced by different ASNs.
Tuning: check whether the second ASN is a mobile carrier or your VPN, and whether the user agents differ only by version. A different OS or browser family on a hosting network is the strong case, as explained in session hijacking. Also remember that externalSessionId can be regenerated after factor lifecycle events (Okta Security), so a replayed session may appear under a different ID than the original sign-in; pivot on authenticationContext.rootSessionId in the raw JSON or your SIEM.
Push fatigue
mfa.push_fatigue counts sends as well as rejections: five pushes in 15 minutes. A user with several devices, or signing in to many apps that each require MFA, can reach it. Look at outcomes (all approved?) and the source network of the triggering sign-ins. Details in MFA fatigue detection.
Helpdesk reset then enrollment
mfa.helpdesk_reset_then_enroll fires on every real "I lost my phone" ticket too; that is why its base severity is high, not critical. It becomes critical when the enrollment comes from a network the user had not used before the reset, from a proxy or from a hosting provider. A user who enrolls their new phone from home (where they have signed in before) stays at high. A user on holiday abroad escalates: confirm with them. See helpdesk social engineering.
Password spraying and guessing
access.password_spray needs 8+ distinct users with failures from one IP in an hour, at 3 or fewer failures per user on average. A shared office NAT after a password-expiry wave can come close; the success ratio tells them apart. access.brute_force (10 failures on one user in 15 minutes) fires on scripts with stale credentials, such as an old mail client retrying.
Admin, policy and IdP changes
Role grants, API tokens, policy changes, IdPs and security settings are reported whoever makes them, because the log cannot tell a planned change from a malicious one. Low and medium severities reflect that. Tuning: match each against your change tickets. A Super Administrator grant or a new IdP without a ticket is an incident until explained.
A verification routine for every finding
- Who is the actor, and is it really them? Call on a known number.
- Where from? ASN, country, user agent compared with the user's history.
- What next? The events after the finding: admin actions, enrollments, SSO.
- Is there a record? Ticket, change request, travel.
- Decide and document in the report, with event
uuids.
When the verdict is clean
Check the period, the event count and the users in the statistics row against what you expected. If anything looks short, fix the export and run again. If it is complete and clean, that is useful information, not a guarantee. Keep the export, and review Okta's HealthInsight recommendations for your org.
FAQ
Why does my corporate VPN show up as a hosting provider?
Many VPN and secure web gateway services egress from cloud or data-centre networks. Their ASN organisation names match the same keywords as a VPS provider. Identify your egress ASNs and check them first.
Can the analyzer miss an attack?
Yes. It only sees the exported events, uses fixed thresholds, and does not yet cover every technique. A clean verdict means none of its rules matched, not that nothing happened.