As reported by Elastic Security Labs, the team linked one Elastic Security Serverless project to 100 others and ran approximately 2,100 prebuilt detection rules from the origin project, with all ingest landing in the linked projects. The search layer held up under that load, and the post details which query patterns stay fast at scale — and where the project boundary intentionally stops.

Key Insight: As reported by Elastic Security Labs, the team linked one Elastic Security Serverless project to 100 others and ran approximately 2,100 prebuilt detection rules from the origin project, with all ingest landing in the linked projects.

This is more than a benchmark. It is a credible validation of a centralized SOC model that many organizations have been building toward理论上 but hesitated to operationalize. The multi-tenant SOC dilemma — consolidate for visibility or isolate for boundaries — has driven MSSPs, global enterprises, and holding companies into fragmented detection stacks where rule drift becomes inevitable. Cross-project search (CPS) on Serverless directly addresses that fragmentation.

Why the Architecture Matters

The key design decision is asymmetric: the origin project reads across linked projects but never writes into them. Alerts, cases, and investigations all land on the origin. Each linked project retains its own data, lifecycle, and isolation. This is the right boundary for centralized triage because it preserves tenant separation — critical for MSSPs with contractual data isolation requirements — while giving analysts a single queue and a single rule set.

The read-only boundary across linked projects is not a limitation. It is the security control that makes the model viable for regulated and multi-tenant environments.

For organizations running 12 different Elastic deployments with slightly different detection rule copies — a pattern Elastic accurately describes — CPS eliminates rule drift by design. One rule on the origin covers every linked project. That alone reduces detection engineering overhead significantly.

What Defenders Should Watch

The article notes that most learnings were about query shapes and rule sizing at scale. That is the real operational signal. Running 2,100 rules across 100 projects is not the same as running 200 rules across 5 projects. ES|QL query patterns matter, and defenders adopting this model should expect to tune their detection catalog for cross-project performance rather than assuming single-project query efficiency translates linearly.

The deliberate limitations — where CPS does not reach — are equally important. The post highlights these boundaries, and security architects need to map them against their investigation workflows before committing. If your response actions require writing back to linked projects, CPS alone will not close that loop.

Broader Implications

This model signals a shift in how Serverless security platforms are positioning themselves for MSSP and large-enterprise use cases. The industry has been moving toward centralized detection with decentralized data for years, but few platforms have stress-tested it at this scale publicly. Elastic's transparency about performance characteristics and limitations gives defenders something rare: an architectural decision backed by evidence rather than marketing.

Shield53 Recommendations

Broader Implications
Map your investigation lifecycle before adopting CPS. Identify which steps require write-back to source projects. If response actions need to modify data in linked projects, plan complementary automation or API-based bridges.
Pilot with a representative rule subset first. Do not port your entire 2,000-rule catalog on day one. Start with high-volume detection rules across a small number of linked projects and measure query latency before scaling.
Standardize on ES|QL patterns early. Elastic recommends specific query shapes for cross-project performance. Train your detection engineering team on these patterns before migration to avoid rework.
Establish origin project governance. Since all alerts and cases land on the origin, define access controls, alert routing, and case ownership policies that reflect which linked project each alert originated from.
Document the isolation boundary for auditors. If you operate in regulated or multi-tenant contexts, the read-only CPS boundary is a control you will need to explain. Prepare architecture documentation that shows data residency and write paths clearly.
Consolidate detection rule management. If you are currently maintaining parallel rule sets across multiple Elastic deployments, use CPS as the trigger to collapse to a single source of truth on the origin project.

Centralized triage with decentralized data is the architecture most SOCs need but few have validated at scale. Elastic's 100-project test provides the evidence defenders should require before betting their operations model on it.