Why shouldn't endpoints rely entirely on scanning?

Endpoints should not rely only on scanning because a scan checks for known problems at one moment. It misses new malware, attackers who use built-in tools, and weaknesses in configuration and identity. Layer scanning with patching, hardening, least privilege, application control and logging that someone reads.

What does scanning actually tell you?

A vulnerability or malware scan compares what is on a machine with a list of known things: known malicious files, known vulnerable software versions, known unsafe settings. The result is a snapshot. It is accurate about the items it knows and silent about everything else.

NIST SP 800-115, the guide to technical security testing, makes this point in its framing: testing and examination have benefits and limitations, and the guide recommends how to use each technique. A scan is a technique, and a technique is not a programme.

Where does scanning fall short?

Time. A scan on Monday says nothing about Tuesday. A new vulnerability, or a new binary, can appear an hour later.

Novelty. Signature and known-issue checks do not recognise what has not been catalogued. Attackers modify tools specifically to change how they look.

Legitimate tools. MITRE ATT&CK documents techniques that use software already on the machine, such as PowerShell abuse (T1059.001) and System Binary Proxy Execution (T1218). Nothing malicious needs to be installed, so a scan for malicious files finds nothing.

Tampering. Adversaries may disable or modify security tools to avoid detection, a behaviour ATT&CK catalogues under impair defenses. A scanner that can be switched off by the thing it is scanning is a weak control.

Context. A scan lists a vulnerable component but cannot tell you whether the user is an administrator, whether the machine holds secrets, or whether the network path to it is open.

What does a constructed incident look like?

A weekly scan reports a laptop as clean on Friday. On Saturday the user is phished and approves a sign-in prompt. The attacker uses the user's session and built-in command line tools to browse file shares. The next scan finds no malware, because none was installed. What would have caught it: multifactor authentication that resists approval fatigue, logs showing an unusual sign-in location, and a limit on what the account could reach.

What should surround scanning?

NIST SP 800-137 describes continuous monitoring as ongoing visibility into assets, awareness of threats and vulnerabilities, and visibility into whether controls are working. Scanning is one input. Around it:

• Patch management. SP 800-40 frames patching as preventive maintenance with a defined process to identify, prioritise, acquire, install and verify updates.
• Hardening. Remove unneeded software and services, and apply a secure baseline.
• Least privilege. Standard users by default, with administrative rights granted for tasks.
• Application control. Allow known programs and block the rest where feasible. CISA's DarkSide advisory lists application allowlisting as a mitigation.
• Logging and review. Keep process, sign-in and network logs off the machine, and alert on chains of behaviour.
• Tamper protection. Make it hard for a local user or process to disable the agent.

How to check or apply this

1. List what your current endpoint scanning detects and what it cannot.
2. Check scan frequency against how fast you need to learn about new problems.
3. Remove local admin rights from everyone who does not need them.
4. Turn on tamper protection and alerting for agents that stop reporting.
5. Send endpoint logs to central storage and write two behaviour-based alerts.
6. Test with a harmless simulation that uses built-in tools, and see whether anyone notices.

Quick check

Sources

• NIST SP 800-115, Technical Guide to Information Security Testing and Assessment
• NIST SP 800-137, Information Security Continuous Monitoring
• NIST SP 800-40 Rev. 4, Enterprise Patch Management Planning
• MITRE ATT&CK T1218, System Binary Proxy Execution
• MITRE ATT&CK T1059.001, PowerShell
• CISA AA21-131A

Last reviewed: 18 October 2026.