Agentless protection secures a device without installing any software on it, by monitoring and controlling its behavior at the network layer instead. It is the only way to protect devices that cannot host a security agent.
Two ways to protect a device
There are fundamentally two ways to protect a connected device. The first, and most familiar, is to install security software on it, an agent, that watches the device from the inside and can act locally. This is how endpoint detection and antivirus work, and it is effective on devices you control and can install software on. The second way is to protect the device from the outside, by watching and controlling its behavior on the network, without putting anything on the device at all. That is agentless protection.
An agentless approach treats the network as the vantage point. It observes the traffic a device sends and receives, learns what normal looks like for that device, and acts at the network layer when something is wrong. Nothing is installed, nothing changes on the device, and critically, the device does not even need to be capable of running security software. That single property is what makes agentless protection the only option for an enormous and growing class of devices.
Why so many devices cannot run an agent
The need for agentless protection is not a preference, it is a structural fact about modern networks. A large share of connected devices simply cannot host an agent. They run closed, embedded, or unsupported operating systems that do not permit third-party software; they are certified in a fixed configuration that cannot be modified, which is common for regulated equipment; or they are years past vendor support with no path to install anything new.
Healthcare is the clearest example. A large hospital runs thousands of connected medical devices, from infusion pumps and patient monitors to imaging controllers and lab analyzers, and research has found that while roughly half run a version of Windows, only about 10% carry active anti-malware protection. The rest are structurally invisible to agent-based tools. The same pattern holds for operational technology in manufacturing and utilities, building-management systems, and the long tail of legacy equipment in almost every organization.
How agentless protection works
Because it cannot rely on anything running on the device, agentless protection does all its work on the network, and it follows a clear sequence.
- Discover: automatically find and classify every connected device, including the unmanaged ones that never made it onto an inventory.
- Baseline: learn each device's normal behavior, the systems it talks to, the protocols it uses, and the volume and timing of its traffic.
- Detect: flag deviations from that baseline, such as a monitor suddenly scanning the network or a pump moving data it never normally touches.
- Contain: on a confirmed threat, quarantine the device at the network layer, cutting the attacker's access while the device stays powered and functional.
- Prove: log every observation and action, so there is a record for compliance and investigation.
Common misconceptions
Because the term gets used loosely, a few misconceptions are worth clearing up. The first is that agentless means weaker. On a device that cannot host an agent, network-level protection is not a lesser substitute for on-device security, it is the only security available, and a device's behavior on the network is often a more honest signal than anything happening on a box you cannot fully trust. The second is that agentless protection is passive and can only watch and alert. That is true of some discovery-only products but not inherent to the approach: protection at the network boundary can actively quarantine a compromised device the instant it misbehaves. The third is that it is hard to deploy, when in reality not having to install and maintain software on thousands of fragile devices is usually simpler than the agent-based alternative.
Why it matters, and how it fits
Agentless protection is not a universal replacement for endpoint agents, and the honest picture is that the two are complementary. A mature program uses both: agents give deep, on-device visibility on the systems that can run them, and agentless protection covers everything that cannot, which in a hospital or factory is the majority of the real attack surface. The failure mode to avoid is assuming an endpoint tool covers you when it structurally cannot see most of your devices. An attacker who lands on an unmonitored infusion pump or a legacy controller is inside the network, invisible to the agent-based tool, and free to move. Agentless protection closes exactly that gap, which is why it is essential rather than optional in any device-heavy environment.
A simple test for whether you need it
There is a quick way to judge how much agentless protection an environment needs. Count the connected things on the network, then count how many actually run your endpoint tool. In an ordinary office, those numbers might be close, and agent-based security covers most of the ground. In a hospital, a factory, or a utility, the gap is usually enormous: thousands of devices against a few hundred managed endpoints. That gap is the undefended attack surface, and it is exactly what an attacker probes first, because it is where they can operate unseen.
If the gap is anything other than near zero, agentless protection is not a nice-to-have but a requirement, because no amount of investment in endpoint security will ever cover the devices that cannot run an agent. The practical path is not to choose between the two approaches but to map the environment honestly, apply agents everywhere they fit, and deploy agentless, network-level protection across everything they do not reach. Done that way, the organization finally has visibility and control over the whole attack surface rather than the comfortable but misleading subset that happens to run software, which is the difference between feeling covered and actually being covered.
See also
Sources
- Claroty: State of CPS Security 2025 — Healthcare Exposures
- HHS HC3: medical device security risks in healthcare
Definitions are drawn from the cited sources and were current as of publication. Content was rephrased for compliance with source licensing.
