XDR Threat Hunting Workflows

Every intrusion touches at least three telemetry domains before an analyst ever sees an alert — a process spawns on an endpoint, a connection crosses the network, and a credential gets used somewhere it shouldn’t. The organizations that catch attackers early are not the ones with the most sensors; they are the ones whose sensors talk to each other. This is the architecture and the workflow discipline behind that correlation.

The fragmentation problem XDR was built to solve

Extended detection and response exists because single-domain security tools each see a slice of an intrusion and none see the whole thing. An EDR agent watches process trees, file writes, and registry changes on a host. A network detection tool watches flow records, DNS queries, and packet captures on the wire. An identity provider watches authentication events, token issuance, and conditional access decisions. A cloud security posture tool watches API calls, IAM policy changes, and workload configuration drift. Each of these tools produces high-fidelity signal inside its own domain and near-zero signal about what is happening in the others.

Attackers exploit exactly this seam. A credential-stuffing campaign against an identity provider looks unremarkable in isolation — a handful of failed logins is background noise for any tenant of size. The same campaign correlated against a burst of impossible-travel logins, followed twenty minutes later by a service principal creating a new OAuth grant, followed by that grant being used to exfiltrate a SharePoint site to an unfamiliar tenant, is an unambiguous account-takeover chain. No single tool in the stack produces that narrative. Only correlation across identity, cloud, and often endpoint (if the attacker later pivots to an interactive session) turns four unremarkable events into one urgent one.

The practical consequence for SOC teams is alert fatigue that is qualitatively different from “too many alerts.” It is too many disconnected alerts, each scored and triaged as though it were the whole story. Analysts spend the bulk of a shift doing the correlation manually — pivoting between an EDR console, a SIEM, an IdP admin portal, and a cloud provider’s activity log — before they can even decide whether an incident exists. That manual pivoting is slow, inconsistent between analysts, and does not scale past a handful of concurrent investigations. XDR, done properly, is the engineering discipline of moving that correlation out of the analyst’s head and into the pipeline, so the analyst starts from a stitched narrative instead of four unrelated tickets.

It is worth being precise about what XDR is not. It is not simply a SIEM with more log sources, and it is not an EDR vendor rebranding its console. A SIEM that ingests everything but keeps endpoint, network, identity, and cloud events in separate indices with no shared entity model is still fragmented — it has just moved the fragmentation into one UI. Real XDR requires a normalized data model, an entity resolution layer that can say “this process, this IP, and this user session are the same actor at the same moment,” and detection logic that is written to span domains rather than stay within one. Our own view of this architecture is laid out in more detail on the XDR detection and response page; the rest of this article works through the mechanics.

Reference architecture for unified detection

A working cross-domain detection pipeline has five layers, and the boundaries between them matter more than any single vendor feature. Get the boundaries wrong — for example, do correlation before normalization — and the whole system becomes brittle every time a source schema changes.

Layer 1: collection

Collection is the set of agents, forwarders, and API pollers that pull raw telemetry off endpoints, network taps/span ports, identity providers, and cloud control planes. The design decision that matters most here is push versus pull and the backpressure behavior when a downstream stage is slow. Endpoint agents should buffer locally and retry rather than drop events silently under load — a dropped process-creation event during exactly the window of a live intrusion is the single most expensive kind of data loss in this architecture. Cloud API polling (CloudTrail, Azure Activity Log, GCP Audit Logs) should track pagination cursors persistently so a collector restart does not create a silent gap.

Layer 2: normalization

Raw events from a Windows Sysmon feed, a Zeek connection log, an Okta system log, and an AWS CloudTrail record share almost no field names, timestamp formats, or severity semantics. Normalization maps each into a common schema — increasingly OCSF (Open Cybersecurity Schema Framework) or an internal equivalent — so that “actor,” “source IP,” “destination IP,” “process,” and “outcome” mean the same thing regardless of origin. This is unglamorous engineering, and it is also the single highest-leverage investment in the entire pipeline: every correlation rule, every hunt query, and every dashboard downstream is only as good as the schema discipline at this layer. Teams that skip it end up writing detection logic with dozens of source-specific branches, which is exactly the brittleness that causes detections to silently stop firing after a vendor changes a log format.

Layer 3: entity resolution and enrichment

This is the layer that actually makes telemetry cross-domain. Entity resolution binds a Windows SID, an Azure AD object ID, an email address, a service account, and a workstation hostname into a single canonical “identity” entity with a lifecycle, so that an anomalous Okta login and a subsequent suspicious PowerShell execution on a laptop can be recognized as the same person’s session even though the raw events never share a literal field. The same resolution has to happen for network entities (an internal IP maps to a specific asset and owner, not just a /32) and for cloud entities (an IAM role ARN maps to the workload and team that own it). Enrichment layers threat intelligence, asset criticality, vulnerability state, and business context (is this a domain controller, is this user a privileged admin, is this workload in the payment scope) onto every event so that scoring downstream has something to weigh besides raw event type.

Layer 4: correlation and detection

With a common schema and resolved entities, detection logic can finally be written as sequences and graphs rather than single-event rules: “this identity authenticated from a new ASN, then within 15 minutes issued an OAuth consent grant it has never issued before, then within 30 minutes that grant was used from a different IP to call an export API on a data store tagged sensitive.” That is a three-hop, three-domain sequence, and it is the kind of pattern that XDR platforms exist to express natively rather than as an analyst’s mental model.

Layer 5: response and hunting surface

The output of correlation feeds two consumers: automated or semi-automated response (isolate host, revoke token, disable account, quarantine workload) and the hunting interface analysts use to explore, pivot, and validate hypotheses that no rule has yet encoded. Both consumers need the same underlying entity graph — response actions have to target the right entity precisely, and hunts have to be able to pivot from any entity to its full cross-domain history.

What each telemetry domain actually contributes

It helps to be concrete about what each domain uniquely sees, because buyers frequently over-invest in one domain (usually endpoint, because EDR is the most mature market) while under-investing in the domains that are actually where modern intrusions spend most of their time — identity and cloud control planes.

Endpoint telemetry remains indispensable for execution-stage detail: no other domain can tell you that rundll32.exe spawned a child process with a base64-encoded argument that decodes to a reflective DLL load. But endpoint telemetry alone is blind to anything that happens before initial access (credential compromise, MFA fatigue attacks, session token theft from a browser that never touches an EDR-monitored process) and blind to anything that happens purely in a cloud control plane, where there is no host to instrument at all — an attacker who compromises a cloud administrator’s session and pivots entirely through API calls never generates a single endpoint event.

Network telemetry is the domain most resistant to attacker evasion, because moving data or commands still requires moving packets, even if payloads are encrypted. Flow-level analysis (who talked to whom, how much, how often, at what times) survives encryption in a way that payload inspection does not, which is why beaconing-interval analysis and JA3/JA4 TLS fingerprinting remain effective even against fully encrypted C2 channels. The trade-off is that network telemetry is the hardest domain to attribute to a specific user or process without joining it to identity and endpoint data — a NetFlow record alone tells you an IP talked to another IP, not who was behind the keyboard.

Identity telemetry has become the highest-value domain for early detection precisely because credential-based initial access now dominates confirmed breach causes across incident response reporting. An identity provider’s logs capture the earliest moments of most modern intrusions — password spray, MFA fatigue, token theft, consent phishing — well before any payload touches an endpoint. This is also the domain where cross-domain correlation pays off fastest, because a single suspicious login event is cheap noise but a login event correlated with an unusual downstream action (a first-time admin console access, a new mail forwarding rule, a new OAuth grant) is a near-certain true positive. Our identity and privileged access guidance and the deeper identity security architecture material go into the control side of this; here the focus is on using identity telemetry as a hunting signal.

Cloud control-plane telemetry is the domain most organizations instrument last and regret it most when they do. A misconfigured S3 bucket policy, an IAM role with an overly broad trust relationship, or a serverless function with excessive permissions can be the entire attack surface for a cloud-native breach, and none of it generates a single endpoint or network event in the traditional sense — it is API calls all the way down. Cloud detection has to key on control-plane anomalies (a role assumed from an unfamiliar principal, a permissions boundary removed, a snapshot shared to an external account) rather than payload or process signatures, which means the detection engineering discipline is closer to identity analytics than to classic malware detection.

Correlation mechanics: from single events to attack narratives

The mechanical heart of an XDR platform is the correlation engine, and there are three broad techniques it typically combines, each with different latency, false-positive, and engineering-cost characteristics.

Deterministic sequence rules encode a specific ordered chain of events across domains within a time window, matched against the resolved entity graph — for example, “same identity: failed logins > 5 in 10 minutes, then success, then privilege escalation API call within 20 minutes, then outbound data transfer > 500MB within 60 minutes.” These rules are cheap to write, easy to explain to an auditor, and directly mappable to MITRE ATT&CK technique chains, but they are brittle against variation — an attacker who reorders steps or stretches the timing outside the window evades them entirely.

Statistical and behavioral baselining builds a per-entity model of normal behavior (typical login hours, typical process trees for a given host role, typical data volumes for a given service account) and flags deviation, usually scored rather than binary. This catches novel attack patterns that no one has written a rule for, at the cost of needing enough historical data per entity to establish a reliable baseline (new hosts, new employees, and newly provisioned cloud accounts are inherently noisy for weeks) and needing careful tuning to avoid flooding analysts with statistically-unusual-but-benign behavior, like a finance team running month-end batch jobs.

Graph-based analysis treats the entire environment as a graph of entities (users, hosts, processes, IPs, cloud resources) and edges (authenticated-as, connected-to, spawned, assumed-role-of), then runs graph algorithms — shortest-path, community detection, centrality scoring — to find things like the shortest privilege-escalation path from a low-value compromised account to a domain admin, or an unusual clustering of otherwise-unrelated hosts all beaconing to the same rare external domain. Graph analysis is the technique best suited to lateral movement and blast-radius questions, and it is also the most computationally expensive and the hardest to make deterministic and explainable to a Tier 1 analyst, which is why it is usually deployed as a hunting and investigation tool rather than a primary alerting mechanism.

Mature programs run all three in layers: deterministic rules for known, high-confidence attack chains that need to auto-triage or auto-contain with minimal delay; behavioral baselining for the broad middle tier of “something is off, a human should look” alerts; and graph analysis on demand, invoked by a hunter once a rule or baseline alert has surfaced a starting entity worth exploring outward from.

The hypothesis-driven hunting loop

Threat hunting is frequently described loosely as “proactively looking for threats,” which is true but not operational. A repeatable hunting program needs a defined loop with entry and exit criteria, or it degenerates into unstructured log browsing that produces inconsistent results and cannot be measured, staffed, or improved over time.

The loop has six stages. Trigger selection starts every hunt from one of three sources: a new threat-intelligence report describing a technique relevant to your environment, a gap identified in detection coverage (commonly mapped against MITRE ATT&CK), or an anomaly surfaced by baselining that a rule did not fire on but that a hunter judged worth a closer look. Hypothesis formulation turns the trigger into a falsifiable statement — not “hunt for lateral movement” but “if an adversary is using pass-the-hash for lateral movement in our environment, we should see NTLM authentication events from service accounts to hosts they have never authenticated to before, within a short time window of an anomalous LSASS memory read on the source host.” A good hypothesis names the entities, the telemetry domains, and the expected sequence, which is exactly what makes it testable against a cross-domain query.

Data scoping identifies which telemetry sources and time range the hypothesis actually requires — this matters because pulling six months of full-fidelity network flow data to test a one-week hypothesis is both slow and often prohibitively expensive against a retained-data budget. Query execution and pivoting is the actual hands-on-keyboard hunting: running the query, examining the results, and pivoting outward from anything suspicious — from a flagged host to its full process tree, from a flagged identity to its full authentication history, from a flagged IP to every other internal host it has touched. Validation separates confirmed findings from false leads, and every confirmed finding should immediately answer “could an automated rule have caught this?” — if yes, that is a detection engineering backlog item, not just a one-off catch. Documentation and rule promotion closes the loop: the hunt’s query, its result, and (if applicable) a new or tuned detection rule get committed back into the platform so the next occurrence of the same pattern is caught automatically rather than requiring another manual hunt.

The step teams most often skip is the last one, and it is the one that determines whether a hunting program produces compounding value or just repeats the same manual work every quarter. A hunt that finds a real technique but never becomes a rule means the next analyst has to rediscover it from scratch the next time it occurs — and adversaries reuse tooling and technique far more than defenders reuse hunt results, which is a bad trade. Programs that track a “hunt-to-rule conversion rate” as a formal metric consistently show detection coverage compounding quarter over quarter, while programs that treat hunting as a standalone activity show flat coverage no matter how many hunts they run.

Worked example: a lateral-movement hunt end to end

Concrete mechanics matter more than abstractions here, so walk through an actual hunt against a hypothesis that a compromised low-privilege workstation is being used as a pivot point toward a domain controller.

The trigger is a behavioral baseline alert: a workstation account that has never authenticated outbound to any host besides its assigned file server suddenly shows an SMB connection to a second workstation it has never touched. On its own this is a weak signal — file-share misconfigurations and one-off IT support sessions produce similar noise constantly. The hypothesis: if this is early-stage lateral movement, the source host should show a credential-access technique (LSASS access, registry hive dump, or similar) shortly before the new SMB connection, and the destination host should show a new local logon from the same identity shortly after.

Data scoping pulls three domains for a six-hour window centered on the anomalous connection: endpoint process and access-token events from both hosts, network flow records for the SMB session (port, byte count, duration), and identity authentication logs for the account in question. The query joins on the resolved identity entity and the two host entities.

The pivot reveals a process-access event twenty minutes prior on the source host: procdump.exe, dropped in a temp directory ten minutes before that, opened a handle to lsass.exe with an access mask consistent with memory dumping. Pivoting on the destination host shows a new interactive logon from the same account, followed six minutes later by that same account enumerating group memberships via net group /domain, then attempting (and being denied, per identity logs) an authentication to a domain controller. The hypothesis is confirmed: credential dumping on the source host, reuse of the dumped credential for lateral movement to a second host, followed by a reconnaissance and escalation attempt that failed only because the dumped account lacked domain admin rights.

Validation closes with containment (isolate both hosts, force credential reset for the account, revoke active sessions) and documentation. Rule promotion adds two new detections: a sequence rule for “unsigned process opens handle to lsass.exe with memory-read access, followed within 30 minutes by that host’s primary logged-on account authenticating to a host it has no history with,” and a baseline refinement lowering the threshold for “first-time internal host-to-host connection” alerts for workstation-tier assets specifically, since the original trigger nearly did not fire with enough confidence to get analyst attention. This is the compounding effect in practice: one hunt produced one incident response and two durable detection improvements that will catch the same technique automatically next time, without requiring another six-hour manual pivot.

Using MITRE ATT&CK as the coverage and gap-analysis framework

ATT&CK matters to a cross-domain hunting program for a specific structural reason: most of its tactics span telemetry domains by design, which makes it a natural checklist for whether your correlation pipeline actually reaches across the domains it claims to. Credential Access techniques mostly live in endpoint and identity telemetry jointly. Lateral Movement lives in network and endpoint jointly. Exfiltration lives in network and cloud jointly. Persistence via cloud-native mechanisms (a new Lambda trigger, a modified CI/CD pipeline) lives entirely in cloud control-plane telemetry and has no endpoint equivalent at all.

A practical coverage exercise scores each ATT&CK technique relevant to your environment against three questions: is there raw telemetry available to detect it (a collection question), is there a rule or baseline that would fire if it occurred (a detection question), and has that rule been validated against a realistic simulation in the last two quarters (a validation question). Techniques that fail the first question are collection gaps — usually cloud or identity logging that is not yet enabled at sufficient granularity. Techniques that pass the first but fail the second are detection-engineering backlog. Techniques that pass both but fail the third are the most dangerous category, because they create false confidence — a rule that exists but has silently broken (a schema change upstream, a disabled data source, a threshold that no longer matches current traffic volume) is worse than no rule, because it removes the pressure to build one while providing none of the protection.

Purple-team exercises — where an internal or contracted red team executes specific ATT&CK techniques while defenders watch for the corresponding alert to fire — are the only reliable way to answer the validation question, and they should be run against the same cross-domain chains the hunting program cares about, not single isolated techniques. Testing “does EDR detect Mimikatz” in isolation tells you little about whether your platform correlates that detection with the subsequent identity and network activity that turns a single host compromise into a confirmed incident.

Metrics that actually indicate hunting program health

Vanity metrics plague this discipline — “number of hunts conducted” and “number of IOCs searched” measure activity, not effectiveness, and can be trivially inflated by running the same shallow hunt repeatedly. A more honest metrics set separates detection quality from process health.

• Mean time to detect (MTTD) by domain crossing count — track MTTD separately for single-domain versus multi-domain incidents. If cross-domain MTTD is dramatically higher than single-domain MTTD, the correlation pipeline is the bottleneck, not analyst skill.
• Hunt-to-rule conversion rate — the percentage of hunts that produce a new or tuned detection rule, tracked quarterly, as the leading indicator of compounding coverage discussed above.
• Detection rule decay rate — the percentage of existing rules that fail a periodic re-validation test (via purple team or synthetic replay), which surfaces silent breakage before an attacker finds it first.
• Analyst time-to-context — median time from alert receipt to having a full cross-domain entity timeline assembled, which directly measures whether the platform is doing correlation for the analyst or whether they are still doing it by hand across four consoles.
• False-positive rate by correlation technique — tracked separately for deterministic rules, behavioral baselines, and graph-derived alerts, since conflating them hides which technique needs tuning.
• ATT&CK technique coverage percentage — the fraction of in-scope techniques that pass all three coverage-exercise questions above (telemetry, detection, validated), tracked over time as the primary board-level coverage metric.
• Dwell time reduction trend — the organization-level trend in confirmed-incident dwell time, which is the ultimate outcome metric everything above should be driving down.

These metrics matter for a second reason beyond program health: they are the concrete evidence base for the alert-triage and automation decisions covered in AI-driven XDR alert triage, where machine-assisted scoring is only trustworthy if it is measured against the same false-positive and coverage baselines the human hunting program already tracks.

Buyer guidance: evaluating an XDR platform

Procurement conversations for XDR tend to focus on the wrong differentiators — endpoint detection efficacy scores from third-party test labs (which measure the endpoint agent alone, not the cross-domain platform) or the sheer count of supported log source integrations (which measures collection breadth, not correlation depth). The questions that actually predict whether a platform will reduce dwell time in your environment are architectural.

Ask whether identity and cloud control-plane telemetry are first-class citizens in the entity graph or bolted on as an additional log source with no native entity resolution to the endpoint and network graph — many platforms that market themselves as XDR still resolve entities primarily around the endpoint agent’s host identity and treat everything else as enrichment context rather than a peer domain with its own graph relationships. Ask how the platform handles a source going silent: does a stopped collector produce a visible gap indicator and coverage alert, or does the absence of events simply look identical to the absence of threats — the latter is a serious blind-spot risk that only surfaces during an actual incident when it is too late. Ask what the detection rule authoring interface actually supports — single-event rules only, or genuine multi-domain sequence and graph queries with adjustable time windows and entity joins. Ask how rule validation works: is there a built-in mechanism to replay historical data or synthetic attack traces against updated rules before they go live, given that a bad rule shipped straight to production either floods analysts or, worse, silently fails to fire.

Data retention economics deserve explicit attention, because cross-domain hunting frequently needs to look back further than the retention window that comes bundled with per-gigabyte-priced ingestion — a hunt that needs six months of authentication history to establish a baseline is not unusual, and platforms priced purely on ingestion volume create a perverse incentive to under-retain exactly the data hunting programs need most. Evaluate whether the platform supports tiered storage (hot for active correlation, warm/cold for hunt-depth retention at lower cost) rather than forcing a single retention tier across all use cases.

Deployment model flexibility matters more for XDR than for most security tooling, because the domains it spans — identity, cloud, network, endpoint — often live in fundamentally different trust zones, and organizations with regulatory or sovereignty constraints frequently need the correlation engine itself, not just the agents, to run within their own boundary. This is a genuine differentiator worth testing directly with vendors rather than assuming: ask specifically whether the correlation and entity-resolution layers can run fully on-premises or in an air-gapped enclave, not just the collection agents, since some platforms decouple collection (deployable anywhere) from correlation (cloud-only SaaS) in a way that defeats sovereignty requirements entirely.

Operationalizing within the SOC and NOC

A cross-domain hunting capability only produces organizational value if it is wired into the surrounding operating model, not run as an isolated specialist function. Two integration points matter most in practice. First, the hunting team’s output has to feed directly into Tier 1/Tier 2 triage playbooks — when a hunt confirms a technique, the resulting rule needs an accompanying response runbook, not just a detection signature, so that the next occurrence is handled consistently regardless of which analyst is on shift. Second, because so many of the cross-domain chains described above span what used to be organizationally separate network operations and security operations concerns (a network anomaly that turns out to be security-relevant, or a security incident that manifests first as a performance or availability symptom), the hunting workflow benefits from the same convergence discussed in integrated NOC-SOC operations — shared telemetry, shared entity context, and a shared escalation path rather than two teams rediscovering the same event independently through different consoles.

The broader agentic SOC model extends this further: once correlation and entity resolution are solid, a meaningful share of the hunting loop’s mechanical steps — data scoping, initial pivot execution, draft hypothesis generation from new threat intelligence — can be delegated to an AI agent that proposes a hunt plan and preliminary findings for a human hunter to validate and refine, compressing the loop from hours to minutes for well-understood technique classes while reserving human judgment for validation and novel hypothesis formulation. That model is described in more depth in our agentic SOC material, and it depends entirely on the entity-resolution and normalization discipline covered earlier in this piece — an agent cannot reliably propose a cross-domain pivot on top of a data layer that has not already resolved entities consistently.

Feeding exposure and asset context back into hunting priorities

Hunting hypotheses are far more productive when they are prioritized by what the organization is actually exposed to, rather than by whatever technique made headlines most recently. A continuous threat exposure management program — attack surface discovery, exploitability validation, and business-criticality scoring of assets — produces exactly the prioritization signal a hunting program needs: if exposure data shows a specific internet-facing service has a validated, exploitable vulnerability and sits adjacent to a high-value data store, that is where hunting hours should go first, ahead of a generic sweep for a technique with no demonstrated relevance to the environment. The mechanics of that exposure pipeline are covered in continuous threat exposure management and exposure management; the connection to hunting is that exposure context should be one of the three formal trigger sources for hypothesis selection described earlier, alongside threat intelligence and coverage-gap analysis.

The same logic extends to AI-specific risk as organizations adopt more machine-learning-driven infrastructure and AI agents of their own — new categories of telemetry (model API calls, agent action logs, prompt/response pairs) are becoming a fifth domain that hunting programs will need to fold into the same correlation discipline over the next several years, a trend covered in AI security. Platforms built with a genuinely extensible entity and schema model, such as the approach described in the AI-native stack, absorb a new domain like this as an additional entity type and telemetry source rather than requiring a parallel platform.

Common pitfalls that quietly defeat cross-domain hunting

Several recurring failure patterns show up across mature and immature programs alike, and most of them are organizational rather than technical.

• Clock drift across sources. A sequence rule with a 15-minute window is meaningless if endpoint agent timestamps and cloud API log timestamps drift by more than that window relative to each other. NTP discipline and explicit timestamp normalization at ingestion are not optional for cross-domain correlation.
• Entity resolution gaps at the edges. Service accounts, shared/generic accounts, and NAT-translated IPs routinely break entity resolution because they map many-to-one or one-to-many rather than cleanly. Programs that do not explicitly handle these cases end up with correlation rules that silently never fire for an entire category of accounts.
• Retention mismatched to hunt depth. Discussed above under buyer guidance, but worth repeating as an operational pitfall: a hunting team that discovers mid-investigation that the data it needs aged out three weeks ago has lost the investigation, not just the convenience.
• Treating hunting as headcount-bound rather than loop-bound. Programs that measure success by hunts-per-analyst-per-quarter without tracking conversion to rules will show activity without compounding coverage, and will not survive analyst turnover because the institutional knowledge from each hunt never left the analyst’s head.
• No adversary emulation cadence. Rules decay silently as environments change — new software deployed, new cloud services adopted, new network segmentation — and without a regular purple-team cadence, decay is invisible until an actual incident reveals it.
• Alert scoring that ignores cross-domain context. A scoring model that rates every alert on its own single-domain severity, without weighting for how many domains and how many distinct entities a chain touches, will systematically under-prioritize the multi-stage, multi-domain incidents that are actually the most severe.

A pragmatic starting sequence

Teams building this capability from a fragmented starting point — separate EDR, separate SIEM, separate identity and cloud logging with no correlation — get the most value from a specific sequencing rather than attempting all five architecture layers simultaneously.

1. Instrument and normalize identity telemetry first. It is the highest-signal, lowest-volume domain, and most environments already have an identity provider generating structured logs with minimal additional collection engineering.
2. Build the entity resolution layer around identity as the anchor, then extend it to endpoint hostnames and user sessions, since most other entities (network connections, cloud API calls) can be resolved back to an identity once that anchor exists.
3. Add cloud control-plane telemetry next, given how much modern blast radius lives there and how cheap it is to enable relative to the risk it covers.
4. Layer in network flow and endpoint process telemetry, prioritizing the assets and segments identified as highest-criticality by exposure management data rather than instrumenting uniformly across a flat environment.
5. Write the first ten detection rules as deterministic cross-domain sequences mapped directly to the ATT&CK techniques most relevant to your threat model, and run a purple-team validation against all ten before calling the initial rollout complete.
6. Stand up the hunting loop formally — documented hypothesis template, tracked hunt-to-rule conversion — only once steps one through five are stable, since hunting against an unresolved entity graph produces mostly false starts.

Frequently asked questions