The platform's risk engine scores every sign-in attempt. One of the inputs to that score is whether the sign-in's IP is on a known-bad list. The Threat intelligence surface is where you configure which lists.
What ships
Section titled “What ships”- FireHOL Level 1 — a high-confidence list of IPs from known attack sources. Pre-configured; usually on.
- Tor exit nodes — the public Tor exit list. Pre-configured; usually on for non-privacy-focused tenants.
- AbuseIPDB — community-reported abusive IPs. Pre-configured; optional; on for high-traffic tenants.
- Custom URL feed — any URL you control, returning a list of IPs / CIDR ranges. You can have several.
The first three are platform-curated. The custom one is yours.
How feeds affect sign-ins
Section titled “How feeds affect sign-ins”Sign-in arrives → the platform's risk engine reads the source IP → checks each enabled feed → if a hit, the risk score bumps up.
How much each feed bumps the score is configurable. Defaults:
- FireHOL hit → +30 points (likely-malicious; default risk threshold is 60).
- Tor exit node → +20 points.
- AbuseIPDB hit → +15 points (community-reported; less certain than FireHOL).
- Custom URL hit → +25 points (default; tune per-feed).
The score doesn't directly block sign-ins. It feeds into adaptive policies — see Adaptive step-up. At score ≥ 60, the platform demands MFA even if not normally required; at ≥ 80, blocks the sign-in entirely.
What's NOT here
Section titled “What's NOT here”- The risk-engine policy itself. That lives in Settings → Authentication policy → Risk-based controls. The Threat surface is just the IP-feed inputs; the policy decides what to do with the score.
- User reputation (per-user history of suspicious behaviour). The risk engine builds that internally; not configurable here.
- Behavioural signals (mouse movement, typing rhythm). The platform doesn't collect these — too invasive + not in scope.
When to use which feeds
Section titled “When to use which feeds”Most tenants:
- FireHOL — on. Cheap, high-confidence, almost no false positives.
- Tor — on, unless your product is privacy-focused (e.g., journalism tool). Privacy-focused → leave off; you have Tor users.
- AbuseIPDB — on for high-traffic consumer tenants; off for low-traffic B2B (more false positives than value).
- Custom URL — on if you have your own threat intelligence pipeline (some teams maintain internal lists from prior incidents).
Update cadence
Section titled “Update cadence”The platform refreshes feed contents on a schedule:
- FireHOL — every hour.
- Tor — every 15 minutes (volatile list).
- AbuseIPDB — every hour.
- Custom URL — every 5 minutes (you control the URL, so the platform polls aggressively).
If your custom URL is slow to respond or returns errors repeatedly, the platform falls back to the previous successful fetch + emits security.threat_feed_fetch_failed in audit.
Feed consumption isn't a cost-incurring axis on the platform side. Enable everything that's useful; the platform handles polling + caching.
For AbuseIPDB specifically, the platform shares a single AbuseIPDB API key across customer tenants — no per-tenant key setup needed.
When false positives hit
Section titled “When false positives hit”You enable Tor, then a legitimate user signs in via Tor and is unexpectedly blocked. Two paths:
- Disable the feed if your user base genuinely uses Tor.
- Whitelist specific IPs if a small number of users have known-good IPs that happen to be flagged. Threat → Whitelists.
The Test an IP surface (Test an IP) lets you check a specific IP against the configured feeds before adding to the whitelist.