Opens in a new tab
vmblog logo 2024 wht (updated)

Why Behavioral Analytics Ranks Identity Alerts but Doesn’t Resolve Them

Share: 

Joe Pettit | Published: October 13, 2026
behavioral analytics ranks identity alerts

“AI-powered” identity security promised relief from alert fatigue. But what most vendors have shipped is behavioral analytics, or models that rank a sign-in’s risk. That ranking work stops well short of resolving the case.

It helps decide which alert an analyst should look at first, but the analyst will still have to work out whether the login was malicious.

For SOC teams, this is already part of the daily workload. Impossible travel and anomalous login alerts arrive from Okta, Microsoft Entra ID, or Google Workspace, and identity-based attacks account for a significant share of security incidents.

SpyCloud’s 2026 Identity Exposure Report also found 8.6 billion stolen session cookies circulating in the criminal underground. Another report by Expel found that identity attacks made up 68.6% of the incidents its SOC investigated in 2025, and 47.7% of those ended with the attacker successfully authenticating.

A login can appear legitimate because an attacker may be using legitimate access. Better risk scoring can help analysts decide what to look at first. It still leaves them with an alert to investigate.

Where the Investigation Begins

The existing layers of the security stack were built to do different jobs.

Identity providers, like Okta, Entra ID, or Google Workspace, can spot behavior that falls outside the norm, be it a login from an unfamiliar location, an unexpected IP, or two sign-ins that would require impossible travel. What they hand back is a hedged risk label. The analyst still has to work out what happened.

A SIEM can take the investigation further by bringing together events from multiple sources. An analyst can search the logs and look for other signs of compromise. The SIEM gives them the context and tools they need to investigate, but the analyst still has to interpret what they find.

SOAR can take care of the response once a suspicious login has been flagged. A playbook might challenge the user or revoke the session, and some workflows ask the user whether they recognize the activity. That can settle straightforward cases, but it still doesn’t tell the SOC what the security evidence shows.

None of these tools is necessarily falling short of its purpose. The problem for the SOC is that someone still has to establish whether the sign-in was malicious.

A Better-Ranked Queue Still Needs Investigating

A better behavioral model feels like progress. It moves a suspicious login up the queue and filters out some of the noise. However, it doesn’t do much to help reduce alert fatigue, because the analyst still has to work out what happened. If the model cannot establish whether the account was compromised, it has prioritized the alert without resolving it.

Take an impossible travel alert that lands at the top. Someone still needs to establish whether the user was traveling or using a VPN. They may need to check whether the device is known and examine endpoint telemetry. Authentication logs may provide more context.

The analyst also needs to know what happened after the login. An account that signs in from an unusual location and then behaves normally presents a different case from one that starts accessing applications or cloud resources the user does not normally touch.

A risk score cannot establish that. It identifies the cases that warrant attention. Better rankings can reduce the time analysts spend deciding which alerts to look at. They do not remove the work required to investigate the alerts that make it through.

What an Investigation Still Needs

To resolve the alert, the analyst needs to know more than where and how the user signed in.

That means being able to follow the investigation across identity data and, where necessary, into endpoint or cloud activity. The analyst needs to see what happened after authentication as well as the events surrounding the login itself.

Collecting those events is only part of the investigation. Someone still has to interpret them and reach a conclusion. If a tool is going to take on that work, it needs to state what it determined and show how it got there. If a tool takes on that work, it needs to show how it reached its verdict. Explainability means a glass-box record of every query run and the reasoning behind the conclusion, which a confidence score cannot provide.

Another analyst or reviewer should be able to follow the same evidence and understand the basis for the decision. Sometimes the evidence will not be enough to decide either way. In those cases, the result should be inconclusive rather than forcing a verdict that the evidence cannot support.

Some AI tools investigate alerts from Identity Providers (IDP) such as Okta and Microsoft Entra ID, taking on the work that typically fell on a SOC analyst.. Prophet Security, a leading AI-powered SOC platform, investigates identity alerts such as anomalous logins, MFA fatigue attacks, or session hijacking attacks. It gathers data from the identity provider, and correlates it with data from endpoint telemetry, SIEM, email, and other contextual data to determine whether an alert is a real attack or a benign/false positive, with the evidence attached.

The system is then taking on work that would otherwise begin after the risk score appears.

Look Beyond the Risk Score

Identity attacks are becoming harder to judge from the authentication event alone. Stolen credentials can allow an attacker to sign in as the user. Stolen session cookies can provide access without repeating the original authentication process. SpyCloud recovered billions of these cookies from criminal sources in 2025.

For SOC leaders evaluating AI tools for identity alerts, it is useful to look closely at what happens after an alert is ranked. A high risk score can help with prioritization, but someone still needs to determine whether the sign-in was malicious.

Look at whether the tool can investigate activity across the systems needed for that particular alert and produce a determination based on what it finds. The evidence behind that determination should be available for another analyst to review or reproduce. Where the evidence is insufficient, the tool should be able to leave the case inconclusive.

Those capabilities provide a more useful way to assess AI tools being added to the identity alert workflow. They also make it easier to distinguish tools that reduce investigation work from those that primarily improve which alert the analyst sees first.

##

ABOUT THE AUTHOR

joe pettit headshot photo

Joe Pettit is the owner of Information Security Buzz, and an award-winning Managing Editor during his time running Tripwire’s State of Security blog. Joe specializes in breaking down complex security topics, making it easy for readers to consume. His favorite topics to cover include vulnerability management, compliance regulations, and industrial cybersecurity.