Building Detections That Span Domains

A ransomware crew rarely announces itself with a single, obvious alert. It shows up as a slightly odd sign-in from a new device, a PowerShell process that spawns a network scanner, a service account touching a cloud storage bucket it has never touched before, and a burst of outbound traffic to a domain registered last week — four whispers across four different tools, each individually beneath the noise floor. Detection engineering's hardest and most valuable job is stitching those whispers into a single, high-confidence signal before the encryption starts, and that means building detections that deliberately span endpoint, network, identity, and cloud telemetry rather than living inside any one of them.

The domain-silo problem in modern SOCs

Most security operations centers did not choose to be siloed — they grew that way. Endpoint detection and response (EDR) came from one lineage of vendors, network detection and response (NDR) from another, identity threat detection from a third, and cloud security posture and workload protection tools from a fourth. Each category matured independently, optimized its own data model, and shipped its own console. The result is a SOC that has excellent visibility into four narrow columns and almost no native visibility into the diagonal lines that connect them, which is exactly where modern intrusions live.

The practical symptom is alert fragmentation. A single attacker action — say, a compromised credential being used to pivot from a workstation to a cloud administration console — generates an EDR alert for the initial process execution, an identity alert for anomalous authentication, and a cloud alert for a suspicious API call, each landing in a different queue, scored by a different engine, and triaged by a different analyst (or, more commonly, by the same overloaded analyst context-switching between three UIs). Mean time to detect suffers not because the data was missing but because nothing was responsible for assembling it into a story.

This is also an economic problem. Every domain-specific tool competes for a finite analyst attention budget, and false-positive rates compound multiplicatively across tools rather than canceling out. A SOC running four best-of-breed point products each tuned to a 2% false-positive rate does not get a 2% blended rate — it gets four independent 2% streams that analysts must reconcile by hand, which in practice pushes effective noise well above what any single tool reports in its own dashboard. Vendors selling "detection coverage" by domain count are selling surface area, not signal.

The fix is not simply buying a platform labeled XDR and assuming correlation happens automatically. It requires deliberate architecture: a shared data model, a shared identity graph, a shared time base, and detection logic that is explicitly written to reason across domains rather than detection logic from four vendors dumped into one screen with a shared login. The rest of this article is about how to build that deliberately, with the specific mechanisms, trade-offs, and worked examples a hands-on team needs to make the call between building, buying, or blending. Our own view on the architecture pattern is laid out in more depth on the XDR detection and response page, but the principles here apply regardless of which vendor stack you run.

What "spanning domains" actually means: a reference architecture

A cross-domain detection stack has five layers, and skipping any one of them is where most XDR projects quietly fail. The layers are collection, normalization, correlation, detection, and response — and critically, the correlation layer sits between normalization and detection as a distinct engineering concern, not a byproduct of dashboarding.

Collection is the layer most teams already have covered: EDR agents on endpoints, network sensors or flow exporters, identity provider logs from Entra ID or Okta, and cloud control-plane logs from CloudTrail, Azure Activity Log, or GCP Audit Log. The mistake at this layer is treating volume as coverage. A cross-domain detection strategy needs breadth of log type more than depth of any single type — a thin slice of authentication logs, DNS logs, process creation events, and cloud API calls will catch more real intrusions than a firehose of full packet capture with no identity context.

Normalization is where most homegrown projects stall. Every source speaks a different schema: Windows Sysmon event IDs, Zeek connection logs, Okta system log actions, AWS CloudTrail event names. Without a common schema, correlation logic has to be rewritten per source pair, which does not scale past two or three integrations. The industry has mostly converged on Open Cybersecurity Schema Framework (OCSF) or a vendor-proprietary equivalent as the common tongue; the specific schema matters less than committing to exactly one and mapping every source into it consistently, including consistent field semantics for actor, target, action, and outcome.

Correlation is the layer that actually spans domains, and it operates on two axes simultaneously: entity identity (the same user, host, or workload appearing under different names in different logs) and time (events that are causally related but arrive on different clocks, with different collection latencies). Get correlation right and detection logic becomes simple pattern matching over a unified event stream. Get it wrong and no amount of detection engineering downstream can compensate, because the engine is matching against fragments instead of a coherent narrative.

Detection logic then operates on the correlated stream using whatever mix of deterministic rules, sequence detection, graph analytics, and machine learning scoring fits the use case — covered in depth in a later section. Response and orchestration closes the loop, translating a cross-domain detection into a case, an enriched analyst workspace, and increasingly an agentic remediation action, which is the pattern we describe in the agentic SOC architecture: detections that not only fire but trigger investigation and containment steps without waiting on a human to open five tabs.

Telemetry normalization: the unglamorous foundation

Normalization gets skipped in roadmap conversations because it produces no dashboard, no alert, and no demo-able feature — it is pure plumbing. It is also the single highest-leverage investment in a cross-domain detection program, because every downstream detection's precision is bounded by how well the underlying entities were resolved.

Entity resolution across domains

The core technical challenge is that the same real-world entity has a different identifier in every domain's logs. A user is a UPN in Entra ID logs, a SID in Windows Security event logs, an ARN-linked IAM role in AWS CloudTrail (if federated), and possibly a completely separate service account string in an application log. A host is a hostname in DNS logs, an IP address in NetFlow, an agent GUID in EDR telemetry, and a MAC address in DHCP logs, and any of those can change (DHCP lease renewal, VPN reassignment, container rescheduling) faster than your correlation window.

Production-grade entity resolution needs three mechanisms working together. First, authoritative identity mapping: pull directory data (Active Directory, Entra ID, Okta) as a standing reference table that maps UPN, SID, email, and device object IDs to a single canonical entity ID, refreshed on a short interval since offboarding and role changes happen daily. Second, dynamic binding: maintain a rolling table of IP-to-host and IP-to-user bindings built from DHCP, VPN, and authentication logs, with explicit time validity windows — an IP address means nothing without a timestamp attached to when it belonged to whom. Third, probabilistic fallback: for the residual cases where deterministic mapping fails (NAT'd egress, shared kiosk machines, ephemeral cloud functions), a confidence-scored fuzzy match is better than silently dropping the event, as long as the confidence score propagates downstream so detection logic can discount low-confidence links appropriately.

Time alignment

Cross-domain correlation is fundamentally a temporal exercise, and clocks lie in more ways than engineers expect. Endpoint agents batch and buffer events, sometimes for minutes, before uploading. Cloud audit logs have documented, non-trivial delivery lag — CloudTrail can take up to fifteen minutes to deliver events under normal load and longer under throttling. Network sensors time-stamp at capture, which can trail the actual event by the sensor's own processing queue depth. A correlation window built assuming near-real-time delivery across all four domains will systematically miss the slowest domain's events, silently degrading detection recall in a way that is invisible until someone audits a missed incident after the fact.

The practical fix is to separate "event time" (when the action actually happened, as best it can be reconstructed) from "ingest time" (when your pipeline saw it), tag every normalized event with both, and build correlation windows generous enough to absorb the slowest source's typical delivery lag — commonly 15 to 30 minutes for cloud control-plane sources — while using event time, not ingest time, for the actual sequence-ordering logic inside a detection rule. Detections that only look backward from ingest time will misorder cause and effect when one domain's data arrives late, and a sequence detection that requires "authentication anomaly followed by data exfiltration" can silently invert if the identity log is the late arrival.

Identity as the connective tissue across domains

If normalization is the plumbing, identity is the wire that actually carries the cross-domain signal. Endpoint, network, and cloud telemetry are all, ultimately, records of something an identity did or something that happened to a resource an identity controls. This is why identity threat detection and response has become the fastest-growing subcategory inside XDR programs: it is the one domain that every other domain's events can be joined against.

A mature cross-domain program builds what is effectively an identity graph — a live model connecting human users, service accounts, machine identities, roles, group memberships, and the entitlements those roles carry, refreshed continuously from the identity provider, the cloud IAM plane, and privileged access management systems. Every normalized event, regardless of source domain, gets annotated with the identity that initiated it and that identity's current privilege level at the time of the event, not a stale snapshot from onboarding. This is the mechanism that turns "process X spawned process Y on host Z" (an endpoint fact) and "role R assumed a new session in account A" (a cloud fact) into a single sentence: "user U, who normally only touches host Z, used a credential to assume role R they have never used before."

The identity graph also enables privilege-aware risk scoring, which is the single biggest lever for cutting false positives in cross-domain detection. An anomalous PowerShell command executed by a helpdesk technician's day-to-day account is meaningfully different from the identical command executed by a domain admin service account that normally only runs scheduled tasks at 2 a.m. Without the identity graph, both events score identically on process telemetry alone. With it, the second event inherits a materially higher prior risk score before any behavioral anomaly logic even runs, which is precisely the effect a well-designed identity security and PAM layer is meant to deliver into the broader detection pipeline, and it is a large part of why identity-centric architecture shows up as a standalone pillar in our identity and PAM solution rather than being bolted on as an afterthought to endpoint detection.

Service accounts and machine identities deserve their own callout because they are where cross-domain detection most often fails in practice. They authenticate constantly, have broad and often poorly documented entitlements, do not use MFA, and their "normal" behavior baseline is far noisier than a human's — a CI/CD service account might legitimately touch dozens of hosts and cloud resources per hour. Treating service accounts with the same anomaly thresholds as human users produces either constant false positives or, more dangerously, thresholds so loose that a compromised service account credential (a disproportionately common initial access vector in cloud breaches) sails through undetected. Cross-domain identity models need a separate behavioral baseline class for non-human identities, built from a longer observation window and keyed to the specific automation pattern, not a generic user-anomaly model repurposed.

Building cross-domain detection logic: correlation patterns

Once entities and time are unified, detection engineering becomes a question of which correlation pattern fits which threat behavior. Four patterns cover the large majority of production cross-domain detections, and picking the wrong one for a given use case is the most common engineering mistake in this space.

Sequence correlation

The simplest and most explainable pattern: a defined, ordered sequence of events across domains within a time window, where each step raises confidence in the ones before it. Example: (1) identity domain — a sign-in from a new device passes MFA but with an unusual authentication method fallback; (2) endpoint domain — within thirty minutes, that device runs a credential-dumping tool signature or LSASS access pattern; (3) network domain — within the next hour, that host initiates SMB connections to more than a defined threshold of internal hosts it has never contacted; (4) cloud domain — a cloud API call using credentials associated with the same user account occurs from an IP not previously associated with that user. Each step alone is low-to-medium confidence; the ordered sequence across four domains within a bounded window is high confidence lateral movement with a credential-theft prelude, and this is a canonical detection pattern behind alert-triage systems like the one described in AI-driven XDR alert triage.

Graph-based correlation

Sequence correlation assumes you know the order in advance. Graph-based correlation instead builds a live graph of entities (users, hosts, processes, cloud resources) and relationships (authenticated-as, connected-to, spawned, accessed), then looks for structural anomalies — unusually short paths between a low-privilege entry point and a high-value asset, unexpected new edges connecting previously disconnected clusters, or nodes whose degree (number of connections) spikes relative to their historical baseline. This pattern excels at catching attack techniques that do not follow a fixed playbook, such as living-off-the-land lateral movement, because it does not require pre-defining the sequence — it flags the shape of the activity rather than a specific script of steps.

Statistical and peer-group anomaly correlation

This pattern establishes a behavioral baseline per entity (or per peer group of similar entities — same role, same department, same team) across multiple domains simultaneously, then flags multivariate deviations. The key cross-domain trick is joint anomaly scoring: a login from an unusual location is mildly anomalous on its own; a login from an unusual location combined with an unusual data volume egress from a cloud storage bucket the same identity touched twenty minutes later is a joint anomaly whose combined probability is far lower than either marginal anomaly, and that combined improbability is the actual signal worth alerting on. Building this correctly requires the detection engine to compute joint, not independent, probabilities — a naive implementation that just sums two domains' individual anomaly scores will over-alert on entities that are mildly unusual in everything and under-alert on entities that are precisely, narrowly unusual in the way that matters.

Static rule chaining with dynamic context

The most operationally common pattern in practice is not pure ML — it is deterministic rules from each domain, individually well-tuned, that get chained by a correlation engine using shared entity IDs and a scoring rubric. This is less academically elegant than graph or statistical methods but is far easier to explain to an analyst, far easier to tune when it misfires, and far easier to audit for compliance purposes. Most mature SOCs run this as the primary detection layer and layer graph or statistical methods on top for the harder-to-specify threats, rather than replacing rules outright.

From correlation to detection: choosing and combining engines

Once correlation patterns produce a unified, entity-resolved event stream, the actual detection logic runs on top of it, and the engineering question shifts to which computational engine should own which class of detection. In practice, three engine types coexist in every mature program, and the skill is routing the right use case to the right engine rather than betting the program on one.

Deterministic correlation rules — expressed as sequence-over-time conditions with entity joins — remain the backbone for known, well-characterized techniques mapped to MITRE ATT&CK. They are fast to write, cheap to run, trivial to explain in an incident report, and easy for a junior analyst to validate by re-reading the rule logic. Their failure mode is technique drift: attackers change tool signatures and command-line syntax faster than rule libraries get updated, so a rules-only program has a half-life on its detection coverage that requires continuous content engineering investment, not a one-time build.

Graph analytics engines maintain the live entity-relationship graph described above and run structural queries against it — shortest-path analysis from any internet-facing asset to crown-jewel systems, connected-component analysis to catch lateral spread, and centrality scoring to flag entities that have suddenly become unusually well-connected. These are computationally heavier and need a graph database or graph-capable stream processor, but they catch the attacker behaviors that specifically try to avoid triggering any single well-known signature.

Machine learning scoring — typically gradient-boosted models or sequence models trained on labeled historical incidents plus unsupervised anomaly detectors for the peer-group baselines described earlier — adds a probabilistic layer that catches gradual drift and multivariate combinations no human would think to write a rule for. The trade-off is explainability and drift management: every ML-scored detection needs a feature-attribution layer (which inputs drove the score) surfaced to the analyst, or it becomes a black box nobody trusts enough to act on, and every model needs a retraining cadence and a shadow-mode validation period before any threshold change goes live in blocking mode.

The architecture that works in production routes low-latency, high-confidence, well-understood techniques to deterministic rules; routes novel-path and living-off-the-land detection to graph analytics; and routes slow-burn, multivariate, hard-to-specify behavior to ML scoring — then fuses all three into one final risk score per entity per time window, rather than presenting analysts with three separate scores to reconcile by eye. This fusion step is itself a piece of engineering that deserves explicit ownership; treating it as "just add up the numbers" reproduces the multiplicative false-positive problem described earlier, just one layer further downstream.

Worked example: a cross-domain attack chain, step by step

Concrete detail matters more than architecture diagrams for engineers who have to implement this, so walk through a realistic intrusion end to end and see exactly what each domain contributes and where single-domain detection would have failed.

Stage one, identity. A user's credentials, phished the previous week, are used to sign in. MFA is satisfied through a fallback SMS method the user has used before, so the identity provider's own risk engine scores this as low-to-medium risk — it is a known device fingerprint reused, but from an ASN the account has never authenticated from. In isolation, this generates, at best, a low-priority identity alert that a busy analyst reasonably deprioritizes; identity providers generate this class of alert dozens of times a day per thousand users.

Stage two, endpoint. Eighteen minutes later, EDR telemetry on the user's laptop shows a process accessing LSASS memory with a read pattern consistent with credential dumping, followed by a renamed system binary being executed from a temp directory. Many EDR products would flag this at medium-to-high severity on endpoint signal alone — but plenty of legitimate IT tooling and some EDR agents themselves touch LSASS, so a meaningful fraction of these fire as false positives in isolation, and analysts learn to deprioritize them at scale, especially at organizations running above a certain per-analyst alert volume.

Stage three, network. Within the next forty minutes, the same host's east-west traffic shows SMB connections to eleven internal hosts it has never contacted in ninety days of baseline, a fan-out pattern with a moderate NDR anomaly score on its own but well below most organizations' network alerting threshold, because internal SMB traffic volume is naturally noisy and a moderate fan-out is common during routine IT operations too.

Stage four, cloud. Roughly an hour after the initial sign-in, a cloud API call assumes an administrative role using credentials tied to the same identity, from an IP address that has never been associated with that user, and modifies a storage bucket's access policy to permit broader read access. Cloud control-plane anomaly detection on this single call, evaluated alone, is a coin flip between "role change during a legitimate cloud migration project" and something malicious — cloud environments have enough legitimate administrative churn that this event alone rarely clears an automated response threshold.

Individually, all four events sit in the amber zone: worth logging, not worth waking anyone up for, and in most single-domain-tool environments they would land in four separate queues, get triaged separately by whoever is on shift for that tool, and very possibly never be connected at all — the median time between stage one and stage four in real incident data is often measured in hours, well within a single analyst shift, but across four different consoles the correlation depends entirely on human memory and habit. Correlated through a shared entity ID and a bounded, event-time-ordered window, the chain is a textbook credential-theft-to-cloud-privilege-escalation pattern that should trigger an automated high-severity case, immediate session revocation for the identity, endpoint isolation for the host, and a hold on the cloud policy change, ideally before stage four's policy modification takes effect at all if stages one through three fire fast enough. This is the concrete value proposition of cross-domain detection stated without marketing language: it converts four amber signals that individually sit below action threshold into one red signal that clears it, and it does so measured in tens of minutes rather than the hours or days a human correlating four consoles by hand typically takes.

Alert triage, scoring and SOC workflow integration

Detection logic that spans domains is only half the job; the other half is making sure the resulting case actually reaches an analyst in a form they can act on quickly, and that automated response has clear, bounded authority to act without a human in the loop for well-understood cases.

Case-level scoring should combine three inputs: the correlation engine's confidence (how tightly the cross-domain events fit a known or structurally anomalous pattern), the identity graph's privilege context (what the involved identity or asset can actually reach), and asset criticality (is the target a domain controller, a crown-jewel database, or a print server). A high-confidence correlation against a low-privilege identity touching a non-critical asset should route differently — lower urgency, possibly automated remediation without analyst review — than a medium-confidence correlation against a privileged identity touching a critical asset, which should page a human immediately even if the correlation confidence alone would not warrant it. Flattening these three inputs into a single severity number, which is what many single-domain tools do by necessity because they only see one of the three inputs clearly, is a common source of both alert fatigue and missed escalations.

The analyst-facing case should present the correlated timeline, not four separate alert tiles requiring manual assembly: one scrollable, entity-anchored view showing the identity event, the endpoint event, the network event, and the cloud event in event-time order, with the entity graph connecting them rendered alongside so the analyst can see at a glance why the system believes these four disparate facts are the same story. Every minute an analyst spends manually reconstructing a timeline across four tools is a minute not spent on judgment calls only a human can make, and it is the specific inefficiency that cross-domain detection platforms exist to eliminate; this is the operating model behind agentic SOC workflows, where the assembly and initial containment steps are handled automatically and the analyst is brought in at the decision point, not the data-gathering point.

• Auto-close with audit trail for low-confidence, low-criticality correlations that match a well-understood benign pattern (e.g., known IT automation touching a defined asset list) — but always log the decision path for later audit, never silently drop.
• Auto-contain, notify for high-confidence correlations against non-critical assets: isolate the endpoint, revoke the session, then notify the analyst asynchronously rather than blocking on acknowledgment.
• Page and hold for approval for any correlation touching a critical asset or a privileged identity, regardless of confidence score, because the cost of a false negative there is categorically higher than the cost of an analyst's five minutes.
• Escalate to threat hunt for structurally anomalous graph patterns that do not match any known sequence — these are exactly the cases where a human's pattern recognition still outperforms the automated engine, and routing them to hunt rather than forcing a binary alert/no-alert decision preserves that value.

This triage model only works if it is fed by the integrated telemetry described earlier in the article; it is also the reason cross-domain detection and IT operations tooling increasingly converge in practice, since the same normalized, entity-resolved event stream that powers security detection is equally useful for operational anomaly detection, which is the logic behind pairing security and operations telemetry under one roof, as in the integrated NOC-SOC model.

Metrics that matter: measuring cross-domain detection effectiveness

Domain-specific tools each report their own metrics — EDR detection rate, network anomaly count, identity risk score distribution — and none of those individually tells you whether the cross-domain program is working. A small, deliberately chosen set of program-level metrics does.

Cross-domain correlation rate: of all high-severity cases opened, what percentage involved events from two or more domains versus a single domain. A healthy, mature program typically sees this rate climb over time as correlation logic matures and entity resolution improves; a flat or declining rate despite adding new detection content is usually a sign that normalization or entity resolution has quietly regressed, not that the environment has genuinely gotten less multi-domain in its attack patterns.

Time-to-correlate: the interval between the first domain event in a chain and the moment the correlation engine assembles the full case, distinct from time-to-detect on any single event. This is the metric that most directly measures the value the cross-domain layer is adding over single-domain tools, and it should be tracked separately from overall mean-time-to-detect because it isolates the correlation engine's contribution from each domain tool's own detection latency.

False-positive rate at the case level, not the alert level: because cross-domain correlation should suppress single-domain noise, the case-level false-positive rate (cases that turn out benign after analyst review) should be materially lower than any individual domain tool's raw alert false-positive rate. If it is not — if correlated cases are just as noisy as raw alerts — the correlation logic is adding assembly overhead without adding precision, which is a sign to revisit the scoring model described in the previous section.

Analyst time per case: measured from case creation to disposition, this should trend down as the correlated timeline view matures, because the point of assembling a cross-domain narrative automatically is to eliminate manual reconstruction time. Programs that see correlation rate go up but analyst time per case stay flat usually have a case presentation problem, not a detection problem — the right data is being assembled but not surfaced usefully.

Coverage against a technique framework: map detections to MITRE ATT&CK techniques and track what fraction of relevant techniques for your threat model have at least one cross-domain detection versus only single-domain coverage, since single-domain-only coverage for a technique that inherently spans domains (like most lateral movement and privilege escalation techniques) is a strong predictor of a coverage gap even if a rule technically exists.

Buyer's guidance: evaluating platforms and vendors

Most organizations building cross-domain detection today are not writing every layer from scratch; they are choosing between a converged XDR platform, a SIEM-plus-integrations approach, or a hybrid where a platform handles correlation and orchestration while domain-specific sensors remain best-of-breed. The evaluation criteria below apply regardless of which model you lean toward.

Test entity resolution with your own data, not the vendor's demo

Every vendor demo shows clean entity resolution because demo environments have clean, single-domain-joined identities and no NAT, no shared kiosks, no service account sprawl. Insist on a proof-of-concept against your actual identity provider export, your actual DHCP logs, and your actual cloud IAM structure, and specifically test the messy cases — shared service accounts, federated identities, ephemeral cloud compute — because that is where entity resolution quality separates products that look similar on a feature checklist.

Ask for the correlation window and time-alignment methodology in writing

Ask specifically how the platform handles delivery lag from cloud control-plane logs, whether correlation uses event time or ingest time for sequence ordering, and what the default and maximum configurable correlation windows are per domain pair. A vendor that cannot answer this precisely likely has not engineered for it, and you will discover the gap during your first real incident postmortem rather than during evaluation.

Insist on explainability for every automated action

Any detection that can trigger automated containment must be able to show, in plain language, exactly which events across which domains contributed to the decision and at what confidence. This is not a nice-to-have for compliance — it is what lets your team tune false positives without vendor support, and what makes the difference between analysts trusting automation enough to expand its authority over time versus disabling it after the first bad call.

Evaluate the detection content lifecycle, not just the count

Vendors will quote a number of pre-built detections; ask instead how detections are versioned, how quickly new technique coverage ships after a technique becomes prominent in the threat landscape, and whether you can see the actual rule or model logic rather than a black box. A platform with fewer, actively maintained, transparent detections beats a platform with a large static library that has not meaningfully changed in a year.

Check deployment flexibility against your actual environments

Many organizations run a mix of cloud, on-premises, and in some sectors air-gapped or sovereign environments, and a platform that only works cleanly in one deployment model will force you to run parallel, poorly integrated stacks — recreating exactly the silo problem this article opened with, just at the platform level instead of the tool level. This deserves its own section given how often it is treated as an afterthought in evaluations.

Deployment models: cloud, on-prem, and air-gapped considerations

Cross-domain correlation architecture changes meaningfully depending on deployment constraints, and this is where generic XDR guidance most often breaks down for regulated or sovereign environments.

In a pure cloud deployment, the correlation and identity graph layers can lean on managed, elastically scaled infrastructure, and the main engineering focus shifts to minimizing the log-delivery-lag problem described earlier and to controlling egress cost from high-volume domains like network flow logs, which tend to dominate ingestion volume disproportionately to their detection value if not sampled or pre-filtered intelligently at the collection layer.

In on-premises deployments, the same five-layer architecture applies, but capacity planning for the correlation and graph layers becomes a hard constraint rather than an elastic knob — graph analytics in particular are compute- and memory-intensive at scale, and on-prem deployments need explicit sizing based on entity count and event throughput rather than assuming the cloud will absorb spikes. This is also where the identity graph's refresh cadence against on-prem Active Directory needs careful scheduling to avoid contending with domain controller load during business hours.

Air-gapped and sovereign environments — common in defense, critical infrastructure, and certain government and financial sectors — impose the strictest constraint: no external threat intelligence feed updates, no cloud-hosted correlation engine, and often no outbound connectivity at all. This means the entire five-layer stack, including entity resolution reference data, detection content, and any ML model weights, must be deployable and updatable through an offline or sneakernet content pipeline, with version control and integrity verification for every content update since there is no vendor cloud to silently patch behind the scenes. Cross-domain detection is, if anything, more valuable in these environments precisely because analyst headcount tends to be leaner and there is no fallback to a vendor's cloud-hosted threat hunting service — but it demands that the platform genuinely support full offline operation rather than treating air-gap support as a checkbox with degraded functionality. This is a design point worth confirming explicitly with any vendor, and it is a core requirement we build for directly given how much of the Algomox customer base operates in exactly these constrained environments across the broader AI-native platform.

A related consideration across all three models is exposure management: cross-domain detection tells you what is happening right now, but pairing it with continuous exposure assessment tells you where the next cross-domain chain is most likely to originate, by identifying which identities, endpoints, and cloud resources sit on the shortest paths between low-privilege entry points and critical assets before an attacker finds that path themselves. This is the connective purpose behind running exposure management and detection as one continuous program rather than two disconnected initiatives, a pattern described further in continuous threat exposure management.

Common pitfalls and anti-patterns

A handful of mistakes recur across nearly every cross-domain detection program, regardless of vendor or team size, and naming them explicitly saves months of rediscovery.

• Correlating without validating entity resolution first. Teams that build correlation rules against an entity graph that is only 70% accurate get confident-sounding, wrong correlations, which is worse than no correlation because it erodes analyst trust faster than raw, unassembled alerts do.
• Treating time windows as a single global constant. A fifteen-minute window that works for endpoint-to-network correlation will systematically miss cloud events that routinely arrive with longer delivery lag; windows need to be tuned per domain pair, not set once globally.
• Over-indexing on machine learning before deterministic coverage is solid. ML scoring adds the most value once the well-understood technique space is already covered by explainable rules; deploying ML first, before basic sequence detections exist, tends to produce impressive-sounding anomaly scores that analysts cannot act on because there is no baseline of known-bad to compare against.
• Ignoring non-human identity behavior baselines. As covered earlier, applying human anomaly thresholds to service accounts and machine identities is one of the single largest sources of both false positives and missed detections in cloud-heavy environments.
• Measuring only alert volume reduction. A correlation layer that reduces alert count but does not improve time-to-correlate or case-level false-positive rate has just made the noise quieter, not more accurate — volume reduction alone is a vanity metric.
• Building the platform around today's tool stack rather than the data model. Point-tool swaps happen every few years; a correlation architecture tightly coupled to one vendor's proprietary schema has to be substantially rebuilt at every swap, whereas one built on a common normalized schema absorbs tool changes at the collection layer only.
• Leaving response automation authority undefined until after an incident. Teams that have not pre-agreed, in writing, which cross-domain confidence and criticality combinations authorize automated containment end up making that call under incident pressure, which is precisely the wrong time to design a decision framework.

Frequently asked questions