As reported by Elastic Security Labs, the company has detailed the internal architecture behind its Entity Store v2 — a system that moves beyond flat, snapshot-based entity records toward continuously enriched, living profiles maintained by background jobs called maintainers. Each maintainer owns a specific facet of an entity record: relationship building, identity resolution, or risk scoring. Introduced in Elastic v9.4 and rebuilt on Elasticsearch Query Language (ES|QL), this architecture represents a meaningful shift in how SIEM platforms can handle the identity problem that plagues modern security operations.
Why Entity Resolution Matters More Than Ever
The core security challenge Elastic is addressing here is not new, but it has become acute. Today's attackers rarely compromise a single account in isolation. They move laterally across identities — a cloud service account here, an on-prem AD account there, a SaaS admin login elsewhere — and traditional SIEMs that treat each as a separate record fundamentally fail to connect the dots. Analysts end up manually pivoting across logs, reconstructing what a well-designed entity store should surface automatically.
What Elastic describes — resolving scattered accounts to a single user identity and maintaining that resolution over time — is the foundation that everything downstream depends on. Risk scoring, behavioral baselines, and AI-assisted reasoning are only as reliable as the entity records underneath them. Garbage in, garbage out applies here with particular force.
The Architectural Shift: From Transforms to Maintainers
The move from Elasticsearch transforms (Entity Store v1) to ES|QL-based maintainers (v2) is more than an engineering optimization. It reflects a broader industry trend toward composable, continuously-running enrichment pipelines rather than batch-oriented rebuilds. The key implications for defenders:
Who Should Pay Attention
Organizations running Elastic Security at scale — particularly those with hybrid environments spanning on-prem infrastructure, multiple cloud providers, and SaaS applications — stand to benefit most from this architecture. The identity resolution problem scales with environment complexity, and environments with overlapping account namespaces (e.g., the same username in different directories) are where misresolution risk is highest.
Security teams evaluating SIEM platforms more broadly should treat this article as a benchmark. If your current platform cannot maintain persistent, inspectable entity records with continuous identity resolution, you are likely doing manually what should be automated — and you are slower at detection as a result.
Shield53 Recommendations
- Audit your current entity resolution capabilities. Map how your SIEM connects user identities across directories, cloud providers, and SaaS apps. Identify blind spots where the same human operates under unlinked accounts.
- Validate entity record quality before trusting downstream analytics. If you use Elastic, review the companion post on entity record quality. Misresolved identities corrupt risk scores and behavioral baselines silently.
- Plan for ES|QL adoption. If you are on Elastic Security and have not evaluated Entity Store v2, prioritize testing in a non-production environment. Understand how maintainer cadence affects detection latency for your specific telemetry sources.
- Build detection rules that leverage entity relationships. Move beyond single-event detections. Use the entity graph to detect anomalous relationship patterns — a user accessing a host they have never touched, a service account logging in interactively, a device associated with multiple users simultaneously.
- Establish an entity governance process. Assign ownership for reviewing and correcting entity resolutions, particularly for high-privilege accounts where misresolution has the greatest blast radius.
The entity layer is where detection quality is won or lost. Every alert, every risk score, and every AI-assisted conclusion traces back to whether your platform correctly knows who is who.