Identity events in the SIEM close a major visibility gap

At a glance

What this is: This is a partnership analysis of combining identity authorization events with SIEM data to improve detection, investigation, and audit visibility.

Why it matters: It matters because IAM, NHI, and security operations teams need shared evidence when access changes, privilege escalation, or suspicious activity occur across human and non-human identities.

By the numbers:

• Only 5.7% of organisations have full visibility into their service accounts.
• 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface.
• 71% of NHIs are not rotated within recommended time frames, increasing the risk of compromise over time.
• 80% of identity breaches involved compromised non-human identities such as service accounts and API keys.

👉 Read Opal Security’s analysis of identity event correlation in SIEM

Context

Identity security fails when access events and security telemetry live in separate systems. If a user or workload gains privilege, uses break-glass access, or changes groups without that state appearing in the investigation layer, teams lose the sequence that explains whether the event was legitimate, risky, or malicious.

This problem is especially acute for non-human identities because machine access often changes faster than traditional review cycles can observe. A SIEM that can ingest authorization events alongside logs gives security teams a better chance of linking entitlement change, anomalous activity, and audit evidence across IAM, NHI, and operations workflows.

Opal Security’s partnership with RunReveal is therefore best read as a visibility and correlation play, not just an integration announcement. The underlying issue is the same one that affects many identity programmes: governance data exists, but it is not always available where incident response and detection decisions are made.

Key questions

Q: How should security teams correlate identity changes with SIEM alerts?

A: Security teams should send identity state changes such as token creation, group edits, MFA resets, and emergency access events into the SIEM and join them to behavioural logs in detection rules. That correlation helps distinguish legitimate administration from suspicious privilege use and gives investigators the sequence they need to triage faster.

Q: When does identity data improve detection rather than just reporting?

A: Identity data improves detection when it is available at the same time as activity data and can be used to trigger or enrich alerts. If entitlement changes are only reviewed after the fact, they support reporting but not real-time judgment about whether access use was expected or risky.

Q: What do security teams get wrong about access governance and SIEM tooling?

A: Teams often treat access governance and SIEM as separate control domains, which leaves a blind spot between permission change and behaviour. The mistake is assuming audit trails alone are enough. In practice, investigations need both the entitlement event and the activity trail to judge whether access was misused.

Q: Who should own correlated identity and security monitoring?

A: Ownership should be shared across IAM, SOC, and identity governance teams because the evidence spans entitlement change, alerting, and response. IAM teams supply the access state, SOC teams use it for detection, and governance teams use the joined trail for review and accountability.

Technical breakdown

Why identity events belong in the SIEM

Identity events such as group membership changes, MFA resets, API token creation, and break-glass access are control-plane signals, not just admin records. When those events are streamed into a SIEM, they can be aligned with authentication logs, endpoint telemetry, cloud activity, and SaaS audit trails. That correlation matters because threat investigations rarely hinge on one isolated event; they hinge on sequence, timing, and privilege context. For IAM and NHI teams, the technical shift is from after-the-fact access reporting to event-driven evidence that can support detection logic and response triage.

Practical implication: route high-risk identity events into the same detection pipeline as security logs so investigators can see access state and activity together.

How authorization context improves detection engineering

Detection engineering becomes stronger when the SIEM knows who gained access, what changed, and whether that change was unusual for the identity type. A token created immediately before sensitive resource access can indicate programmatic abuse. A break-glass event followed by atypical behaviour may indicate emergency access misuse. A user added to a sensitive group and then accessing data at speed may indicate privilege abuse. The technical value is not just richer logging. It is the ability to write detections that combine entitlement change with behaviour, which reduces false negatives caused by missing identity state.

Practical implication: build correlation rules that join privilege changes to subsequent activity within the same investigation window.

Unified audit trails and compliance evidence

Compliance teams often struggle because access governance records sit in the IAM or IGA layer while activity evidence lives in the SIEM. That split makes it difficult to prove not only that access was granted, but that it was used appropriately, reviewed, and monitored. Streaming authorization events into security observability tools creates a single evidence path for auditors and internal reviewers. This is especially valuable for sensitive groups, emergency access, and programmatic credentials, where the audit question is usually not whether access existed, but whether the lifecycle and use of that access were defensible.

Practical implication: retain linked entitlement and activity records so access review, incident response, and audit teams work from the same evidence set.

Threat narrative

Attacker objective: The objective is to use legitimate-looking identity state changes to mask malicious activity long enough to reach sensitive resources or evade response.

1. Entry begins when an identity receives or uses elevated access, such as a newly created API token, an MFA reset, or break-glass activation.
2. Escalation follows when that access is correlated with suspicious activity, such as immediate access to sensitive resources or unusual behaviour after group membership changes.
3. Impact occurs when the combined access and activity trail allows either a faster incident response or, if uncorrelated, a missed detection of insider misuse or account compromise.

Breaches seen in the wild

• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
• DeepSeek breach — DeepSeek breach exposed 1M+ log lines and sensitive secret keys.

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

NHI Mgmt Group analysis

Identity telemetry without security telemetry leaves the control plane half-seen: Access governance can tell you what changed, but it cannot tell you whether the change was exploited, abused, or merely observed. Correlating authorization events with SIEM data closes that gap and makes identity state operationally useful. For identity programmes, the practical conclusion is that governance data must be consumable by detection and response teams, not just archived for review.

The most important analytical shift is from static entitlement review to event-linked trust validation: When API token creation, MFA resets, break-glass access, and sensitive group changes appear alongside behavioural telemetry, teams can evaluate whether access history matches actual use. This is where NIST CSF and Zero Trust thinking converge in practice, because continuous verification depends on seeing state changes at the moment they matter. Practitioners should treat identity events as first-class detection inputs, not background administration records.

Runtime correlation is the named concept this partnership illustrates: security programmes increasingly need authorization events and activity logs in the same analytic path so they can reason about identity state at the moment of use. The point is not consolidation for its own sake. It is the ability to answer whether access was expected, whether use was risky, and whether the control boundary was crossed. Security teams should design for correlation first and reporting second.

Machine identities need the same visibility discipline as human accounts, but the timing problem is worse: service accounts and tokens can change state faster than manual review cycles can observe. That is why the gap between identity governance and SIEM matters across NHI, human IAM, and autonomous workflows. Practitioners should assume that the fastest-moving identities will be the hardest to reconstruct after an incident unless their event history is already in the detection layer.

Auditability now depends on joined evidence, not separate systems of record: The stronger model is a linked path from entitlement change to activity to response decision. That does not eliminate the need for IAM or IGA, but it changes their job from record-keeping to operational evidence supply. Teams that cannot join those records will keep proving access existed without proving how it behaved, which is a weak position for both security and compliance.

From our research:

• Only 5.7% of organisations have full visibility into their service accounts, according to the Ultimate Guide to NHIs.
• 71% of NHIs are not rotated within recommended time frames, increasing the risk of compromise over time.
• The rotation and offboarding gap is analysed further in the NHI Lifecycle Management Guide, which is the next resource to use when identity events need governance follow-through.

What this signals

Runtime correlation: identity programmes are moving from record retention to operational evidence, and the security value now comes from joining access state with behaviour at the point of use. That shift matters because a siloed access log can prove permission existed, but only a correlated trail can show whether it was exercised in a way that demanded response. For teams using NIST Cybersecurity Framework 2.0, this is a practical way to strengthen detect and respond functions without overfitting to one tool stack.

The programme signal here is that SIEM design and identity governance are converging. Security teams that still review access changes on a different cadence from detection will miss the operational moment when privilege becomes risk, especially for service accounts and break-glass identities. The right operating model is one where authorization data is treated as detection input, not just compliance evidence.

For identity architects, the next step is not more logging for its own sake. It is deciding which identity events are urgent enough to stream, which correlations matter most, and which investigations depend on linked evidence rather than isolated alerts. Teams that standardise this now will be better positioned for NHI governance, emergency access review, and future agentic workflows.

For practitioners

• Stream high-risk identity events into the SIEM Send API token creation, MFA reset, break-glass use, and sensitive group membership changes into the same detection pipeline as security logs.
• Build correlation rules around entitlement change Write detections that join privilege changes to subsequent access patterns so investigators can see whether a newly granted entitlement was used immediately and unusually.
• Prioritise sensitive identities for joined monitoring Focus first on privileged users, break-glass accounts, and service accounts whose actions can change security posture faster than manual review can catch.
• Create audit trails that combine access and activity Retain linked entitlement records and SIEM activity data so access review, incident response, and compliance teams work from the same evidence set.

Key takeaways

• The core problem is a visibility gap between identity governance and security monitoring, not a lack of data.
• Identity state changes become far more useful when SIEM and IAM teams can correlate access events with behaviour in one investigation path.
• Joined evidence improves detection, response, and auditability, especially for privileged users, service accounts, and emergency access.

Key terms

• Authorization event: An authorization event is a recorded change in what an identity can do, such as token creation, group membership change, or emergency access activation. In identity operations, these events are valuable because they explain privilege state at the moment security telemetry is generated.
• Runtime correlation: Runtime correlation is the practice of joining identity state changes with security activity while an investigation is still active. It lets teams evaluate whether access use matches expected behaviour, which is more useful than reviewing entitlement records after the fact.
• Break-glass access: Break-glass access is emergency privilege granted outside the normal access path so work can continue during an outage or incident. It is legitimate but high risk, and it should always be visible in logs because it can mask misuse if not treated as a special control state.
• Identity telemetry: Identity telemetry is the stream of events that describe how identities are created, changed, authenticated, and used. For NHI and human programmes alike, it becomes security-relevant when those events are fed into monitoring and response processes, not left in isolated admin tools.

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 responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.

This post draws on content published by Opal Security: Unifying Identity Security in Your SIEM: How Opal and RunReveal Create Complete Security Visibility. Read the original.