Join our Newsletter — 33% off our NHI Course

What do teams get wrong about enrichment at query time?

Teams often assume query-time enrichment is good enough because the data is eventually available. In practice, it arrives after the expensive storage decision has already been made, and after the analyst needed it most. That creates slower investigations, more tool switching, and weaker routing decisions. The result is forensics, not real-time defense.

Why This Matters for Security Teams

Query-time enrichment sounds efficient because it preserves a leaner event store and promises “always current” context when the analyst asks for it. The practical failure is that enrichment is often needed before a query ever happens: routing, correlation, containment, and triage decisions are made upstream, while the event is still moving through pipelines. By the time enrichment lands, the question has shifted from “what should we do now?” to “what happened?” That is a storage and investigation model, not a defense model. Current guidance from the NIST Cybersecurity Framework 2.0 emphasizes timely detection and response, which depends on context being available at decision time, not after the fact. NHI Management Group’s Ultimate Guide to NHIs also shows why this matters operationally: only 5.7% of organisations have full visibility into their service accounts. In practice, many security teams discover the cost of late enrichment only after a containment window has closed, rather than through intentional design of the detection path.

How It Works in Practice

Effective enrichment should be treated as a control-plane function, not a post-query convenience. The event or alert needs enough identity, asset, and trust context at ingest time to support filtering, priority, and routing. That usually means joining on workload identity, secret source, ownership metadata, business criticality, and environment before data lands in the analyst workflow. If those joins happen only at query time, downstream decisions inherit delay and inconsistency.

Teams that handle this well usually separate enrichment into two layers:

  • Static enrichment at ingest for stable attributes such as asset owner, NHI type, and environment.
  • Dynamic enrichment at decision time for volatile fields such as current privilege state, active session, or recent secret rotation.
  • Policy-based routing that can use the enriched context immediately, rather than waiting for a retrospective search.

This is where current guidance converges with identity practice. The Ultimate Guide to NHIs highlights how often organisations lack visibility into service accounts and secrets, which makes late enrichment especially fragile. Query-time enrichment can still be useful for investigation and retrospective hunts, but it is a poor substitute for enriched telemetry that supports real-time containment. The NIST Cybersecurity Framework 2.0 also reinforces that response outcomes improve when data quality and decisioning are built into the workflow, not bolted on after an alert is opened. These controls tend to break down in high-volume environments where events arrive faster than external lookup systems can answer, because enrichment latency becomes alert latency.

Common Variations and Edge Cases

Tighter real-time enrichment often increases pipeline cost, lookup complexity, and schema maintenance, so organisations have to balance analyst speed against operational overhead. The best practice is evolving, especially where teams mix SIEM, SOAR, data lakes, and identity stores that were never designed to share a common event model.

A few edge cases matter:

  • High-churn cloud workloads can change ownership or privilege faster than enrichment jobs refresh, making query-time lookups misleading.
  • Air-gapped or heavily segmented environments may not support live calls to authoritative sources, so staged enrichment at ingestion becomes more reliable.
  • For low-severity hunting, query-time enrichment is often acceptable because the goal is depth of analysis, not immediate containment.
  • For NHI-related alerts, static metadata alone is rarely enough, because the most important question is usually whether the credential or workload was valid at the exact time of activity.

Guidance is not universal here. Some organisations can tolerate delayed enrichment for compliance reporting, but not for incident response or automated blocking. The practical rule is simple: if the context affects a decision that must happen now, enrichment must already be present now. If the decision can wait, query-time enrichment is usually sufficient.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

OWASP Non-Human Identity Top 10 and CSA MAESTRO address the attack and risk surface, while NIST AI RMF, NIST CSF 2.0 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.

Framework Control / Reference Relevance
OWASP Non-Human Identity Top 10 NHI-01 Identity visibility is critical when enrichment depends on accurate NHI context.
CSA MAESTRO AIC-03 Agent and workload context must be available at decision time for automated routing.
NIST AI RMF GOVERN Governance requires timely, trustworthy context for operational AI and security decisions.
NIST CSF 2.0 DE.CM-1 Monitoring depends on context arriving fast enough to support detection and response.
NIST Zero Trust (SP 800-207) PR.AC-1 Zero Trust decisions need current identity and trust context, not delayed lookups.

Map enrichment fields to NHI inventories so critical identity context is available before analysts query it.