What an endpoint agent actually monitors

Endpoint detection and response tools work by installing an agent on a managed device. That agent monitors process execution, file system activity, registry changes and network connections originating from the device. When a suspicious process runs, the agent logs it, classifies it and raises an alert. The model is well understood and works reliably for what it covers.

The boundary of that coverage is the managed device. What an endpoint agent monitors is what happens on the hardware it is installed on. It has no visibility into what happens across cloud and identity surfaces that exist entirely outside the device boundary.

This is not a product failure. It is an architectural constraint. The agent is designed to observe the endpoint. Expecting it to observe a SharePoint external sharing event or an Entra ID sign-in from an unfamiliar location is expecting it to do something it was not built to do.

What a clean dashboard does and does not tell you

A clean EDR dashboard tells you that no malicious or anomalous process executed on a monitored device during the reporting period. That is a meaningful data point. It is not the same as telling you that no breach is in progress.

The gap matters because a significant portion of modern attacks do not execute malicious code on managed endpoints at all, or do so only at the final stage after the attacker has already achieved persistence and exfiltrated data through other surfaces. The same pattern across cloud and identity appears repeatedly: a clean endpoint posture alongside active account compromise that has been running for weeks.

The question to ask when reviewing endpoint telemetry is not only whether any alerts fired. The question is what the endpoint tool cannot see and whether anything is monitoring those surfaces instead.

The surfaces outside endpoint agent visibility

Entra ID and identity

An attacker who gains access to valid credentials does not need to touch a managed device. Sign-in activity, MFA bypass attempts, conditional access failures and new device registrations all happen at the identity layer. Endpoint agents produce no signal for any of these events. Detecting them requires monitoring Entra ID sign-in logs and identity protection alerts directly.

Exchange Online and mailbox activity

Inbox rule creation, forwarding rule changes and external sharing of calendar data are among the most common persistence mechanisms after account compromise. Mailbox rules and forwarding changes produce no process execution event on any endpoint. They are application-layer events inside Exchange Online. An endpoint agent monitoring the user's laptop sees nothing.

SharePoint and OneDrive

Bulk download of files from SharePoint or OneDrive, external sharing link creation and permission changes all occur inside the Microsoft 365 application layer. The files never pass through a process that the endpoint agent monitors. The activity is invisible to EDR unless the attacker also opens the files locally on a managed device.

Azure and cloud infrastructure

API calls to Azure Blob Storage, changes to Azure AD application permissions and storage account access events all occur outside any endpoint. An attacker using Azure's own APIs to exfiltrate data produces traffic that is indistinguishable from normal Microsoft 365 operations. No endpoint alert fires.

SaaS applications

Activity inside Salesforce, Teams, ServiceNow or any other SaaS platform is not observed by endpoint agents. An attacker accessing sensitive data through a compromised SaaS account, or using a Teams webhook for command and control, generates no endpoint signal at all.

What detection across these surfaces requires

Monitoring the surfaces outside endpoint agent visibility requires telemetry from the identity, cloud and application layers. For a Microsoft 365 environment, that means Entra ID sign-in and audit logs, Exchange Online audit events, SharePoint access and sharing logs and Azure Monitor data for cloud infrastructure. Each of these is a separate data source that has to be ingested, normalized and correlated.

The detection logic also has to operate differently. Endpoint detection looks for known-bad process behavior. Identity and cloud detection looks for behavioral deviation from an established baseline: a user accessing SharePoint from an unusual location at 3am, an inbox rule forwarding to an external address that did not exist yesterday, compromised credentials being used from a geography inconsistent with normal patterns.

Correlating those signals across the full attack surface requires a detection platform that ingests from all layers and applies correlation logic across them, not a platform that processes one layer at a time.

The operational implication for MSPs

An MSP running endpoint MDR for a client has good visibility into endpoint threats. The question is whether the client's broader environment is covered or whether the visibility effectively stops at the device boundary. For most Microsoft 365 environments, the identity, cloud and application surfaces represent a large proportion of the actual attack surface.

The reporting structure matters here too. A monthly report showing zero EDR alerts is accurate. Whether it is representative of the client's actual security posture depends entirely on what else is being monitored. An MSP that presents endpoint telemetry as a complete security picture is presenting an incomplete one, even if the data itself is correct.