Elastic's Security Labs team recently published the results of an architecture experiment that every SOC leader and detection engineer should study: they linked a single Elastic Security Serverless project to 100 other projects, ran the full prebuilt detection rule catalog from the central "origin" project, and let all telemetry ingest land in the linked downstream projects. The system held up. More importantly, the boundaries of where it deliberately does not reach are where the real design lessons live.
This matters because the architecture they validated — a single pane of glass for alert triage across dozens or hundreds of segregated telemetry domains — maps directly onto the operational reality of MSSPs, multi-tenant SOCs, holding-company security teams, and any enterprise with M&A-driven data fragmentation or sovereignty constraints. If your analysts are pivoting between five browser tabs to triage alerts across business units, this model is your exit ramp.
What Elastic Actually Tested
The design is straightforward in concept and demanding in execution:
- One origin project running Elastic Security Serverless hosts the detection layer and the analyst workflow.
- 100 linked projects hold the actual data — endpoint, network, cloud, and identity telemetry ingest locally in each project, satisfying data residency and tenant isolation requirements.
- Cross-project search lets the origin project execute detection rules and analyst queries against remote indices without moving the underlying data.
- The full prebuilt detection catalog (Elastic maintains 1,200+ prebuilt rules covering the MITRE ATT&CK matrix) was enabled from the origin, meaning detection content was managed in exactly one place.
The result: a single analyst in the origin project sees alerts generated from data physically residing in 100 separate projects, investigates with cross-project Timeline and ES|QL queries, and never needs credentials or context-switching into the downstream environments.
Why This Architecture Wins for Defenders
1. Detection content drift is eliminated. The most corrosive failure mode in distributed SOCs is rule divergence — tenant A is running last quarter's rule set, tenant B has local modifications nobody documented, and your coverage map is fiction. One origin, one catalog, one version of the truth.
2. Data never moves. For organizations under GDPR, HIPAA, PCI-DSS, or data-sovereignty mandates, cross-project search solves the legal problem architecturally. Raw telemetry stays in-region and in-tenant; only query results and alerts traverse the boundary.
3. Onboarding economics change. Adding the 101st project is a linking operation, not a detection-engineering project. For MSSPs this is the difference between scaling linearly in headcount and scaling sub-linearly.
4. Blast-radius reduction. Analysts triage from the origin without holding standing access to every downstream environment — a meaningful reduction in credential exposure if the SOC itself is targeted.
Where It Deliberately Does Not Reach
This is the part of the Elastic write-up worth reading twice, because the limitations define your residual architecture work:
- Response actions stay local. Cross-project search is a detection and triage fabric, not a response fabric. Host isolation, process kill, and file quarantine via Elastic Defend still execute against the project where the endpoint lives. Your IR runbooks must account for the pivot from central triage to local response.
- Data views and index patterns must be engineered, not assumed. At 100 linked projects, poorly governed index naming will break queries silently. Enforce a rigid index naming convention before you link project number two.
- Not every rule type behaves identically across the boundary. Indicator match rules, machine learning jobs, and entity-centric analytics have project-local state. Validate each rule class in your catalog against the cross-project pattern before assuming coverage parity.
- Query performance is a governance problem. One unbounded ES|QL query from the origin fanning out to 100 projects is a self-inflicted denial of service. Time-range discipline, field filtering, and saved-query standards are mandatory controls, not suggestions.
- Alert deduplication and correlation across projects remain analyst-visible seams. A single intrusion spanning three tenants will generate three alert streams. Your triage workflow needs explicit correlation logic — by attacker infrastructure, identity, or campaign tag — or you will investigate the same incident three times.
Executive Takeaways
1. Treat this as a validated reference architecture, not a lab curiosity. A 100-project fan-out with the full detection catalog running is beyond what most organizations will ever need. If you have been deferring SOC consolidation because of scale doubts, that excuse is gone. Commission a pilot: one origin, five linked projects, 90 days.
2. Separate your detection fabric from your response fabric in planning. The Elastic model centralizes triage but deliberately leaves response local. Map your containment actions — host isolation, account disablement, firewall changes — to the teams and credentials that own each downstream environment before an incident, not during one.
3. Fix index governance first. The single largest predictor of failure in federated search is inconsistent data naming. Mandate a standard index/schema convention (ECS-compliant) across all projects as a hard prerequisite to linking. Audit existing projects and remediate before connecting them.
4. Re-baseline your coverage map against one catalog. Consolidate detection rule management into the origin project and diff your current per-tenant rule sets against it. Expect to find both coverage gaps and zombie rules. Publish the unified coverage matrix against MITRE ATT&CK so leadership sees exactly what is and is not detected everywhere.
5. Impose query cost controls as a security control. Rate limits, maximum time ranges, approved saved searches, and analyst training on cross-project query cost are guardrails that keep the architecture stable under real triage load. A SOC platform that falls over during a major incident is worse than no consolidation at all.
6. Reassess whether your current SIEM contract is forcing bad architecture. Many organizations ship all data to one monolithic SIEM purely for triage convenience, paying egress, ingestion, and compliance costs to do it. If cross-project search removes the only reason for centralizing raw data, rerun the cost and risk math — the savings often fund the entire detection-engineering program.
Bottom Line
Elastic just demonstrated, at a scale few SOCs will ever approach, that centralized alert triage over decentralized telemetry is operationally sound. The architecture preserves data residency, eliminates rule drift, and collapses analyst context-switching — while keeping response authority and performance risk where they belong: explicitly designed, locally executed, and governed. If your 2026 SOC roadmap includes consolidation, multi-tenancy, or M&A integration, this pattern belongs at the top of the evaluation list.
Related Resources
Security Arsenal Managed SOC Services AlertMonitor Platform Book a SOC Assessment soc-mdr Intel Hub
Is your security operations ready?
Get a free SOC assessment or see how AlertMonitor cuts through alert noise with automated triage.