What is endpoint detection and what does it actually see?

Endpoint detection is the practice of recording what happens on a device, such as which processes start, which files change and which connections open, then flagging sequences that look like an attack. It sees behavior on the host. It does not see your code, your dependencies or traffic that never touches the device.

What data does an endpoint tool collect?

Think of a flight recorder for a laptop or server. MITRE ATT&CK models this as data sources, and one of the most used is the process: an instance of a program being executed by at least one thread, with its own memory space, loaded modules and allocated regions. Around processes sit files, network connections, logons and registry or configuration changes.

A single event is rarely interesting. A word processor starting is normal. The signal lives in the chain.

What does a detection actually look like?

Here is a constructed example. A finance employee opens an invoice attachment. The document viewer starts a command shell. The shell writes a new executable to a temp folder, runs it, and that process opens an outbound connection to an address nobody in the company has contacted before.

MITRE's detection notes for phishing describe the same idea: correlate email metadata, file creation and network activity after a message arrives, looking for unusual new processes or suspicious document behavior. The ATT&CK mitigation for behavior prevention on endpoints gives a similar case: a user-level application spawns a privileged process, the tool notices the abnormal parent and child relationship and blocks it.

Each step alone has an innocent explanation. Together they are a story.

Where is the blind spot?

An endpoint tool answers "what did this machine do?" It is weak on questions outside the machine:

• Which third-party packages did a build pull in last Tuesday?
• Is the library in production exploitable through code paths you call?
• Was a secret committed to a repository that no endpoint ever touched?
• What did a SaaS admin change in a tenant?

Those need other evidence: dependency inventories, repository scanning, cloud and identity logs. Endpoint telemetry is one layer, and treating it as the whole picture is how teams get surprised.

There is also a coverage problem. A device with no agent produces no events. Contractors' laptops, build runners and short-lived containers are the usual gaps.

Detection versus prevention

Detection tells you something happened. Prevention stops it. Many tools do both, but they are different decisions with different failure costs. Blocking a legitimate admin script during a maintenance window is a real outage. Many teams start in alert-only mode, tune for a few weeks, then turn on blocking for the narrow set of behaviors they trust.

How to check or apply this

1. List your endpoints by type: employee laptops, servers, build runners, containers, contractor devices. Mark which report telemetry today.
2. Pick five ATT&CK techniques that matter for your business, for example phishing (T1566) and valid accounts (T1078).
3. For each, write the process chain you expect to see, then run a safe test on a lab machine and confirm an alert fires.
4. Decide who reads the alerts, how fast, and what they can do without asking anyone.
5. Review the gaps every quarter. New device types arrive quietly.
6. Pair endpoint data with software inventory so you can answer "are we affected?" without touching every host.

Where Safeguard fits

Endpoint detection does not tell you which of your dependencies are exploitable. Safeguard's SBOM and dependency scanning and reachability analysis cover that side of the question, and they work on code and build artifacts rather than on device behavior. We do not provide endpoint detection and response.

Quick check

Sources

• MITRE ATT&CK: Process data source (DS0009)
• MITRE ATT&CK: Phishing, T1566
• MITRE ATT&CK: Behavior Prevention on Endpoint, M1040
• MITRE ATT&CK: Valid Accounts, T1078

Last reviewed: 18 October 2026.