Because they assume a stable log structure and a centralised processing model. Modern cloud, identity, and NHI telemetry arrives in inconsistent formats, at high velocity, and with changing context requirements. A central SIEM then becomes a bottleneck for normalisation, cost, and latency rather than a control point for detection.
Why This Matters for Security Teams
Legacy SIEM design was built for a narrower world: a predictable set of perimeter logs, relatively static identity events, and batch-oriented correlation. Cloud services, SaaS platforms, and NHI activity now generate distributed telemetry that changes shape, volume, and meaning far faster than traditional normalisation pipelines can absorb. That creates blind spots in detection engineering, delays in incident triage, and inflated storage costs when teams try to force everything into one central model. NIST SP 800-53 Rev 5 Security and Privacy Controls remains useful as a control baseline, but it does not remove the architectural tension between modern telemetry and legacy SIEM assumptions.
The core problem is not simply log volume. It is the mismatch between event context and the way older SIEMs expect to process it. Identity events often need cloud resource metadata, session lineage, API action history, and workload trust signals to be useful. When those relationships are stripped away during ingestion, analysts lose the ability to distinguish benign automation from risky privilege use. In practice, many security teams encounter this only after an investigation stalls because the relevant identity and cloud context was never preserved in the first place.
How It Works in Practice
Modern cloud and identity telemetry usually arrives from multiple control planes, each with different schemas, timestamps, enrichment needs, and retention constraints. A legacy SIEM often tries to solve this with a central parser, a fixed field model, and downstream correlation rules. That can work for well-understood event types, but it becomes fragile when the same identity can appear as a human user, an API token, a workload, and an agentic AI process across several platforms.
Practically, the failure shows up in four places:
- Normalization overhead increases before detection value is established.
- Correlation rules depend on fields that are missing, renamed, or delayed.
- High-cardinality identity data drives up licensing and storage pressure.
- Analysts spend more time reconstructing context than validating risk.
Security teams usually need to push more logic closer to the source, whether through cloud-native detection, stream processing, security data lakes, or targeted enrichment before ingestion. That allows identity state, privilege changes, and workload relationships to be evaluated while the context is still intact. For control mapping, NIST guidance such as NIST SP 800-53 Rev 5 Security and Privacy Controls is still relevant for access control, logging, and monitoring expectations, but implementation has to reflect event diversity rather than assume a single log pipeline. Where identity data is involved, this also intersects with privilege lifecycle control, session traceability, and machine identity governance. These controls tend to break down when log transport is delayed or rewritten by multiple intermediaries because the original security context is lost before correlation can occur.
Common Variations and Edge Cases
Tighter normalisation often increases operational overhead, requiring organisations to balance analytical consistency against ingestion cost and time-to-detect. That tradeoff becomes sharper in environments with ephemeral workloads, multi-account cloud estates, or large volumes of service-to-service authentication, where the signal is real but the event shape is highly variable. Current guidance suggests that there is no universal standard for how much context must be preserved at ingest versus reconstructed later.
Some teams can keep a central SIEM effective by limiting scope to high-value use cases, such as identity abuse, privileged actions, or confirmed incident triage. Others need a distributed model where cloud-native detectors, IAM logs, endpoint telemetry, and workload signals feed a broader analytics layer. The main edge case is agentic AI or NHI-heavy environments, where a single operational action may be attributed to a user, a token, a workload, and an autonomous agent in quick succession. In those settings, the architecture must preserve provenance and execution lineage, not just event text. If that lineage is missing, the SIEM becomes a record store rather than a detection system.
For teams formalising a migration path, the practical question is not whether to abandon the SIEM entirely, but which detections truly need central correlation and which are better evaluated closer to the source using cloud-native tooling and identity-centric analytics. That distinction is often the difference between scalable detection and an expensive log archive.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK and OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0, NIST Zero Trust (SP 800-207) and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | DE.AE-1 | Anomalous events must be detected across diverse cloud and identity telemetry. |
| MITRE ATT&CK | T1078 | Valid account abuse is a common identity-led path that legacy SIEMs miss without context. |
| OWASP Non-Human Identity Top 10 | Machine identities and secrets create telemetry patterns that require dedicated governance. | |
| NIST Zero Trust (SP 800-207) | SC-23 | Zero trust demands contextual access decisions that legacy SIEMs cannot supply alone. |
| NIST AI RMF | GOVERN-2 | Agentic AI and model-driven workflows need defined accountability and traceability. |
Build detections that flag abnormal identity and cloud activity before relying on central SIEM correlation.
Related resources from NHI Mgmt Group
- Why do legacy IAM systems struggle with modern cloud access patterns?
- How should security teams unify identity across cloud and data center environments?
- How should security teams reduce cloud identity risk in customer data environments?
- Why do legacy PAM programs struggle with cloud authentication?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on August 2, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
