Okta and CrowdStrike announced a deepened integration on Wednesday that connects identity risk signals and endpoint response in both directions and in near real time. A sign-in that Okta scores as high risk can now trigger CrowdStrike to isolate the originating device within seconds. An endpoint that Falcon flags as compromised causes Okta to revoke every active session for the associated user across every connected application. Both directions existed before through workflow automation with latency measured in minutes. The new implementation uses a direct signal exchange with a stated median propagation of 1.8 seconds, which is the difference between containing an intrusion and documenting one.
The gap this addresses
Modern intrusions frequently begin with valid credentials and a session token, which means the identity system sees a legitimate login and the endpoint system sees ordinary process activity. Each has part of the picture. The attacker relies on the two not comparing notes, and the typical enterprise architecture, where identity and endpoint are separate products with separate consoles and an integration built through a security orchestration platform, guarantees a delay.
That delay is where the damage happens. Session token theft, which has become the dominant technique for bypassing multi-factor authentication, gives an attacker a working session that survives password changes. Revoking it requires the identity provider to act, and the identity provider does not know the token was stolen unless something tells it. An endpoint detection alert is exactly that signal and it has historically taken minutes or hours to arrive.
How the exchange works
The integration uses the Shared Signals Framework, an OpenID Foundation standard for security event transmission between services, which both companies have been implementing since 2023. Events flow over a persistent stream rather than polling, which is where the latency improvement comes from. Okta emits risk change events and session events. CrowdStrike emits device compromise and containment events. Each side maps the other's identifiers through a shared device and user correlation.
That correlation is the hard part in practice. Okta identifies a user; CrowdStrike identifies a device. Connecting them requires knowing which user was on which device at a given moment, which is straightforward for a managed laptop with a single user and difficult for shared workstations, jump hosts, and virtual desktop environments. Both companies say the mapping works well for the common case and requires configuration for the rest, which is the correct expectation to set.
The story is rarely the launch. It is what breaks, what ships, and who owns the mess at 2 a.m.
The automation risk
Automatic isolation is powerful and dangerous. A false positive that quarantines a chief executive's laptop during a board meeting, or revokes sessions across an engineering organization during an incident response, causes real damage and destroys trust in the tooling. Security teams have learned this repeatedly and most run automated response in a narrow, carefully scoped configuration.
The integration ships with response actions disabled by default and a policy layer that lets teams scope automation by user group, device type, and confidence threshold. The recommended rollout, which both companies' documentation describes, is to start in alert-only mode, measure how often the automation would have fired and whether those cases were genuine, and enable enforcement for high-confidence signals first. That is sound advice and the teams that skip it will generate the incident stories other teams learn from.
The competitive context
Microsoft has offered this natively between Entra and Defender for years, and the integration is tighter than anything two separate vendors can achieve. That is the core argument for Microsoft's security suite: the pieces know about each other because they are built together. Okta and CrowdStrike are both, in different ways, competing against that argument, and a fast standards-based integration is the strongest counter available to them.
The standards angle matters beyond these two companies. Shared Signals is an open specification, and Cisco, Zscaler, SailPoint, and Netskope all have implementations at various stages. If the ecosystem converges on it, best-of-breed security architectures become viable again against the suite argument. If it stays a bilateral integration between two large vendors, it does not.
What teams should do
Organizations running both products should enable the integration in monitoring mode immediately, because the visibility alone is valuable even without automation. Seeing which sign-in risk events correlate with endpoint findings tells you something about your environment that neither console shows separately.
Organizations running one and not the other should not buy the second for this. The more useful exercise is to ask your existing vendors about Shared Signals support and their roadmap, because the capability matters more than the specific pairing. The teams that will benefit most over the next two years are the ones that make interoperability a purchasing requirement rather than a pleasant surprise.
It is also worth planning for the incident where this fires correctly and the response is still wrong. An isolated device in the field, a revoked session during a customer call, or a quarantined machine belonging to someone who cannot reach the help desk are all operational events that need a documented recovery path before the automation is enabled. The teams that handle this well write the runbook first, including who can override and how fast, and treat the security capability as something that comes with a support obligation rather than as a switch you turn on.
Skarvonix will keep following this beat with reporting grounded in how systems behave outside the launch keynote.
- Zero Trust
