Okta’s Resilient Defense: A Deep Dive into AI-Powered ITDR

In the time it took you to read this sentence, thousands of malicious login attempts have already been made across the globe. The scale and complexity of identity-based attacks are staggering, with threats evolving daily. In 2025, Okta alone blocked more than 15 billion malicious logins across 10,000+ organizations. How can any organization keep up? The answer lies not in building a single strong wall, but in architecting a more intelligent, responsive defense. This is the core principle behind AI-powered Identity Threat Detection and Response (ITDR). In this deep dive, we will unpack the architecture of Okta’s security platform, providing a blueprint for how inline prevention and offline analytics work together to create a truly resilient defense.

In a previous blog, we introduced the concept of layered defenses. In this blog, we’ll explore the complete architecture. We’ll cover these three topics:

1. The architecture of our inline defenses. Inline defenses are like the guards at the gate, protecting users in real time as they interact directly with Okta.
2. The architecture of our offline defenses. Offline defenses are like the surveillance systems that continuously protect identities by analyzing Okta and third-party security signals.
3. Key recommendations to secure Okta tenants.

Why do we need both inline & offline defenses?

We detect & remediate attacks both inline in the path of web requests to Okta (ex: login attempts, user registrations) and also offline as a reaction to security events (ex: a security vendor detects malware on a user’s device).

A combination of inline and offline defenses is necessary for the following reasons.

1. After the user uses Okta to single-sign on into a third-party application, the user interacts with that third-party application until the token is valid. Okta is not in the path of those web requests, and it relies on offline signals from the device, the third-party application, and partners (ex: ZTNA, SASE, EDR vendors) to detect attacks.
2. Inline detections must run very quickly (within a few milliseconds) to avoid impacting the experience of legitimate users. We can’t detect some sophisticated attacks with high precision with inline detections.

The diagram below captures the high-level overview of the inline and offline defenses. As you see in the diagram, the asynchronous events generated from the inline defenses, along with the third-party signals, become an input to the offline defenses. The types of actions that we can take inline (ex: Block or MFA) are different and complementary to the actions we can take offline (ex: Universal Logout or run workflows).

Inline Defenses

Okta processes more than 100 million logins and 100 thousand new user registrations every day. We run multi-layered defenses described below in the path of these requests. In the past 18 months, we introduced the following layers (bold italicized in the blue boxes) in addition to the existing layers described in the previous blog.

Now, let’s unpack the recent innovations in the inline defenses.

Enhanced Dynamic Zones

Attackers often use anonymizing proxies, residential proxies, and certain types of VPNs to hide their location and launch attacks such as credential stuffing and session hijacking. To detect such attacks, we introduced support for enhanced dynamic zones. Customers can now create network zones based on a combination of IP service categories (specific types of anonymizing proxies, residential proxies, and VPNs), geographic locations, and ASNs (Autonomous System Numbers). These zones can be used as blocklists or can be configured as conditions in the sign-on, MFA, and other policies. 

You can use zones to support a variety of use cases. For example:

1. Block all requests to the tenant from any anonymizing proxy except for the proxies that your security policies allow.
2. Require MFA for logins that come from specific types of VPNs while allowing all other traffic.
3. Deny MFA enrollment from a combination of ASNs, countries, and proxy types.

The impact of this feature has been significant: We now evaluate IP metadata for every request that hits Okta. In 2025, more than 1000 Okta customers used this feature to block more than a billion malicious requests.

The diagram below shows the high-level architecture for ingesting third-party IP metadata feeds and making them available for extremely fast lookups. These feeds provide geo-location and other IP metadata, such as IP service categories.

This architecture achieves 2 main objectives:

1. Improved Quality: To reduce the risk of false positives and false negatives, we built an offline pipeline to refresh IP metadata as soon as third-party vendors make the data available.
2. Reduced Latency: To reduce the response times for requests, we architected the application layer to look up IP metadata from multiple vendors in single-digit milliseconds.

Bot Protection

Malicious bots are involved in many high-volume credential-based attacks, such as fraudulent account creation and password spray attacks. To counter this, we recently announced the beta of Bot Protection that complements ThreatInsight to block credential-based attacks in the following ways.

1. Detection: ThreatInsight was built for detecting IPs involved in sign-in attacks. Bot Protection detects bots based on signals beyond IP involved, not just in sign-in, but also in sign-up and recovery attacks. 
2. Remediation: ThreatInsight supports block or log as remediation options. Block is a strong remediation action. With a block, the cost of false positives is high. Bot protection allows customers to configure a softer proof-of-work challenge as a remediation action. This introduces roadblocks for bots while ensuring that legitimate users experience minimum friction.
3. Configuration: Bot protection allows customers to configure remediation based on their risk tolerance. This allows customers to tune the feature to optimize for false positives vs false negatives.

We leverage the very large attack data that Okta has collected over the years to build heuristics and machine learning models to identify bots.

Identity Threat Protection: Session Context Evaluation

After a user is authenticated, the risk doesn't disappear. Identity Threat Protection now includes inline evaluation of session context changes to detect post-authentication threats. This feature continuously evaluates sessions to detect any indication of a hijacked session. Whenever the IP or device context changes, we evaluate the session's risk by running a machine learning model to determine its risk level. The model identifies how anomalous the request is compared to the baseline for that user. 

Customers can configure policies to re-evaluate all the global and application sign-on policies if the session is risky. These are the same policies that are evaluated before a session is granted in the first place. The evaluation of policies not just in the context of a login, but also continuously in reaction to any change in the session context, allows Okta to deliver true continuous authentication. 

Read this blog to understand the details of continuous authentication.

Offline Defenses

Our offline, event-driven defenses continuously analyze security signals from a wide range of sources to proactively identify and respond to threats.

Identity Threat Protection: Continuous User Risk Evaluation

Identity Threat Protection extends beyond inline analysis. We continuously ingest and analyze a wide array of first and third-party security events. We use a combination of offline ML models and heuristics to continuously estimate a user's risk level. The customer can configure policies to take automated actions when a user is flagged as high risk, such as initiating a Universal Logout to log the user out of Okta and all the applications they are logged into. In 2025, Identity Threat Protection flagged more than 70,000 high-risk users. Read this blog to get a more detailed view of the real-world impact of Identity Threat Protection.

The diagram below describes the high-level architecture for ingesting signals from various sources and processing that information asynchronously to update and remediate user risk.

Ingesting Third-Party Signals

Most customers use Okta along with other third-party security products. Many security products operate in silos, and it is extremely challenging for customers to integrate the signals from multiple products to detect and block identity-based attacks. Our innovation with the OpenID Shared Signals Framework standard addresses this challenge. Identity Threat Protection allows customers to configure Okta to exchange security signals with their existing security products (ZTNA, WAF, SASE, EDR, etc.). A standards-based exchange of signals enables seamless and secure integration for both security vendors and customers.

Okta First-Party Signals

Identity Threat Protection ingests signals from multiple Okta native sources. For example:

1. We ingest threat feeds produced by the Okta Threat Intelligence team. These feeds include indicators of compromise associated with malicious phishing-as-a-service infrastructure. This allows customers to take automated remediation actions, such as universal logout, based on the actionable insights generated by our threat research team. 
2. We continuously ingest device signals (ex: Device management status, whether the device is jailbroken, signals from EDR software installed on the device) from Okta Verify to build a rich device context. This device context is used to continuously evaluate the user and session risk.
3. We continuously ingest Okta system log events into a data lake to run offline ML models and heuristics to flag risky users and malicious IPs.

Breached Credential Protection

According to some estimates, there are more than 50 billion breached credentials on the dark web. Attackers use this data to conduct large credential-based attacks. Breached Credential Protection (now Generally Available) integrates with third-party providers to continuously check whether your users' credentials have appeared in known data breaches. If a match is found, we can automatically expire the compromised password and terminate all active sessions, preventing an attacker from using the stolen credentials. 

We built a highly scalable architecture that can download these large databases, process and make them available for a very low latency lookup after a successful password-based authentication.

The diagram below captures the high-level architecture for ingesting billions of breached credentials data from multiple vendors and how that data is used to detect and remediate breaches.

Within the 3 months after it became generally available, Breached Credential Protection flagged 1.7 million breached credentials and reset 770k credentials.

The Unifying Intelligence: How AI Connects the Dots

Neither the Inline nor the Offline layer operates in a vacuum. The true power of this architecture lies in our AI-based detection engine, which unifies data from both. At the heart of this detection engine is the truly unique usage data (ex: IPs, Application Usage, Credential Validations, Device Usage, etc) that Okta collects in the identity pipeline around billions of logins every month. This rich usage data, along with labeled data from known attacks, is used to train both offline and inline machine learning models to block sophisticated identity-based attacks. For example:

1. We use an offline machine learning model to identify malicious IPs involved in large credential-based attacks. We look for patterns around password sprays, login rates, failure rates, types of failures, etc., to identify such IPs. Password spray is one interesting credential based attack where attackers automate verifying a password across multiple user accounts. Okta can identify such passwords by tracking their usage across users and organizations and block those attempts.
2. We use an offline machine learning model to identify IPs involved in phishing attacks based on signals from attempts blocked by FastPass.
3. We use an inline machine learning model to flag account takeover and session hijacking attacks. The machine learning model determines whether the request deviates from the baseline (known-good IPs, devices, locations, etc.) we establish for users based on their successful logins.
4. We use an inline machine learning model to identify suspicious requests based on various request-level attributes, so we can rate-limit them separately from legitimate requests to the organization.

Key Recommendations 

1. Enable ThreatInsight, Enhanced Dynamic Zones and Bot Protection to proactively block large-scale, automated attacks at the front door.
2. Enable Breached Credential Detection to instantly neutralize threats from credentials compromised in third-party breaches.
3. Enable Identity Threat Protection to achieve true continuous authentication and respond to post-authentication threats in real-time.

Conclusion

We encourage you to use this deep dive as a lens to examine your own security posture. Are your defenses working in concert? Are you leveraging AI to detect the undetectable? Moving beyond traditional, siloed tools toward an integrated, AI-powered ITDR framework is the definitive next step in securing your identities and assets against the modern threat landscape.