Why your SIEM can’t solve identity security and what it actually takes

We hear it regularly.

“We already have Splunk — can’t we just query it for identity data?”
“Our team built connectors into Elastic. Why would we need another platform?”
“Azure has all our logs. We’ll layer AI on top and build what we need.”

These are reasonable-sounding questions from smart people. And they reveal a misconception that costs organizations months — sometimes years — of wasted effort before they arrive at the same conclusion: a log store is not an identity security platform, and no amount of AI layered on top will make it one.

It’s an engineering reality check. If you’re an architect evaluating whether to build or buy, or a security leader deciding where to invest — this is what the problem actually looks like from the inside.

The misconception: “We have the data, we just need a better interface”

The assumption sounds logical. Your SIEM or log store already ingests authentication events, audit trails, and API logs. That’s identity data, right?

It is — in the same way that a pile of lumber is a house. The raw material exists, but the structure, context, and function that make it useful are entirely absent.

Here’s what a log store actually captures: events. User X authenticated to System Y at timestamp Z. That’s valuable for incident investigation and compliance reporting. But identity security requires answering fundamentally different questions:

Who has access to this production database, through what role chain, across which systems, should they still have it based on their current job function, and what’s the safest way to remove it if not?

That question requires data your SIEM doesn’t collect, relationships it can’t model, context it was never designed to hold, and write-back capabilities it structurally cannot perform.

Layer 1: The integration problem is not what you think it is

The first thing teams underestimate is the integration layer. “We’ll build connectors” sounds straightforward until you’re actually doing it.

Reading authentication logs from Okta or Entra ID is the easy part. Building bidirectional, API-level connectors that can read the full access model — roles, entitlements, group memberships, resource permissions, inheritance chains — from Workday, Salesforce, ServiceNow, AWS IAM, Azure RBAC, GCP IAM, GitHub, Jira, and hundreds of custom internal applications is a fundamentally different engineering challenge.

Every system has its own access model, its own API quirks, its own undocumented behaviors. We’ve seen connectors that took tens of iterations to get right — and they’re never “done.” Vendors change APIs. Edge cases surface in production. New permission types get introduced. What starts as a “build a connector” project becomes a permanent maintenance burden with dedicated engineering resources.

And that’s just the read side.

Writing back — safely removing access, modifying role assignments, revoking entitlements across source systems with proper rollback and audit trails — is an order of magnitude harder. Your SIEM is architecturally read-only. It was designed to receive events, not to take action on the systems that generated them. This isn’t a feature gap. It’s a structural limitation.

One prospect invested months having a Senior Engineer attempt to build this integration layer. They came back to us — not because the Engineer wasn’t capable, but because the scope of what “connecting identity data across systems” actually means was fundamentally larger than anyone anticipated. That’s months of engineering time that could have been spent on their core product.

Layer 2: Raw data isn’t context — and context is everything

Suppose you solve the integration problem. You now have access data flowing in from dozens of systems. What do you actually have?

Disconnected records. User IDs that don’t match across systems. Role names that mean different things in different applications. Entitlements with no common schema. No way to trace how someone got access — whether it was a direct grant, inherited through a group, or an exception that was supposed to be temporary.

This is where most “build it ourselves” efforts quietly die.

Identity security requires a common access schema — a unified ontology that translates every system’s unique access model into one language. Then you need a composite access graph — a living, continuously-synced knowledge graph of every identity-to-resource relationship across your environment. Not a static export. Not a nightly batch job. A live map of who has access to what, right now A graph that reflects the current state of access across all systems simultaneously, with cross-system identity resolution.

And on top of that, you need access lineage — the ability to trace the full grant chain for any permission. Was this access granted directly? Inherited through a nested group three levels deep? Provisioned by an automated workflow that no one remembers creating? Is the person who approved it still at the company? Does the access still align with the user’s current role, department, and manager?

This is where HR systems, business rules, peer group analysis, and usage patterns become essential inputs — none of which your Elastic cluster or Splunk instance has any concept of.

Layer 3: The AI layer that everyone oversimplifies

“We’ll just point AI at the data.”

This is the argument we hear most from teams that have a data store and access to large language models. And it reveals the deepest misconception of all.

AI reasoning over identity data is only as good as the foundation underneath it. If your data layer is raw logs without a common schema, your AI is pattern-matching on inconsistent, incomplete data. The difference between an AI that says “User X accessed System Y 47 times this month” and one that says “User X has admin access to three production databases they haven’t touched in 90 days, inherited through a role chain that traces back to a department transfer 18 months ago, and their peers in the same role have none of this access” — that difference is entirely a function of the data architecture underneath.

You cannot shortcut your way to intelligent identity security by layering a language model over a log store. The AI needs a knowledge graph. The knowledge graph needs a common schema. The common schema needs bidirectional integrations. And the whole stack needs write-back capability to actually do something with the insights — otherwise you’ve built a very expensive dashboard.

Layer 4: The compounding effect — why this gets harder, not easier

Here’s what the build-vs-buy calculation often misses: each layer doesn’t just add complexity — it multiplies it.

Every new system you integrate reveals new edge cases in your schema. Every schema update ripples through your graph. Every graph change affects your lineage calculations. Every lineage update changes what your AI recommends. And if you want autonomous action — governance campaigns that can detect, recommend, and remediate access issues without manual intervention — every layer needs to be reliable enough to trust with production changes.

The number of commercial and custom applications in a typical enterprise is growing, not shrinking. Non-human identities and AI agents are proliferating faster than human identities ever did. The complexity compounds in every direction simultaneously.

This is years of dedicated platform engineering. It’s the kind of problem where the first 80% looks deceptively achievable and the remaining 20% is where organizations get stuck

What it actually takes: the full stack

For architects and technical leaders evaluating this space, here’s the honest picture of what an identity security platform requires:

• Bidirectional integrations across hundreds of commercial and custom applications — HR systems, identity providers, SaaS platforms, cloud IAM, DevOps tools — with read and write capability, safe execution, rollback, and audit trails.
• A common access schema that normalizes every system’s unique access model into a unified ontology.
• A composite access graph that continuously syncs the full identity-to-resource relationship map across all connected systems, with cross-system identity resolution.
• Access lineage and context enrichment that traces full grant chains, differentiates direct from inherited access, and incorporates usage patterns and risk signals.
• AI reasoning that operates over the enriched knowledge graph — not raw logs — to surface insights and toxic access combinations in natural language.
• Autonomous governance that can execute decisions back through the integration layer — access reviews, certifications, auto-remediation, policy enforcement— in a closed loop with human oversight.

Every one of these layers is in production at Oleria today. TrustFusion is the platform we built specifically because we understood that identity security is not an automation problem — it’s an autonomous knowledge and operations problem that requires purpose-built infrastructure from the data layer up.

The build vs. buy reality

Building read-only connectors for a handful of systems is doable. Most engineering teams can get that far in a quarter or two.

Building read/write integrations across hundreds of applications — from Workday to AWS IAM to custom internal tools — with safe remediation, rollback, and audit trails? Then layering a common schema, composite access graph, lineage engine, AI reasoning, and autonomous governance on top?

That’s not a quarter. That’s not even a year. It’s a multi-year, dedicated platform engineering effort — and it’s exactly what we’ve been building at Oleria.

The question isn’t whether your team could build pieces of this. They could. The question is whether that’s the best use of their time when the identity security problem is growing faster than any internal team can keep up with, and a purpose-built platform already exists.

Your SIEM is excellent at what it was designed to do. The question isn’t whether to keep your SIEM — it’s whether you can afford to keep asking it to do something it was never built for. Identity security requires a fundamentally different architecture — one that was built from the ground up to understand, reason about, and act on the full context of who has access to what, why, and what to do about it.