Has anyone benchmarked login latency after adding ThreatInsight?

I've been conducting a performance review of our Okta-powered authentication flow, with a particular focus on the 99th percentile latency for the primary user login journey. After enabling ThreatInsight with the "Block" mode configured for requests from malicious IPs, I observed a measurable increase in P99 latency that I did not fully anticipate. I'm curious if others in the community have performed similar benchmarking and how your findings compare.

My initial hypothesis was that the latency impact would be negligible, as IP reputation checks are typically fast lookups. However, the integration point and the specific configuration appear to introduce more complexity. Here's a simplified breakdown of the login flow post-enablement and the additional hop I believe is responsible:

1. User submits credentials to Okta.
2. Okta's authentication pipeline now invokes the ThreatInsight evaluation *before* proceeding to password verification or MFA challenges.
3. The ThreatInsight service performs its IP reputation check. In "Block" mode, if a match is found, the flow terminates with an error. If no match is found, the standard authentication process resumes.

The critical path now includes a synchronous, blocking call to an external threat service. While the median latency increase is indeed minor (approximately 12ms in our environment), the tail latency has become more pronounced. Our profiling indicates the P99 increased by ~180ms, and we've observed occasional outliers exceeding 500ms.

My primary questions for the community are:

* Has anyone performed A/B testing or before/after latency profiling specifically for ThreatInsight? Were your results in line with the median increase, or did you also see significant tail latency degradation?
* What configuration nuances might influence this? For instance, does using "Audit" vs. "Block" mode have a different latency profile, given the potential for different code paths?
* Is there a recommended strategy for mitigating this, such as implementing a local, fast-reject IP cache in front of the Okta widget to offload some of these checks, or is the consensus that the security trade-off is worth the latency cost?

I can share anonymized segments of our latency distribution data if it would be helpful for comparison. My interest is in understanding whether this is an inherent characteristic of the service integration or an area where configuration tuning can be effective.