Why trailing aggregation windows matter for event-driven detections

At a glance

What this is: This is an analysis of why aggregation should be treated as separate choices for boundary, state, and output, with TQL used to preserve the triggering event while attaching rolling context.

Why it matters: It matters because identity and security teams often need the original event plus its history for investigations, correlation, and detection logic, not just a collapsed summary row.

By the numbers:

• Only 5.7% of organisations have full visibility into their service accounts.
• 71% of NHIs are not rotated within recommended time frames, increasing the risk of compromise over time.
• 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface.

👉 Read TENZIR's analysis of stateful aggregation for event-driven detections

Context

Aggregation in security pipelines is often misunderstood as a single step, but it actually bundles three decisions: when a result is complete, whether state carries forward, and which rows should be emitted. That distinction matters in detection engineering, where the original event and its surrounding context are often both required for analysis. In identity-heavy environments, the same logic appears in session analytics, authentication monitoring, and service-account review.

The article’s core point is that different tools expose these choices in different ways, which makes cross-platform detection logic harder to reason about than it should be. TQL’s approach is to make the model explicit so teams can express trailing windows, stateful counts, and event-preserving outputs without forcing every use case into a summary shape. For teams managing identity signals, that clarity can improve correlation around login bursts, suspicious successes, and other event sequences that should not be collapsed too early.

Key questions

Q: How should security teams use trailing windows in authentication detections?

A: Use trailing windows when the meaning of an event depends on the immediately preceding history, such as a successful login after repeated failures. This preserves the decisive event while attaching the evidence window that explains why it matters. For authentication telemetry, that usually produces better triage than a collapsed count alone.

Q: Why do summary-only aggregations create blind spots in identity monitoring?

A: 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.

Q: What do security teams get wrong about rolling event counts?

A: They often assume a rolling count is enough on its own, even when the alert also needs the event that crossed the threshold. In practice, the count and the event are different outputs. If the pipeline cannot retain both, the detection may be mathematically correct but operationally weak.

Q: How do teams keep stateful detections correct in parallel pipelines?

A: They need deterministic routing so all events for the same key, such as a user or service principal, are processed by the same state owner. Otherwise partial histories can split across workers and thresholds can fail silently. Correct keyed state is as much a reliability issue as a detection issue.

Technical breakdown

Grouped summaries versus event-preserving windows

Grouped aggregation reduces a population into summary rows, which is useful for totals, averages, and counts but discards the original event. Windowed aggregation keeps a bounded slice of the stream and can emit the triggering event with attached context. That difference is why SQL GROUP BY, Kusto summarize, Splunk stats, and TQL summarize are not interchangeable with rolling or trailing windows. In detection work, preserving the event matters because the analyst needs the session, source, device, and user attributes that a summary would hide.

Practical implication: choose event-preserving windows when the alert must carry the triggering record forward, not just a count.

Trailing windows and stateful detection logic

A trailing window anchors the analysis on the current event and examines only the history immediately before it. That is different from tumbling or hopping windows, which evaluate fixed boundaries that can split an attack pattern across frames. The article’s login example shows why this matters: five failures followed by one success should produce the success event annotated with prior failures, not a separate aggregate that loses the decisive login. The model is especially important when detections depend on burst patterns, sequence context, or threshold crossing at the moment of success.

Practical implication: use trailing windows for threshold detections that depend on the history immediately preceding a success or change event.

Admission, contribution, and firing are separate controls

The article separates three ideas that many systems blur together. Admission decides what enters retained history, contribution decides what counts toward the aggregate, and firing decides which events trigger evaluation. In a login-burst detection, all three are different: every login is retained, only failures contribute to the count, and only the success event fires the window body. That separation makes the logic easier to audit and reduces accidental false positives or missed outputs. It also helps explain why a pipeline can behave correctly even when the retained history is large or the data arrives out of order within tolerance.

Practical implication: design stateful detections by explicitly specifying what is retained, what is counted, and what is allowed to trigger output.

Threat narrative

Attacker objective: The attacker objective is to obtain a successful authenticated session after credential-guessing or password-spraying activity while avoiding detection until the decisive login occurs.

1. Entry begins with a burst of repeated failed logins against a single account, creating the signal that the pipeline later needs to evaluate.
2. Escalation occurs when a subsequent successful login arrives after the failure threshold, turning a noisy authentication sequence into a potentially suspicious access event.
3. Impact is the ability to surface the success event itself, enriched with contextual evidence that supports triage and downstream investigation.

NHI Mgmt Group analysis

Event-preserving aggregation is a governance problem, not just a query syntax problem. Security teams often need the original login, token, or API event plus its preceding context, because the summary row alone is not actionable. When detection logic collapses the event too early, identity signals lose the session, device, and source details needed for triage. Practitioners should treat output shape as part of the control design, not a formatting choice.

Trailing windows expose a useful concept: detection should follow the event, not the boundary. Fixed buckets are convenient for reporting but brittle for burst-based identity abuse, especially when a success is meaningful only because of what preceded it. That distinction is central to authentication monitoring, service-account abuse detection, and some forms of NHI governance where the sequence matters more than the total.

Identity telemetry becomes far more useful when summary and trigger logic are separated. Many SOC and IAM workflows still conflate running counts with enrichment, which makes it harder to reason about thresholds and evidence retention. The same principle applies to service accounts and machine identities, where a single authenticated event may need to carry historical context for access review, incident response, or zero-trust enforcement.

Stateful analytics should be designed as pipeline primitives, not bolt-on correlations. Once teams rely on downstream enrichment to reconstruct context, they create avoidable gaps in auditability and detection fidelity. For IAM and NHI programmes, this reinforces the value of making state boundaries, retention rules, and event emission explicit in the pipeline itself.

Composable aggregation is a better fit for modern identity telemetry than monolithic search commands. The operational reality is that authentication, privilege use, and service-account behaviour all produce event sequences that need different shapes at different stages. Teams that separate those shapes can build clearer controls and faster investigations.

What this signals

Stateful detection is becoming an identity control surface. As organisations push more authentication and service-account telemetry into pipelines, the ability to preserve event context will shape investigation quality as much as the raw signal volume. Teams that already struggle with service-account visibility should expect the same gap to appear in detection logic, which is why full lifecycle observability matters as much as alerting.

Detection engineering for identity data needs a lifecycle mindset. The same programme that cannot consistently see service accounts will also struggle to explain which events were retained, which were counted, and which were emitted as evidence. That makes control design, not just query design, the critical discipline. NHI Mgmt Group sees this as another reason to align telemetry pipelines with NIST SP 800-53 Rev 5 Security and Privacy Controls and clear identity governance boundaries.

For practitioners

• Separate detection outputs from summary metrics Define detections so the triggering event is preserved with attached context, while aggregate-only reporting stays in a separate pipeline. This avoids losing the session, device, and source fields needed for follow-up analysis. Use the original event as the alert carrier whenever a sequence matters.
• Use trailing windows for burst-based authentication logic Apply trailing windows to success-after-failure patterns, password spraying checks, and similar identity sequences where the decisive event is the last event in the series. Fixed buckets can split the history and hide the threshold crossing. Keep the lookback anchored on the arriving event.
• Explicitly define admission, contribution, and trigger rules Document which events enter retained history, which events count toward the aggregate, and which events cause evaluation. This is especially useful in authentication pipelines and service-account monitoring where only one event type should fire the logic. Make the rule set auditable.
• Route keyed identity events to a single state owner Ensure that all events for the same account or service principal hash to the same operator instance so thresholds remain correct under parallel processing. Without consistent routing, partial counts can produce false negatives or inconsistent evidence windows.

Key takeaways

• Aggregation design affects security outcomes because boundary, state, and output are separate control choices.
• Event-preserving windows are better suited than summary rows when the triggering identity event must carry its own evidence.
• Security teams should make stateful detections explicit in the pipeline so identity telemetry stays auditable and actionable.

Key terms

• Trailing Window: A trailing window is a bounded slice of event history anchored to the current record. It evaluates what happened immediately before the event and is useful when the order of events matters more than a fixed calendar boundary.
• Event-Preserving Aggregation: Event-preserving aggregation keeps the original event as part of the output instead of replacing it with a summary row. This is essential when analysts need the triggering record, along with its context, for triage, investigation, or enforcement.
• Keyed State: Keyed state is the retained history associated with a specific entity such as a user, host, or service account. Correct keyed state ensures that related events are processed together so thresholds and sequence logic remain accurate under parallel execution.
• Trigger Predicate: A trigger predicate is the condition that decides whether a windowed pipeline should evaluate at all for a given event. It separates the act of retaining history from the act of emitting a result, which improves precision in stateful detections.

What's in the full article

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

• Line-by-line comparisons of Splunk, Cribl Stream, and TQL query shapes for stateful detection logic
• Worked examples showing how trailing windows preserve the successful login and its context
• Operator-specific details on TQL window size, trigger, and summarize semantics
• Migration considerations for teams translating existing search logic into pipeline-native detections

👉 TENZIR's full article shows the concrete pipeline patterns and migration details behind the examples here.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It gives identity and security practitioners a practical foundation for turning telemetry and lifecycle controls into operational policy.