Summary-only aggregations can hide the original event, which is often the only record that contains the session, device, source address, and user agent needed for investigation. That is a problem in identity monitoring because analysts need both the count and the triggering event to decide whether the behaviour is suspicious or expected.
Why This Matters for Security Teams
Summary-only aggregations are attractive because they reduce noise, compress storage, and make dashboards easier to scan. The problem is that identity security depends on context, not just counts. A spike in failed logins, token refreshes, or privilege changes can mean benign automation, credential stuffing, or a compromised session. Without the underlying event, analysts lose the fields needed to triage and correlate activity across IAM, PAM, SIEM, and endpoint telemetry. That weakens detection fidelity and slows incident response.
This is not just a logging preference. It affects whether a team can reconstruct NIST Cybersecurity Framework 2.0 outcomes such as detection, analysis, and response in a way that stands up during investigations. For identity monitoring, the original event often carries the session identifier, device fingerprint, source address, and user agent that explain whether activity was expected, suspicious, or clearly malicious. Current guidance across detection engineering strongly favours retaining enough raw telemetry to preserve those details.
In practice, many security teams discover the limitation only after a suspicious aggregate has already been escalated and the original evidence has aged out or was never retained.
How It Works in Practice
Identity systems often generate high-volume events that are summarised for dashboards, cost control, or long-term reporting. That can be useful for trend analysis, but only if the underlying raw records are still available elsewhere. A useful rule is simple: aggregation is for reporting, while investigations need event-level telemetry. If the monitoring stack stores only the rolled-up result, analysts cannot answer basic questions about how access occurred, whether the event was interactive, and whether the same actor used multiple identities or devices.
In operational terms, the best pattern is to preserve the original authentication, session, and privilege events, then build summaries on top of them. That lets teams correlate with directory logs, PAM session records, EDR alerts, and SIEM detections. It also supports better detection logic for techniques commonly tracked in MITRE ATT&CK, such as valid account use, token abuse, or unusual login sequences. When identity telemetry is mapped well, a summary can still be useful, but it should act as a pointer back to the source record, not a replacement for it.
- Keep raw authentication and session logs long enough for investigation and correlation.
- Store summaries separately for reporting, not as the only retained evidence.
- Preserve source address, device, user agent, and session identifiers where possible.
- Link aggregates back to event IDs so analysts can pivot into the original record.
- Validate that SIEM retention and identity platform retention are aligned.
Strong implementations also define which events must never be collapsed beyond recognition, especially around MFA changes, role grants, token issuance, and privileged logins. These controls tend to break down when identity data is routed through cost-optimised pipelines that drop context before the SIEM or when logging is normalised so aggressively that session-level detail is lost.
Common Variations and Edge Cases
Tighter retention and richer telemetry often increase storage, processing, and privacy overhead, requiring organisations to balance investigative depth against compliance and cost. That tradeoff is especially visible in high-volume SaaS environments, federated identity estates, and environments using short-lived tokens or automated service accounts.
There is no universal standard for how much identity context must be preserved in every environment, but current guidance suggests keeping enough detail to reconstruct the sequence of events, not just the outcome. For example, a failed login burst may be harmless noise in one tenant and an early indicator of compromise in another if the same source address later succeeds with a different user agent. Summary-only views also struggle in shared-IP networks, virtual desktop estates, and agentic automation workflows where many actions can legitimately look similar at the aggregate level.
This is where the identity bridge matters. When an organisation uses non-human identities, service principals, or agentic AI systems, summary-only aggregation can hide which workload actually obtained access and from where. That makes ownership, attribution, and revocation harder. Teams should treat zero trust style verification as a design principle: trust the aggregate for trending, but verify the event for control decisions. Where privacy rules limit retention, the practical compromise is to retain minimised raw records with strong access controls rather than discarding them entirely.
[
{
“framework_code”: “NIST-CSF”,
“control_ref”: “DE.CM”,
“relevance_note”: “Identity monitoring needs continuous telemetry, not only rolled-up counts.”,
“framework_summary”: “Retain event-level logs so detection and analysis can pivot from alerts to source evidence.”
},
{
“framework_code”: “MITRE-ATT&CK”,
“control_ref”: “T1078”,
“relevance_note”: “Valid account abuse is hard to confirm without original session context.”,
“framework_summary”: “Correlate aggregates with raw auth events to spot valid-account misuse and sequence anomalies.”
},
{
“framework_code”: “OWASP-NHI”,
“control_ref”: null,
“relevance_note”: “NHI activity needs provenance and attribution beyond summary metrics.”,
“framework_summary”: “Preserve workload identity context so service and agent actions remain attributable.”
},
{
“framework_code”: “ZT-NIST-207”,
“control_ref”: “SC-4”,
“relevance_note”: “Zero trust decisions rely on continuous verification using rich telemetry.”,
“framework_summary”: “Use detailed identity signals to verify each access request instead of trusting aggregates.”
},
{
“framework_code”: “NIS2”,
“control_ref”: null,
“relevance_note”: “Incident handling obligations depend on sufficient evidence for investigation.”,
“framework_summary”: “Maintain logs and access traces that support timely incident analysis and reporting.”
}
]
