GravityZone EDR vs XDR: When Does Each Actually Pay Off?

TL;DR. GravityZone EDR records what happens on the endpoint and lets an analyst (or Bitdefender’s MDR team) chase incidents through process trees, command lines, registry, and network. XDR adds sensors for M365, Google Workspace, network, identity, and cloud, then correlates across them. EDR pays off the first time a phish lands. XDR pays off when the phish chains into an inbox rule, a Teams export, and a sign-in from a new country. Most SMEs need EDR; mid-market with M365 telemetry and an analyst needs XDR.

The Bitdefender page shows the tier matrix. This article goes deeper: what changes between EDR and XDR in practice, what the XDR sensors actually pull, and how to tell which side of the line your business sits on.

What’s actually the difference between EDR and XDR?

Strip the marketing off and the answer is one word: scope.

EDR (Endpoint Detection and Response) tells you what is happening on the endpoint. Process A spawned process B with these arguments. Process B opened a TCP connection to this IP. Process B wrote a file at this path. The agent records the events; the console correlates them into a story; an analyst (yours, or Bitdefender’s) reads the story and decides what to do.

XDR (Extended Detection and Response) does the same for everything else that produces telemetry. The M365 audit log. The Google Workspace admin log. The firewall. Entra ID sign-in events. AWS CloudTrail. It correlates an event in the inbox with an event on the laptop with an event at the identity provider, and surfaces one incident instead of three disconnected alerts in three portals.

The “X” is not a product. It is the breadth of telemetry the platform can ingest. Bitdefender’s XDR engine takes the EDR data it already has and joins it onto sensor data. Same detection logic, wider surface.

What does GravityZone EDR cover?

The EDR tier does the work most SMEs need.

The agent records process creation, command-line arguments, file writes, registry changes, network connections, scheduled-task creation, service installations, DLL loads, and PowerShell / WMI / scripting-host activity. Events stream to the GravityZone cloud and are held for a 90-day retention window (extendable). The console renders incidents as a process tree with suspicious nodes highlighted, MITRE ATT&CK technique IDs attached (T1059 Command and Scripting Interpreter, T1547 Boot or Logon Autostart, T1003 OS Credential Dumping, and so on), and a recommended response path.

Response actions live in the same console. Isolate an endpoint from the network at one click while leaving the agent’s command channel open. Kill a running process. Quarantine a file. Run a remote shell against the host. Roll back ransomware-encrypted files using Bitdefender’s local snapshot. Search lets an analyst query recorded telemetry across the fleet (think “show me every endpoint that ran certutil.exe -urlcache in the last 30 days”) without pushing agents or rebuilding indexes.

EDR also surfaces the human signals XDR will eventually correlate against: failed local logons, unusual logon sources, suspicious parent-child process relationships (Word spawning PowerShell), and credential-access patterns mapped to T1078 Valid Accounts.

That is EDR. It is good. Enough for most fleets we run.

What does GravityZone XDR add?

XDR keeps everything EDR does and adds four classes of sensor that ingest external telemetry, plus a correlation engine that joins it all into single incidents.

The sensors do not replace your existing tools (M365 still keeps its own audit log, your firewall still has its own dashboard). They subscribe to the events those systems already emit, normalise them, and feed them into Bitdefender’s correlation. An XDR alert reads as one timeline crossing systems, not three alerts you have to stitch together yourself.

Response actions move across the boundary too. An XDR analyst can disable a compromised user in Entra ID, kill a malicious inbox rule in Microsoft 365, isolate the laptop, and quarantine the file from one console.

When does EDR cover the use case?

If any of these describe you, EDR is enough:

• Fleet under ~150 endpoints, mostly on one or two operating systems.
• No in-house security analyst and no MDR contract that consumes external telemetry.
• M365 or Google Workspace is the only “extended” surface, and you are happy reading sign-in logs and audit events in the native portals when an incident is live.
• Compliance pressure exists (cyber-insurance, POPIA, GDPR Article 32, SOC 2) but the questionnaire asks about EDR specifically, not XDR.
• Budget is tight and XDR spend would crowd out things you need more: patch management, FDE, MFA hardware tokens, an actual backup tier.

EDR with Bitdefender’s MDR on top is where most of our clients land. The MDR team watches EDR telemetry 24x7, triages alerts, and handles response. Analyst-grade outcome, without paying for an analyst seat.

When is XDR worth it?

XDR earns its line item when these conditions stack up:

• M365 or Google Workspace is core to operations, and identity (Entra ID / Google Identity) is where attackers go first. OAuth-consent phish, inbox-rule-forward, Teams data-export, SharePoint over-share, Adversary-in-the-Middle session-token theft (T1539 Steal Web Session Cookie). All cloud, not endpoint.
• You have at least one analyst in-house, or an MDR contract that explicitly covers cloud / identity telemetry (some MDR offerings cover endpoint only, so check the SoW).
• Network telemetry is available and worth correlating: a next-gen firewall with NetFlow / syslog out, a SASE / ZTNA service, or cloud VPC flow logs.
• Identity is federated and high-value: M&A activity, regulated industry, finance/legal/healthcare, or enough revenue per compromised account that a one-hour-faster detection materially changes the loss number.
• A SIEM exists or is on the roadmap. XDR can feed it; EDR alone gives a thinner stream.

30 staff on M365 Business Premium, no analyst, already paying for MDR? XDR is over-spec. 300 staff across two countries with a SOC ramp-up underway and Conditional Access doing real work? XDR pulls its weight from month one.

What sensors does GravityZone XDR ingest?

This is where the XDR pitch gets concrete. Four sensor families do the work.

Cloud sensor. Subscribes to AWS CloudTrail, Azure activity logs, and (where supported) GCP audit logs. The detections target cloud-native attack chains: a new IAM user in an unusual region, an S3 bucket policy widened to public, a Lambda function modified by a non-admin principal, a Reserved Instance footprint that suddenly grows in a region you don’t operate in (cryptomining, T1496 Resource Hijacking). For SMEs the CloudTrail integration alone often justifies the sensor; most cloud breaches show up in CloudTrail hours before any endpoint signal does.

Identity sensor. Pulls sign-in and audit events from Microsoft Entra ID and (for Google shops) the Google Workspace admin and login audit logs. Detections target T1078 Valid Accounts and the post-MFA-bypass surface: impossible-travel sign-ins, anomalous OAuth consent grants, MFA fatigue patterns, sign-ins from residential proxy ranges tied to credential-stuffing infrastructure, and inbox rules that auto-forward or auto-delete (the classic BEC pre-positioning). This is the sensor that catches phishing chains. See the Microsoft 365 page for how the M365 side fits; XDR consumes the audit stream M365 already produces, no tenant changes or extra licences needed beyond an M365 SKU that supports the unified audit log.

Network sensor. Ingests syslog and NetFlow from firewalls, IDS, and proxies. Detections target T1071 Application Layer Protocol (C2 over HTTP/S), DNS tunnelling, lateral-movement RDP/SMB patterns inside the LAN, and beaconing intervals no host-side signal alone will catch. Useful when an attacker has reached an unmanaged device (a printer, a guest laptop, a contractor box) the EDR agent will never sit on.

Productivity sensor. Watches M365 and Google Workspace activity beyond identity: SharePoint / OneDrive / Drive sharing changes, Teams data-export events, Exchange Online inbox-rule creation, mass-download patterns, anomalous admin actions in the M365 admin centre or Google Admin console. This sensor catches the “after the account is compromised” phase: data exfiltration and persistence. T1114 Email Collection, T1567 Exfiltration Over Web Service, T1098 Account Manipulation.

The sensors share a correlation engine. An incident reads end-to-end: identity sensor flags an anomalous sign-in; productivity sensor flags an inbox rule created five minutes later; EDR flags the same user’s laptop running a script downloaded from a suspicious Drive link an hour after that. One incident, four signals, one analyst response.

What does this look like in practice?

Worked example. A finance manager at a 120-person SME clicks a link in what looks like a DocuSign notification. The link leads to an Adversary-in-the-Middle proxy that captures her Microsoft 365 password and the post-MFA session token (T1557 Adversary-in-the-Middle, T1539 Steal Web Session Cookie). Within the hour the attacker signs in from a residential proxy in another country, creates an inbox rule that moves any reply containing “invoice” or “wire” into RSS Subscriptions, exports her contact list, and starts emailing the supplier list with a “we have changed banking details” PDF.

What does EDR alone see? The endpoint is clean. The phishing kit ran in the browser, the session token theft is server-side, no payload landed on the laptop. EDR has nothing to alert on. You find out when a supplier phones to confirm the new banking details, by which time invoices have been paid into the attacker’s account.

What does XDR see? Identity sensor flags the sign-in: new ASN, country mismatch, time-of-day anomaly. Productivity sensor flags the inbox-rule creation minutes later. Auto-moving messages to a non-default folder is a classic BEC pre-positioning step. The correlation engine joins the two into one incident, severity high, with the user, the source IP, the rule contents, and the access-token age in one timeline. An analyst (yours, or Bitdefender’s MDR) revokes the session, disables the user, deletes the inbox rule, and pushes a Conditional Access block on the source ASN, all from inside the XDR console, inside 15 minutes.

That is the difference. EDR sees endpoint-resident attacks. XDR also sees the cloud and identity attacks that never touch the endpoint, which is most of what 2026 looks like.

Side-by-side

Where does this leave you?

If you do not have EDR yet, that is the first decision and the obvious one. Read the GravityZone Buying Guide for the tier mechanics and the Bitdefender vs Defender comparison for the platform call. EDR vs no-EDR has one answer in 2026: yes.

If you have EDR and you are weighing XDR, the question is not really about Bitdefender. It is about whether your environment generates enough cloud and identity telemetry that a correlation engine will surface something a human reading three portals would miss. For most 50–150-staff SMEs the answer is “not yet”. For most 200+-staff businesses with M365 in the middle of operations, the answer is “yes, and the longer you wait the more you pay in incident cost”.

XDR is also where MDR economics flip. An MDR contract that includes XDR telemetry is materially better value than endpoint-only MDR; the analyst on the other side has the cloud and identity context that makes triage faster.

Book a 30-minute XDR fit call

If you are weighing the decision, the useful next step is a structured scoping call rather than a sales demo. We walk three things:

1. Incident-response maturity. Who currently triages alerts, on what schedule, with what runbook? Honest answers, not aspirational ones.
2. Current SIEM stack and analyst capacity. Sentinel? Splunk? Nothing yet? In-house analyst, MDR, MSP-as-SOC, or no-one?
3. Telemetry availability. Is M365 audit logging fully enabled? Are firewall syslogs being collected anywhere? Is Entra ID emitting sign-in logs to a destination you control?

Out of that we tell you which tier (EDR with MDR, XDR self-managed, or XDR with MDR) actually fits, and what the 12-month cost looks like in your numbers. No deck.

Email support@osh.co.za or use the form on the Services page. Same-business-day response, real engineer on the call, written summary afterwards. For the broader Bitdefender stack (patch management, full disk encryption, email security, the lot), start at the Bitdefender page. For the identity-sensor angle, see the Microsoft 365 page.