Why SIEMs fall short for identity security governance

At a glance

What this is: This analysis argues that SIEMs and log stores can collect identity events but cannot provide the access context or remediation layer identity governance requires.

Why it matters: It matters because IAM, IGA, PAM, and NHI programmes need live entitlement context and write-back to reduce access risk, not just observe it after the fact.

👉 Read Oleria Security's analysis of why SIEMs cannot solve identity security

Context

Identity security is not the same as log analysis. A SIEM can show that an identity authenticated or that an API call occurred, but it cannot by itself model who has access to what across systems, how that access was granted, or whether it should still exist.

The governance problem gets harder when access spans human identities, service accounts, cloud entitlements, and automated workflows. In that environment, teams need a composite access graph and continuous synchronisation, not a pile of events that only becomes useful after the fact.

This is a common failure mode for teams trying to extend their existing telemetry stack into identity governance. The source article argues that the architecture gap is structural, and that is the right lens for IAM leaders evaluating whether to build access intelligence on top of logs.

Key questions

Q: How should security teams govern identity access if they already have a SIEM?

A: Use the SIEM for detection and investigation, but keep identity governance in a system that can model access relationships and write changes back to source systems. The critical test is whether the platform can show entitlement lineage, resolve identity across systems, and enforce revocation. If it cannot, it is supporting governance rather than performing it.

Q: Why do SIEM logs fail to provide enough context for identity governance?

A: Logs show activity, not durable entitlement state. Identity governance depends on understanding roles, inherited permissions, group membership, and source-of-truth data across systems. Without that context, teams can detect suspicious access but cannot reliably decide whether access is legitimate, stale, or excessive.

Q: What breaks when organisations try to build identity governance only from logs?

A: The first break is access lineage, because logs do not tell you how a permission was granted or whether it came from a nested group or workflow exception. The second break is remediation, because a log stack can describe the problem but cannot safely remove the access that caused it.

Q: Should organisations replace the SIEM or augment it first?

A: Most teams should augment first. A shared data layer can improve context, retention, and triage without forcing a risky rip-and-replace. Replacement only makes sense when the current platform cannot support the retention, enrichment, or investigation model the SOC actually needs.

Technical breakdown

Why log stores cannot model identity relationships

A log store records events in sequence, such as authentications, token use, and administrative actions. Identity governance needs relationship state, including roles, entitlements, group membership, inheritance, and source-of-truth context from HR, cloud, and SaaS systems. Without a unified schema, the same user can appear as several disconnected records, and the same permission can mean different things in different applications. That makes it impossible to answer access questions reliably from logs alone.

Practical implication: treat SIEM data as evidence for investigation, not as the system of record for entitlement governance.

Why bidirectional integrations change the security model

Reading data from identity and application systems is only half the problem. Effective governance also requires writing changes back to source systems, such as revoking access, correcting role assignments, or closing out stale entitlements with auditability and rollback. A SIEM is normally read-only by design, so even perfect detection leaves remediation outside its control boundary. That distinction is what separates observability from governance.

Practical implication: map every privileged access workflow to a source system that can actually enforce the decision, not just report it.

Why AI over raw logs produces shallow identity insight

AI can only reason over the structure it is given. If the underlying dataset is a stream of raw logs, the model can identify activity patterns but not entitlement lineage, inherited access, or toxic privilege combinations across systems. A knowledge graph plus a common access schema gives AI the context needed to explain why access exists and what should happen next. Without that layer, the output is descriptive rather than governable.

Practical implication: do not place AI above a logging stack and expect identity decisions to improve without a normalised access model underneath.

Threat narrative

Attacker objective: The objective is persistent access that remains unreviewed because governance and enforcement live in separate systems.

1. entry: The organisation begins with legitimate identity and audit logs already flowing into the SIEM, creating the impression that identity context is available for governance use.
2. escalation: Teams attempt to stitch together roles, entitlements, and application permissions through custom connectors, but the access model remains fragmented and incomplete across systems.
3. impact: The result is visibility without enforcement, where stale access persists, remediation is manual, and AI only accelerates analysis of incomplete identity data.

Breaches seen in the wild

• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
• Meta AI Instagram Account Takeover — 20,225 Instagram accounts hijacked via compromised Meta AI support chatbot with overprivileged access.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

SIEM telemetry is not an identity governance control. Security teams often confuse event visibility with entitlement control, but the two solve different problems. A SIEM can help detect suspicious behaviour after it happens, yet it cannot maintain access lineage, enforce role correctness, or remove entitlements in source systems. The practitioner conclusion is simple: logs support identity governance, but they do not constitute it.

Composite access graphs are the real governance substrate. Identity decisions require a living model of who has access to what, why they have it, and how that access relates across systems. That requirement spans IAM, IGA, PAM, and NHI governance because the access problem is cross-domain, not tool-specific. Teams that do not build or buy a composite access model end up making decisions from partial evidence.

Write-back is what turns insight into control. If a platform cannot safely remove access, adjust role assignments, or revoke entitlements at the source, then it only produces recommendations. That limitation is especially harmful in environments with NHI sprawl and cloud entitlements, where access can outpace review cycles. The practitioner conclusion is that control ownership must sit where enforcement can actually happen.

Access context, not log volume, determines identity security maturity. Many programmes invest in more telemetry when they really need better data relationships. The article underscores a category-level truth: identity security is an access-intelligence problem, and access intelligence depends on normalised schemas, lineage, and continuous synchronisation. The practitioner conclusion is to measure governance by coverage and enforceability, not by event count.

Autonomous governance only works when the control plane can act back on the identity source. If the system can detect an access issue but cannot close the loop, the organisation is still relying on human intervention to finish the job. That matters most when AI-assisted workflows and NHI populations expand faster than review capacity. The practitioner conclusion is to design for closed-loop enforcement, not dashboard visibility.

From our research:

• 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, according to The State of Non-Human Identity Security.
• A separate finding from the same research shows that only 1.5 out of 10 organisations are highly confident in their ability to secure NHIs.
• For a broader control perspective, see Ultimate Guide to NHIs , Lifecycle Processes for Managing NHIs for provisioning, rotation, and offboarding coverage.

What this signals

The practical signal for identity programmes is that telemetry maturity will keep lagging access complexity unless teams create a control plane that owns entitlement state. Composite access graph: a live, normalised view of who has access to what across systems, and the foundation for enforceable governance rather than retrospective analysis.

For IAM, IGA, PAM, and NHI teams, the next investment question is not how much more log data can be collected, but how much of the access lifecycle can be enforced from source systems. That shift aligns with the NIST Cybersecurity Framework 2.0 view of identity as a control outcome, not an observability by-product.

The organisations that will mature fastest are the ones that can connect detection, review, and revocation in a single workflow. AI can help prioritise decisions, but it cannot compensate for missing access lineage or a read-only control layer.

For practitioners

• Separate observability from governance ownership Classify your SIEM as a detection and investigation layer, then define which system owns entitlement truth, review approval, and revocation execution for each identity type.
• Build or buy a composite access graph Require a unified access model that can stitch roles, groups, entitlements, and inheritance across HR, SaaS, cloud IAM, and internal applications before you attempt AI-based reasoning.
• Test write-back before expanding analytics Validate that every remediation workflow can modify source systems safely, with rollback and audit trails, instead of stopping at alert generation or recommendation text.
• Measure governance by enforcement coverage Track how much of the environment can be reviewed, certified, and remediated from one control plane, including cloud entitlements and service-account access that typically sit outside SIEM workflows.

Key takeaways

• SIEMs can support identity investigations, but they cannot replace the access context required for governance.
• The scale of the visibility problem is already large, with 85% of organisations lacking full visibility into third-party OAuth-connected vendors.
• Identity programmes need composite access graphs and write-back enforcement if they want governance to change access, not just describe it.

Key terms

• Composite access graph: A composite access graph is a live model of identity-to-resource relationships across systems. It resolves users, service accounts, roles, entitlements, and inheritance into one connected view so teams can answer who has access, why it exists, and what should happen next.
• Identity Lineage: Identity lineage is the traceable relationship between a human owner and the non-human identities that person creates, authorises, or depends on. It allows security teams to connect service accounts, API keys, tokens, and AI agents back to accountable ownership for review, audit, and retirement decisions.
• Write-back Remediation: Write-back remediation is the ability to push an access decision back into the target system so the entitlement is actually changed, not just reported. It matters because governance without execution leaves review findings, revocation decisions, and offboarding tasks unresolved.
• Identity Control Plane: An identity control plane is the governance layer that decides who or what can access systems and under what conditions. In practice, it coordinates authentication, authorization, privilege review, and lifecycle management across human and machine identities so access policy is enforced consistently across environments.

What's in the full article

Oleria Security's full article covers the operational detail this post intentionally leaves for the source:

• Connector architecture for reading roles, entitlements, and group membership across cloud and SaaS systems
• Write-back and remediation workflows with rollback and audit trail requirements
• How the composite access graph and lineage engine support identity decisions
• The build-versus-buy engineering effort behind maintaining identity integrations at scale

👉 The full Oleria Security post covers integration depth, graph design, and autonomous remediation requirements.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building identity security capability across IAM, IGA, or NHI operations, it is worth exploring.