How should security teams decide what identity data belongs in a hybrid SIEM?

Why This Matters for Security Teams

A hybrid SIEM is not a dumping ground for every identity-related event. Security teams need identity data that explains control changes, supports investigation, or proves who changed access and when. That means directory mutations, privileged role changes, cloud admin actions, and SaaS permission updates usually belong in the SIEM. NIST Cybersecurity Framework 2.0 reinforces this outcome by tying logging to detection and response rather than treating collection as the goal.

The practical risk is twofold. If teams ingest too little identity data, compromise investigations stall because there is no audit trail for access changes. If they ingest everything, signal gets buried under noisy telemetry that is better handled by purpose-built monitoring or a data lake. NHIMG’s Ultimate Guide to NHIs notes that only 5.7% of organisations have full visibility into their service accounts, which is a reminder that visibility gaps often start with poor source selection, not just weak tooling. In practice, many security teams discover this only after an access path has already been abused and the SIEM has too much noise, too little context.

How It Works in Practice

The decision should start with use case mapping. A hybrid SIEM should receive identity data when the event helps answer one of three questions: who changed access, who benefited from the change, or whether the change was authorised. That usually includes directory group membership changes, privileged access assignments, MFA policy updates, cloud IAM modifications, application role grants, and SaaS admin actions. These events are high-value because they create audit evidence and often precede abuse.

By contrast, high-volume telemetry such as every authentication attempt, token refresh, or API call should only enter the SIEM when it supports a specific detection rule or incident workflow. Otherwise, that data is often better retained in a security data lake, observability platform, or vendor-native log store for longer-term hunting. The filtering logic should be based on the identity object, the privilege change, and the system of record. NIST CSF 2.0 and the broader logging guidance in NIST Cybersecurity Framework 2.0 support this risk-based approach.

A practical hybrid model usually includes:

• Directory and federation events from Entra ID, Okta, Google Workspace, or equivalent identity providers.
• Privileged group changes, admin role assignments, and conditional access policy changes.
• Cloud control-plane events from AWS, Azure, and GCP where identity governs infrastructure access.
• SaaS permission changes for email, source control, finance, HR, and collaboration systems.
• High-fidelity alerts tied to suspicious identity behavior, such as impossible travel, consent grant abuse, or privilege escalation.

NHIMG’s The State of Non-Human Identity Security is especially relevant here because inadequate monitoring and logging are cited as a major attack cause, which means source selection must be tied to actual investigations, not log collection ambition. These controls tend to break down in multi-cloud environments with fragmented admin planes, because the same identity change may be represented differently across providers and never normalized into a single audit story.

Common Variations and Edge Cases

Tighter SIEM scoping often reduces storage and analyst fatigue, but it also creates the tradeoff of missing context if an incident begins in an adjacent platform. The right balance depends on whether the system is a control evidence store, a detection engine, or both. There is no universal standard for this yet, so current guidance suggests defining separate ingestion tiers for audit-critical identity events, high-confidence detections, and bulk telemetry.

Some environments need more than the usual directory and cloud-admin feeds. Identity data for third-party OAuth grants, service accounts, and API keys can be essential in organisations with heavy SaaS or automation use, especially given NHIMG research showing that NHIs are often over-privileged and poorly visible. The Ultimate Guide to NHIs also highlights how limited visibility into non-human identities can distort incident response, while the 52 NHI Breaches Analysis shows how identity abuse often moves through legitimate access rather than obvious malware.

One common exception is regulated or high-assurance environments, where more verbose identity telemetry may be retained in the SIEM for evidentiary reasons. Another is agentic or automated workload access, where short-lived credentials and delegated actions may need richer correlation to reconstruct intent. Even then, the rule remains the same: ingest the identity data that explains a control decision, and route everything else only when it serves a named detection or compliance purpose.

Related resources from NHI Mgmt Group

• How should security teams choose between a data catalog and data access governance platform?
• How should security teams prioritise NHI remediation in cloud environments?
• How should security teams govern non-human identities at scale?
• How should security teams govern non-human identities for compliance?