Endpoint Detection and Response watches what happens on a managed device. Processes, files, registry changes, memory injection. It does that well. 

Managed Detection and Response builds on EDR. It adds a SOC team that triages alerts and responds to incidents. The analysts make endpoint detection faster and more accurate. They only see what the agent records. 

The problem is what sits outside the device. Network traffic between hosts. Identity systems like Microsoft 365 and Entra ID. Cloud workloads in AWS and Azure. Third-party SaaS apps holding your client data. A growing population of IoT and OT equipment that cannot run an agent at all. None of it appears on the endpoint console. 

EDR was never built to cover that ground. Neither was MDR. They protect the device. The rest of the attack surface needs different telemetry. 

The five blind spots EDR and MDR were never designed to cover 

1. Network blind spots 

EDR watches its own host. It does not watch the path between hosts. 

Lateral movement, command and control beaconing, DNS tunnelling and bulk data exfiltration travel across the network. An attacker who pivots from one device to another, or from a compromised cloud workload to a database, moves through traffic an agent will never see. The endpoint console shows nothing because nothing happened on the endpoint. 

Network Detection and Response (NDR) closes the gap. It analyses flows, protocols and anomalous behaviour at the wire level and surfaces what endpoint telemetry misses. 

2. Identity blind spots 

Most modern intrusions start with a credential, not a process. 

M365 account takeovers, OAuth consent phishing, session token theft and privilege escalation inside Entra ID happen entirely in identity systems. The attacker never touches a managed device. They sign in with stolen credentials or a stolen token from their own laptop, then operate inside Microsoft 365, SharePoint, Teams and connected SaaS apps. The legitimate user notices nothing. The endpoint sees nothing. 

Identity Threat Detection and Response (ITDR) ingests sign-in logs, MFA events and conditional access decisions. It catches what the endpoint console will never see. 

3. Cloud blind spots 

Workloads, configurations and APIs sit outside agent coverage. 

Misconfigured IAM roles, exposed S3 buckets, unrotated access keys, public-facing APIs and shadow cloud subscriptions all create entry points that endpoint agents do not monitor. An attacker who finds a misconfigured admin role in AWS does not need to touch a single managed laptop. They operate inside the cloud control plane. 

Cloud Security Posture Management (CSPM) and cloud workload telemetry surface these gaps. Without them, an attacker pivots through your client estate for weeks before anyone notices. 

4. SaaS blind spots 

Third-party SaaS apps now hold more sensitive data than endpoints do. 

Malicious OAuth grants, over-permissioned app integrations and compromised third-party vendors give attackers a direct path to client data without ever touching a device. The path runs through app-to-app permissions inside Microsoft 365, Google Workspace, Salesforce and dozens of other platforms an MSP client uses every day. 

SaaS Security Posture Management (SSPM) and OAuth audit telemetry catch app-to-app abuse and unauthorised data access in the place where the attacker is actually operating. 

5. IoT and OT blind spots 

Some devices were never designed to host an agent at all. 

Network cameras, printers, building management systems, smart sensors, programmable logic controllers, medical devices and BYOD hardware do not run endpoint software. Their firmware does not allow it. In a typical SMB estate, this category is growing faster than the managed device population. 

Network-level telemetry is the only way to see these devices. Without it, every printer and every smart thermostat is invisible to your security stack. Attackers know this. The 2024 Microsoft Digital Defense Report found that over 90% of ransomware attacks reaching the encryption stage used unmanaged devices as the initial access point or for remote encryption. 

A common breach scenario your EDR and MDR will not see 

A finance user at one of your clients clicks a phishing link in a Teams message. The page looks like a legitimate Microsoft sign-in. They enter their credentials and approve the MFA prompt. The attacker now holds a valid M365 session token. 

The attacker signs in from a new IP in another country. Conditional access rules are not strict enough to block the login. They access SharePoint, exfiltrate 12 GB of client files, and create an inbox forwarding rule on the user mailbox so future correspondence gets copied to an external address. 

The endpoint agent on the finance user laptop sees nothing. No malicious process. No file write. No memory injection. No signature match. The agent has nothing to report because nothing malicious happened on the device. The MDR SOC team sees nothing either, because they only investigate what the agent flags. 

Open XDR catches this because it correlates three events into one incident. The identity event (sign-in from a new geography), the cloud event (bulk SharePoint download), and the SaaS event (new mail forwarding rule). An analyst sees the pattern within minutes. Your client gets a call before the data leaves the estate. 

Side-by-side coverage. EDR, MDR and Open XDR. 

A coverage map for the most common attack vectors MSP clients face today. EDR and MDR share the same data layer, so their coverage is identical for these attack types. Open XDR adds telemetry from network, identity, cloud and SaaS so it sees the rest. 

A note on fairness: This compares standard EDR and MDR deployments. Some MDR providers have added identity (ITDR) or cloud (CSPM) modules to their core service. Where they have, treat those rows as Partial for that provider. The default architecture of MDR remains endpoint-first. 

Is enhanced.io a fit for your MSP? 

Book a 30-minute call with Hannah, our co-founder. We talk through your MSP, your current security setup and where you want to take it. If enhanced.io is a fit, we tell you. If not, we tell you that too.