Detecting Campaign Overlap Across Tenant-Separated SIEMs

Multi-tenant SIEM architecture keeps every customer's logs walled off from every other customer's, on purpose. That same wall is why a security team watching one customer get hit by an attacker often has no way to know the same attacker just hit three other customers last week. Isolation and correlation are both correct requirements for a SIEM to have, and they pull in opposite directions. This piece breaks down why that tension exists, what it costs operationally, and the handful of architectural patterns practitioners actually use to work around it without breaking the wall.

Start with why the wall exists at all. Each customer's baseline behavior has to stay separate, or a detection rule tuned for Customer A starts throwing false positives against Customer B's traffic. Compliance adds another layer on top: US data residency rules, EU data protection law, and India's sovereignty requirements often can't be satisfied by one shared query plane, because they contradict each other in different jurisdictions at the same time. And there's a purely operational reason too: shared log processing means a noisy incident at one tenant, a flood of alerts or a misbehaving log source, can slow down analytics for everyone else sharing that infrastructure.

The blind spot follows directly from all three. If a threat shows up on one customer's network, the platform can't automatically go check every other customer for the same indicators. Per Huntsman Security, every cross-tenant check has to be built as a manual rule or alert, one at a time, case by case. That means an MSSP can know, with total confidence, that an attacker is running a campaign, because it already hit one client, and still get blindsided when the same attacker hits the next client on the list. The knowledge exists. The architecture just can't act on it without someone building the bridge by hand.

How organizations end up with multiple separated SIEM environments in the first place

Almost nobody sets out to run three or four SIEMs. It happens in pieces, and each piece makes sense on its own.

Cost is usually the first driver. Teams pair a cloud-native platform like Microsoft Sentinel or Google Chronicle with an older, on-prem tool like Splunk or IBM QRadar, because splitting ingestion between the two keeps the bill down. Then comes M&A: an acquired company shows up with its own SIEM already wired into its workflows, and ripping it out costs more than just leaving it running. Then regulation forces the last piece into place, when data residency law says logs have to physically sit in a specific country, so a single instance covering every region simply isn't legal.

Per CardinalOps, this fragmentation has a direct cost on detection coverage. Every log source in a split environment needs its own detections mapped to the MITRE ATT&CK framework, covering different tactics and techniques. Look at only one SIEM's rule set and you get a partial picture, and the gaps you can't see are exactly the gaps an attacker finds first.

Vendor lock-in made the whole mess stickier. Before OCSF (an open industry schema framework), every SIEM ran its own proprietary schema, Splunk's CIM, Microsoft's ASIM for Sentinel. Per Databahn AI, that meant the entire pipeline, every parser, every detection rule, every dashboard, was built around one vendor's data model. Migrating off it meant rebuilding all of it from scratch. So teams didn't migrate. They just kept adding.

These environments stay this way because the switching cost never gets cheap enough to justify the cleanup. That sprawl is the ground floor everything else in this piece sits on top of.

What cross-tenant campaign correlation requires technically

Detecting a coordinated campaign across tenants isn't the same job as writing more detection rules. It means spotting shared indicators, IP addresses, file hashes, domains, behavioral fingerprints, across environments that don't share a query plane and were built specifically so they couldn't.

Rarity is what makes an indicator worth chasing. A major DNS resolver showing up across a dozen alerts means nothing, it shows up everywhere. Per Conifers AI, it's the odd domain, the rare hash, the low-prevalence IP that turns up in more than one tenant's logs that's actually worth a second look. That's the signal buried in the noise.

The architecture has to hold two things true at once. Tenant isolation has to stay enforced at the data layer, not just in the application's login screen, so Customer A's logs stay genuinely out of reach for Customer B's analysts. At the same time, per Conifers AI, some of those overlapping indicators represent a threat hitting multiple clients at once, and catching that early is the whole point of running detection in the first place.

Rule health makes this harder than it sounds. Rules drift over time, log sources get misconfigured, field names change, parsers break quietly. Per CardinalOps, building cross-tenant correlation on top of broken per-tenant rules just produces false confidence, a correlation engine confidently comparing garbage across five environments instead of one.

None of this works without a shared schema across SIEMs that were never designed to talk to each other. OCSF version 1.4.0, released in January 2025, was a real step forward here, adding event classes for threat intelligence enrichment and vulnerability findings. Without that kind of common language, comparing indicators across a Sentinel deployment and a Chronicle deployment means custom normalization work for every single field.

How platform-native multi-tenancy handles the tension, and where it falls short

Microsoft Sentinel's answer is Azure Lighthouse, and it's a reasonable one with real limits. Lighthouse grants delegated cross-tenant access, and role-based access control gets fairly granular at the workspace and resource-group level, with Sentinel-specific roles built in. But there's no row-level or table-level isolation inside the actual log data. Once someone has delegated access, they can see everything inside that scope, there's no finer control at query time.

Audit trails compound the problem. Access logs sit inside each customer's own tenant rather than in one place, so proving what was accessed and by whom means running queries across a scattered set of per-tenant logs, something cross-workspace Log Analytics queries and the Activity Logs by Domain workbook support, but don't make effortless. Per ContraForce, managing this across a large roster of customer tenants eventually hits an operational ceiling where the model just doesn't scale cleanly anymore. Microsoft's newer GDAP framework (Granular Delegated Admin Privileges) improves on the older DAP model, but it brings its own role-provisioning overhead along with it.

Microsoft's unified security operations platform, in public preview from April 2024 and generally available from July 2024, tries to close some of this gap. It lets multi-tenant customers triage incidents across SIEM and XDR data in one interface, hunt across multiple tenants without needing to ingest XDR data separately, and automatically correlate incidents across SIEM and XDR sources for a fuller picture of multistage attacks. As of a June 2025 update from the Microsoft Tech Community, multi-workspace support is now generally available for both single and multi-tenant setups, a real improvement over the earlier one-workspace-per-tenant limit. Copilot for Security, Threat Intelligence, and Exposure Management aren't part of this multi-tenancy yet, though. And it needs Azure B2B collaboration for delegated access, since GDAP only covers Defender data, not Sentinel data directly. Lighthouse is still required for secondary workspace queries.

Google's Chronicle (now Google Security Operations) takes a different approach: logical separation through labels rather than physical separation of infrastructure. DataRBAC, announced generally in June 2024, uses scopes, log types, namespaces, ingestion labels, custom searches in Chronicle's Unified Data Model, to control what any given user can query. Detection rules can run globally across all tenant data or get bound to one scope only.

Maintenance is the catch. Scoped rules have to be duplicated for every client, and for a while it wasn't even clear how curated, built-in rules behaved: did they run globally, or need per-scope copies too? A community thread running from June and July 2024 through August 2026 worked through this in public, eventually clarifying how curated, built-in rules behave across scopes. Teams can also build a client identifier into custom fields and use it as a match variable in detection rules, to stop cross-client bleed inside a single rule, but that's a manual workaround that has to be engineered into every rule individually, not something the platform does for you.

None of these platforms automatically surfaces campaign overlap on its own. They manage isolation well and give some centralized visibility, but the actual work of spotting a campaign across tenants still has to be built above the SIEM layer, by someone.

Architectural patterns practitioners use to detect campaign overlap without violating tenant boundaries

A few patterns have emerged to bridge that gap without tearing down the wall.

One is the federated control plane model, laid out by Databahn AI in its Beacon Architecture in November 2025. One control plane governs many isolated data planes underneath it. Each tenant keeps its own routing logic, volume policy, and SIEM integration, running independently, but all of them inherit global policy and governance from the plane above. Because all data planes inherit policy from the control plane above them, detection updates can propagate across the portfolio centrally, rather than getting hand-built into each tenant SIEM separately.

CardinalOps takes a related but distinct approach: federated detection posture management. A layer sits above the individual SIEMs, mapping every detection across every instance to MITRE ATT&CK and producing one aggregate coverage view. That layer catches broken rules, misconfigured sources, changed field names, parser drift, before they turn into exploitable gaps, and it decides where alerts should route for organization-wide correlation and incident response, rather than trying to force the correlation to happen inside the SIEM itself.

Threat intelligence tiering matters just as much as the architecture around it. Cross-tenant detection lives or dies on the quality of the intelligence feed underneath it, a massive indicator list just drowns the rare signal in noise. Filtering feeds down to what's actually relevant to a given client's industry, geography, and tech stack cuts that noise before it ever reaches an analyst. And the rarity logic from earlier applies here directly: one tenant seeing an odd indicator once is routine, several tenants seeing the same odd indicator around the same time is a campaign.

Dedicated multi-tenant detection platforms, Vectra AI is one named example, bake this correlation in at the platform layer instead of leaving it to SIEM-level workarounds. Per MSSP Alert, that means tenant isolation paired with centralized management, per-tenant cross-domain threat correlation, and consistent service-level enforcement, plus automated reporting and shared intelligence across the whole tenant base.

The clearest sign this problem has matured into a real product category: BlueVoyant LLC holds US Patent 12519823, covering a method for provisioning and updating SIEM artifacts across multiple tenants. An industry patenting a solution for a recurring problem has moved past a bespoke engineering fix.

Every one of these patterns leans on the same prerequisite: a shared schema. OCSF adoption is what makes cross-SIEM aggregation affordable in the first place. Without it, each of these approaches needs its own custom normalization work before any correlation can even start.

What the operational tradeoffs look like when choosing between these approaches

The tradeoff runs on one axis. Tighter tenant isolation means more manual work to surface cross-tenant signals, and the more that work gets automated, the more carefully that automation has to be audited to make sure it never crosses the line it's supposed to respect.

Scale is where this actually bites. Manually replicating rules per tenant works fine with a handful of customers. Per Databahn AI, the complexity cost grows faster than the revenue a growing customer base brings in, and the operational ceiling shows up well before the architecture technically breaks.

There's a real cost argument for consolidation, too. Per ContraForce, bundled multi-tenant platforms typically run 30 to 50 percent cheaper per customer than stacking separate single-tenant tools. That saving only holds up if the platform actually enforces isolation at the data layer, not just at the login screen, otherwise the savings come with a hidden liability attached.

Anything requiring rule duplication per tenant, Chronicle's scoped-rule model, manual propagation across federated SIEMs, builds up maintenance debt over time. Rules drift apart across tenant copies, and detection coverage that looked identical on day one quietly diverges by month twelve.

Audit trails matter here too, maybe more than anywhere else. Proving zero cross-tenant data leakage isn't optional, it's the baseline expectation from any customer and any regulator. Platforms that scatter audit logs across individual tenants, the way Lighthouse does, turn that proof into its own separate operational job.

The pattern across every functional approach here points the same direction: campaign correlation belongs above the SIEM, at a layer that can compare stripped or hashed indicators across tenants without ever touching raw log data directly. The real architectural decision isn't whether to build that layer, it's whether to build it or buy it.

For teams without a dedicated security engineering staff, the honest takeaway is that building this from scratch, custom fields, scoped rules, manual intelligence propagation, is a heavy lift for a small team to carry alone. The more durable fix is cutting down the number of separate data planes that need correlating in the first place, by choosing platforms that already unify device management, identity, and detection under one roof. Fewer walls to build bridges across is still the simplest answer available.