Unagentable Device

Why unagentable devices matter

An unagentable device is a security problem because the usual endpoint model does not work. If you cannot install or rely on a local agent, you lose the telemetry and enforcement path many tools assume, so security has to shift toward the network, the asset inventory and the trust boundary around the device itself.

This is common in embedded systems, industrial controllers, safety systems and specialised appliances where the firmware is proprietary, the operating environment is tightly constrained, or continuous uptime matters more than local security tooling. In those environments, the device may still be critical to business operations, but it cannot be treated like a normal managed endpoint.

Discovery and classification for unagentable assets

The first challenge is knowing what exists. Unagentable devices are often missed by standard endpoint tooling, so organisations need non-agent discovery methods such as passive network visibility, switch and firewall logs, DHCP and DNS records, CMDB correlation, and vendor documentation. Without that inventory, the device can become both unmanaged and invisible.

Classification matters because the security approach depends on what the device does, where it sits, and how sensitive the traffic is. A device that cannot run an agent should be tagged by function, owner, location and trust level so that security teams can decide whether it belongs on a restricted segment, behind a broker, or inside a tightly controlled management zone.

Control strategies when host telemetry is unavailable

When an endpoint agent is not possible, the control stack has to move outward. Network segmentation, allowlisting, NAC-style admission control, protocol-aware inspection and hardened jump paths become more important than local posture checks. The aim is to reduce the device's blast radius and make its communication paths predictable.

That also means accepting that compensating controls will be layered and imperfect. You may not be able to see processes or files on the device, but you can still constrain who can talk to it, what destinations it can reach, what management interfaces are exposed, and whether configuration drift is detectable through external monitoring.

Operational trade-offs and lifecycle pressure

Unagentable devices tend to create long-term governance pressure because their limitations rarely disappear after deployment. The organisation has to keep track of firmware constraints, vendor support cycles, replacement planning and exceptions to standard security policy, while making sure the device does not quietly age into an unreviewed risk.

That is why these assets often need explicit ownership and periodic review. If a device cannot be instrumented like the rest of the fleet, someone still has to own its classification, network placement, permitted communications and end-of-life path. Otherwise, the exception becomes the baseline.

Risk and Threat Considerations

Unagentable devices increase exposure because they are harder to observe, harder to harden consistently and often harder to remediate quickly. Attackers value that combination: if a device sits in a trusted network zone but cannot run a security agent, it may become a quiet pivot point, a persistence target or a weak link in segmentation assumptions.

Failure mechanism: Security teams lose endpoint-level visibility and control, so compromise can persist through network reachability, weak segmentation or unmanaged management interfaces rather than through the device's local security stack.

Impact: A single overlooked asset can expose sensitive traffic, enable lateral movement, or undermine the trust boundary of an otherwise well-managed environment.

Practitioner Guidance

What to watch for: Treat the inability to install an agent as a design constraint, not a temporary exception. If a device is unagentable, the security decision shifts to whether the organisation can compensate with network controls, monitoring and ownership that are strong enough for the asset's role.

Governance implication: The right question is not "can we protect it like a laptop?" but "what alternative control set makes this device acceptable to operate?" That usually means formal classification, documented exceptions and a clear replacement or containment plan for devices that cannot meet the normal baseline.

Related resources from NHI Mgmt Group

• Why does device binding matter in modern identity assurance?
• How should security teams govern device-bound payment credentials in open finance?
• What is the difference between device attestation and origin validation?
• What is the difference between device identity risk and workload identity risk?