The Identity Game: What Does it mean for SIEMs?

Over the past year, the cybersecurity world has been buzzing with a new label: IdentitySIEM. Vendors are announcing partnerships, platforms are rebranding features, and some would have you believe that security has just discovered identity. But here’s the truth: IdentitySIEM isn’t new—it’s just finally being noticed. For teams that have been doing real behavioral analysis, identity has always been central. It’s how we correlate intent. It’s how we trace patterns. And in cloud-first environments, identity isn’t some workaround—it’s the logical continuation of what audit was designed to capture from the start: actor, action, target, and result. This article walks through what IdentitySIEM actually means, how it’s already shaping modern detection workflows, and why understanding it now is essential—especially if you want your AI to reason the way analysts already do.

The Problem Space: SIEMs Were Built Around Machine Data

The fundamental challenge with traditional SIEM architecture isn’t that it deliberately excluded identity—it’s that it evolved around the dominant source of security data at the time: the network. In the 1990s and early 2000s, most of what security teams had access to were network logs, IDS alerts, firewall events, and flow records. These were machine-centric by nature—focused on IP addresses, ports, and sessions. And so, SIEMs were built to reflect that. They correlated what was available: machine activity.

There were host-based solutions, like Tenable’s Lightning Console or early HIDS tools, but they were less adopted—largely due to the complexity of managing endpoint deployment at scale. Antivirus handled malware; IDS handled intrusion. Everything else lived in a gray zone. The correlation engines inside early SIEMs were therefore optimized for the most accessible and structured data: network telemetry.

This shaped how security analysts worked. If you could bind an IP to a hostname and align it to a session, you had enough to generate an alert and maybe even start an investigation. Users were present in logs, but they were often treated as metadata—secondary information, not the primary object of analysis.

And that matters. Because correlation isn’t just a convenience—it’s the very thing that reduces alert fatigue. Good correlation tells you that ten events belong to one issue. Poor correlation tells you that ten events are ten problems. If the dominant model ties events to machines, then the SIEM tells you what the machine saw, not what the user or process did.

This is the underlying problem: SIEMs followed the shape of the data, and the shape of the data was machine-oriented. Even when UEBA (User and Entity Behavior Analytics) emerged as a discipline, many products treated the “entity” as the endpoint, not the user. And now that identity has become the organizing principle of access and action, most legacy SIEMs are trying to retrofit identity into correlation engines that were never designed for it.

Fluency—and a few others like Exabeam—built differently. We started from the assumption that identity is the root of behavior. If UEBA was going to be meaningful, it had to track and reason about identity first, not treat it as an annotation.

What Is Identity-SIEM? Reclaiming the Actor in a Stateless World

If traditional SIEMs were shaped by network data, Identity-SIEM is shaped by the absence of it. It’s a response to the fact that in modern environments—cloud-native, serverless, zero-trust—machines don’t matter as much anymore. What matters is who or what initiated the action.

At its core, Identity-SIEM emphasizes one thing above all: correlating the identity of the actor to the process. That identity might be a user, a service principal, a token, or a managed function. What matters is that someone or something owns the action, and it’s that ownership that lets us detect meaning, pattern, and risk.

We arrived at this not through hype but through necessity. In traditional networking, every port had a process, and every process belonged to a system. You could reasonably infer ownership through the host. If a process was malicious, you’d isolate the system, because the system was the actor. That model held up as long as infrastructure was physical or VM-bound.

But in cloud environments—especially SaaS and serverless—there is no system. You don’t deploy Office 365 or Zoom to a server you manage. You don’t run AV on Google Drive. There’s no process tree. There’s just the log: a user took an action. And if you’re lucky, the platform tells you what happened. You’re completely dependent on the granularity and reliability of the audit trail.

That’s the heart of the shift. Once everything runs on abstracted infrastructure, you can no longer use host-based correlation. The only meaningful anchor left is the identity of the actor.

This is where Identity-SIEM begins.

Everything is One Entity—So Identity Must Be the Discriminator

Cloud environments collapse the perimeter. It’s not just that the IP address is meaningless—it’s that there’s no local system to tie behavior to. All activity funnels through abstracted APIs and cloud services. From the SIEM’s point of view, it’s just one giant system.

In such environments, correlation by IP or hostname doesn’t help. Everything shares the same IP ranges. Instead, the discriminating factor is who initiated the action. And that’s the key insight: if every system looks the same, the only way to understand intent is to follow the actor.

This mirrors exactly what audit trails were always meant to capture. Going back to the Orange Book in the 1980s, the formal definition of audit data centered on four fields:

It wasn’t about systems. It wasn’t about flows. It was about who did what to what. For decades, we had that concept—but we didn’t have the infrastructure or data visibility to implement it fully. Now we do.

Reframing the Audit Trail: From Machines to Actors

That’s what Identity-SIEM is really about: returning the SIEM to its original purpose, but in a way that matches the modern execution environment. We no longer correlate events by network sessions—we correlate them by actor sessions. We no longer ask “what did this machine do?” We ask, “what did this identity do over time?”

Even in environments where machines still exist—on-prem, hybrid, or edge—the same principle applies. Every process on a system has an owner. Every command, script, or request originates from a context. We just never correlated on that context as the primary index before. Identity-SIEM does.

In Fluency’s model, we broke this down years ago into two flows:

• Network Flow: network behavior modeled over time, used to establish exposure and policy context.
• Event Flow: identity and process behavior, modeled as audit trails.

That bifurcation recognized early on that network analysis and behavioral detection serve different purposes—and that the event trail, not the packet trail, is where the actor lives.

Why Identity-SIEM Is Being Rebranded and Resold

Let’s address the elephant in the room: the sudden buzz around “IdentitySIEM” is not entirely about technical innovation. It’s also about market realignment. As vendors scramble to position themselves for a cloud- and AI-driven world, some are packaging existing identity practices under new labels—and selling it as a new category.

You can see this clearly in the Okta and Palo Alto messaging. Their pitch is compelling: inject identity context into the detection and response layer. But it’s also a way to push a new integration strategy—and a new licensing model. Okta’s value here is not that it creates identity context out of thin air. Microsoft and Google already provide extremely strong identity infrastructure. Most modern products—Fluency included—already support authentication using those native identity providers.

What Okta enables is cross-platform identity management. If your enterprise is spread across Microsoft, Google Cloud, AWS, GitHub, Atlassian, and various SaaS vendors, Okta can centralize identity brokerage. It doesn’t create identity—it unifies it. That’s useful, but it’s also very much a product positioning play. It’s less about detection, and more about authentication plumbing.

Fluency Already Supports Native Identity Correlation

In Fluency, we don’t force customers into a separate identity product to achieve IdentitySIEM. Instead, we honor the identities they already use—Microsoft, Google, SAML, Duo, and others—and build correlation on top of that.

That’s what allows us to:

• Link audit activity across systems using the identity a user authenticated with.
• Ingest and normalize events from different cloud providers under a shared user record.
• Support seamless investigations that follow the user, not the log source.

This absorbed identity schema—the company’s native authentication model—becomes the anchor for detection. It’s not glamorous, but it’s incredibly powerful. By grounding our analysis in the identity already used to access systems, we can tie together disparate events across products, geographies, and platforms.

From Identity to Legitimacy: The Path to Process Ownership

But this goes deeper than just knowing who the user is. Once we have identity correlation, we can start evaluating authorization chains:

• Did this user have the right to access this process?
• Was this login behavior typical, or anomalous?
• Was the process executed from an expected geo-location or network profile?

This is where Geo-IP, authentication context, and risk-based access controls all come into play. And it’s why Impossible Travel detections matter: they expose mismatches in these access patterns.

Identity-SIEM doesn’t just correlate events—it builds the case for legitimacy. It ties access to action, authentication to behavior. It traces the thread from “who are you?” to “why are you doing that?” That’s the real power—and it doesn’t require reinventing the wheel. It just requires structuring your SIEM to follow the path that identity systems already lay down.

How Identity Changes the Way We Investigate Security Events (Without the Marketing)

Let’s be honest: identity doesn’t revolutionize incident response. But it does bring us back to what matters—understanding who took an action, how they got the ability to take it, and whether that’s consistent with what they’ve done before.

This kind of reasoning is central to UEBA , and it’s the basis of what people now like to call “IdentitySIEM.” At Fluency, we’ve been operating this way for years, and we’ve seen firsthand how identity-centered analysis changes the way we approach investigation—not in theory, but in the day-to-day practice of working through alerts.

Let’s Start with a Trigger

Say we get an alert:

“Mr. Jordan has created a new user account.”

That action sets off a flag—not because it’s malicious, but because it’s abnormal. Maybe he’s never added a user before. Maybe he hasn’t done it in the past 30 days. Either way, the behavior deviates from the user’s history, and that’s the real trigger.

Notice what didn’t start the investigation:

• It’s not a login alert.
• It’s not a failed authentication.
• It’s not that the activity was blocked.

The alert fires because someone did something significant and unusual, and we want to understand if it’s legitimate.

So What Really Changes with Identity?

Not the fundamentals of investigation—but the focus. Traditional SIEMs were built around systems and IP addresses. IdentitySIEMs are built around people and services. Instead of asking:

“What did this IP do?”

We ask:

“What did this user do—and is that normal for them?”

This changes how we write detections, how we group alerts, and how we reason about threats. In a world where everything is permission focused, history becomes the measure of risk. And identity is the key to that history.

Conclusion: IdentitySIEM Is Just One Part of the Workflow

Let’s be clear—what we’ve described throughout this paper isn’t a product. It’s not a buzzword or a reinvention. It’s a workflow.

When we walk through an alert—evaluate the actor, verify access paths, consider historical behavior, and look for supporting signals—we’re following a process. In Fluency, we call this soft logic: the structured, reasoning-driven analysis that ties multiple facts into a judgment. This is how human analysts work—and it’s also how we’ve structured AI-based workflows to think.

That’s the real convergence. When people talk about AI and IdentitySIEM in the same breath, they’re dancing around what actually matters: AI can follow this same process, but at scale and speed. It can take an alert and ask, “Is this normal for this identity?” It can pivot into login history, Geo-IP, client fingerprinting, authorization paths, behavioral patterns—all the things we do manually—automated.

And because that process is structured, it becomes teachable. Repeatable. Reliable.

IdentitySIEM Isn’t a New System—It’s a Lens

IdentitySIEM isn’t something you buy—it’s a lens through which you evaluate behavior. It’s a way of anchoring a security workflow on who performed an action, not just what happened.

Yes, identity plays a critical role. But it’s not the whole picture. Some vendors want you to believe identity is the owner of all logic, the singular key to detection. But in real analysis, identity is one dimension among many. Sometimes the login is the trigger event (as with impossible travel). Sometimes it’s the behavior. Sometimes it’s both.

• To treat identity as the only input is to reduce security to one signal.
• To treat identity as the contextual anchor is to elevate detection.

A Final Thought

The industry is just catching up to the idea that workflows matter more than data sources. We’ve built our detection models, our AI reasoning, and our analyst experience around this exact principle for years. Identity is part of that. So are patterns, anomalies, permissions, and behaviors. It’s not about what data you have—it’s about how you think with it.

And that’s what IdentitySIEM really is:

An approach to thinking clearly about security events by anchoring them to the actor, not just the artifact.

That’s not new. That’s just finally being recognized.