Agents

Agents increase scan flexibility by making it easy to scan assets without needing ongoing host credentials or assets that are offline. Agents allow for large-scale concurrent scanning with little network impact.

After you install a Tenable Agent on a host and link the agent to Tenable Vulnerability Management, the agent appears on the Tenable Vulnerability Management Linked Agents page.

Tenable Agents are host-based sensors that you install directly on your endpoints (for example, servers, laptops, and desktops).

Unlike traditional network scanners that scan assets from the outside, agents operate from within the operating system. This provides visibility into assets that are transient, offline, or difficult to scan remotely.

To manage your linked agents, see Manage Linked Agents.

How Agents Work

To architect your deployment effectively, you must understand the following technical behaviors:

  • Local Processing — The agent runs as a service on the host. When a scan window opens, the agent compiles vulnerability data locally using its own CPU and memory, then compresses and uploads the results to Tenable Vulnerability Management.

  • Outbound Communication — Agents are designed for strict firewall environments. They initiate all communication via outbound TCP port 443 to the Tenable cloud. They do not require you to open any inbound ports.

  • Asynchronous Scanning — If an agent is offline during a scheduled scan window, you can configure it to run the scan as soon as it comes back online. This ensures you do not miss results for employees who are traveling or working in different time zones.

  • Manager Check-in — Linked agents check in with Tenable Vulnerability Management on start, after a restart, and whenever metadata is updated (no more than every 10 minutes).

Key Use Cases

Security engineers typically deploy agents to solve specific coverage gaps that network scanners cannot address:

  • Transient Devices — Laptops that leave the corporate network (for example, remote workers on public networks) can still report vulnerabilities over the internet without a VPN connection.

  • Credential Management — Because the agent runs as System or Root, it automatically has full access to the local file system. This eliminates the need to manage and rotate service account credentials (like SSH keys or WMI passwords) for every host.

  • Hardened Segments — For Demilitarized Zones (DMZs) or isolated networks where inbound SMB/SSH is strictly blocked, agents provide a way to extract vulnerability data via a single outbound HTTPS stream.

Deployment Workflow

Getting data from an agent involves installation, linking, and organization.

  1. Installation — Deploy the agent software (MSI, RPM, DEB) to the host using your standard deployment tools (such as SCCM, Jamf, or Ansible).

  2. Linking — During installation, you must provide a linking key. This key authenticates the agent to your specific Tenable container. Once linked, the agent is "online" but idle.

  3. Organization — Configure agent groups, agent profiles and networks to manage the agents effectively.

Manage Agents at Scale

Managing agents at scale requires the use of groups for targeting and profiles for configuration.

  • Agent Groups (Targeting) — You cannot launch a scan against an individual agent; you must scan an agent group. Groups allow you to organize agents logically (for example, "Windows Servers" or "Remote Laptops"). When you configure a scan in Tenable Vulnerability Management, you select these groups as the scan targets.

  • Agent Profiles (Configuration) — Profiles allow you to manage the behavior of the agents themselves. You use profiles to control:

    • Software updates — Specify which version of the agent software your endpoints run.

    • Freeze windows — Prevent agents from upgrading or making changes during critical business hours.

    • Performance — Limit the CPU resources the agent is allowed to consume on the host.

  • Networks (Segmentation) — Networks are logical segments used to distinguish overlapping IP addresses. For example, if you have agents deployed in two different branch offices that both use the 192.168.1.x range, you assign those agents to different networks. This ensures Tenable Vulnerability Management treats the assets as distinct entities.

Data Collected

Once active, agents collect and report the following metadata to help with asset identification and vulnerability assessment:

  • Version information (agent version, host architecture)

  • Versions of installed Tenable plugins

  • OS information (for example, Microsoft Windows Server 2008 R2 Enterprise Service Pack 1)

  • Tenable asset IDs (for example, /etc/tenable_tag on Unix, HKEY_LOCAL_MACHINE\SOFTWARE\Tenable\TAG on Windows)

  • Network interface information (network interface names, MAC addresses, IPv4 and IPv6 addresses, hostnames and DNS information if available)

  • Hostname if update_hostname is set to yes (see Tenable Agent Advanced Settings for more information)

  • ClosedAWS EC2 instance metadata, if available:

    Note:Tenable Agent connect to 169.254.169.254 to provide AWS metadata to Tenable Vulnerability Management; traffic between Tenable Agent and 169.254.169.254 is normal and expected behavior.

    • privatelp

    • accountId

    • imageId

    • region

    • instanceType

    • availabilityZone

    • architecture

    • instanceId

    • local-hostname

    • public-hostname

    • public-ipv4

    • mac

    • iam/security-credentials/

    • public-keys/0/openssh-key

    • security-groups