This document provides information about deploying Nessus Agents to perform unobtrusive, host-based, credential-free vulnerability scanning.


As part of the UT Austin Information Security Office's vulnerability management program, organizational units are required to deploy Nessus Agents, which are client-side applications that perform thorough, accurate scans of hosts without the need for traditional, credentialed network vulnerability scans.

Agent-based scanning provides more accurate results than traditional network scanning, allows for scanning of hosts that are only intermittently online, enables scanning of systems not connected to the campus network, and eliminates the need to send administrator credentials over the network to perform credentialed scanning. In combination with the ISO's automated network vulnerability scanning program, Nessus Agents provide organizational units with timely, accurate information about critical vulnerabilities, helping units to manage, mitigate, and remediate their IT risks. Armed with this information, units can identify and resolve vulnerabilities before they are exploited—heading off network quarantines, decreasing headaches for IT staff, and preventing system compromises.


For all computer systems, regardless of data classification, the deployment of Nessus Agents—or the configuration of credentialed network scanning—is required under §4.7.1 of the Minimum Security Standards for Systems. Given the nature of pivoting-style attacks, it is critical that the Nessus Agent is deployed on all systems used to conduct University business, regardless of whether the system is owned by the University.

As specified in §4.7.1, for systems on which the Nessus Agent is unsupported, or for systems on which its installation is otherwise not possible/desired (and for which an approved compliance exception request is in place), local accounts and firewall policies must be configured to allow for credentialed network scanning, instead.


Nessus Agent deployment is a two-step process: first, the Agent must be installed on the host system, then it must be linked to our Nessus Manager.

Verify system requirements

Nessus Agents are available for Macintosh, Windows, and Linux operating systems; they are not currently supported on mobile (Android or iOS) devices.

Tenable's Nessus Agent Software Requirements page lists the specific operating systems supported:

  • 10.9, 10.10, 10.11, 10.12, 10.13, 10.14, 10.15, 11.0, 12.0, and 13.0
  • 7, 8.1, and 10 (32/64-bit)
  • 11 (64-bit)
Windows Server
  • 2008 SP2 (incl. 32-bit), 2008 R2 SP1, 2012, 2012 R2, 2016, 2019, and 2022 (64-bit)
Red Hat
  • 6, 7, 8 and 9 (64-bit Intel)
  • 7, 8, and 9 (64-bit ARM)
Amazon Linux
  • 2015.03, 2015.09, 2017.09, 2018.03, and Amazon Linux 2 (64-bit Intel)
  • Amazon Linux 2 (64-bit ARM)
  • 9, 10 and Kali Linux 2017, 2018, 2019, 2020 (32/64-bit)
  • 11 (64-bit)
  • 10 and 11 (64-bit ARM)
  • 34, 35, and 36 (64-bit)
  • 7 (64-bit)
  • 7 (64-bit ARM)
Oracle Linux
  • 6, 7, 8, and 9 (64-bit Intel)
  • 7, 8, and 9 (64-bit ARM)
  • 12 and 15 (64-bit)
  • 14.04, 16.04, 18.04, 20.04, and 22.04 (64-bit Intel)
  • 18.04, 20.04, 22.04 (64-bit ARM)

Nessus Agents are designed to consume few resources, and thus require little in the way of available hardware. Minimum requirements include one (1) dual-core CPU running at 1 GHz, 1 GB of RAM, and at least 2 GB of available storage.

Additional information can be found at Nessus Agent Hardware Requirements.

Download and install Nessus Agent

Download the appropriate Nessus Agent installer directly from Tenable's Download Nessus Agents page, then follow the instructions at Nessus Agent Install for the host operating system:

For automated deployments, you may find our direct download links helpful; they bypass the license agreement prompt that is otherwise required when downloading installers directly from Tenable. See "Automating deployment", below, for more information.

After installing the Nessus Agent, link the Nessus Agent to the campus Nessus Manager.

Link to Nessus Manager

Nessus Agents must be linked to a controller, called a Nessus Manager, in order to download their initial plugin set, receive scan commands, and report results.

Linking happens at the command prompt, whether the host system is running macOS, Windows, or Linux.

The following commands are required parameters for linking Agents:

Linking Key 05d660528c40cfe1dd8cb21fad465e9bf8aee2403bffe310ec6c976a040bbb47
Port 8834
Agent Groups A quotation-mark enclosed, comma-separated list containing both:
  1. The system owner's official department code (such as INFS)
  2. The system's operating system (one of either Linux or Windows or macOS)

    The nessuscli agent command is used to link Agents; for more details, see nessuscli agent.

    Agent Group requirements

    While it is technically possible to link an Agent without specifying any Agent Groups, you will not receive the proper scan routines—nor will you be able to view a system's vulnerabilities—without specifying the appropriate groups at the time of linking.

    TIP Agent Group names are case-sensitive and quotation marks (") are necessary when specifying Agent Groups.

    Department codes must be four (4) characters, must use all uppercase letters, and must match your official department code found in the UT Austin Department System. Only one department code Agent Group should be assigned per Agent.

    TIP If a Nessus Agent will be installed on a system connected to a wired network owned by a specific department, then that same department should be used for the Agent group, in order to ensure that Isora GRC's inventory stays aligned. If this is not done, Agent-derived data may appear on one department's Isora GRC inventory sheet, while data for network-connected devices may appear on another department's inventory sheet. In addition to creating general confusion, duplicate inventory entries lead the UT Inventory team to disregard assets when determining whether a device is "found" on the network.


    To link a Linux system, use sudo or a root account with a command patterned after:

    /opt/nessus_agent/sbin/nessuscli agent link --groups="UNIT,Linux" --key="05d660528c40cfe1dd8cb21fad465e9bf8aee2403bffe310ec6c976a040bbb47" --host="" --port="8834" --offline-install="yes"

    where "UNIT" is the system owner's official department code (see "Agent Group requirements", above).


    To link a Windows system, launch an elevated command prompt and use a command patterned after:

    msiexec /i NessusAgent-<version number>-x64.msi NESSUS_GROUPS="UNIT,Windows" NESSUS_KEY="05d660528c40cfe1dd8cb21fad465e9bf8aee2403bffe310ec6c976a040bbb47" NESSUS_SERVER="" NESSUS_OFFLINE_INSTALL="yes" /qn

    where "UNIT" is the system owner's official department code (see "Agent Group requirements", above).


    To link a macOS system, use sudo or a root account with a command patterned after:

    /Library/NessusAgent/run/sbin/nessuscli agent link --groups="UNIT,macOS" --key="05d660528c40cfe1dd8cb21fad465e9bf8aee2403bffe310ec6c976a040bbb47" --host="" --port="8834" --offline-install="yes"

    where "UNIT" is the system owner's official department code (see "Agent Group requirements", above).

    Automating deployment

    Though outside the scope of this document, Nessus Agent installation and linking can be automated using system management tools such as Jamf Pro, Ivanti EPM, SCCM, Group Policy, Puppet, Chef, and Ansible.

    The Nessus Agent Large-Scale Deployment Guide may be useful if you are planning a fleet-wide deployment.

    Deploying with Jamf Pro, Ivanti EPM, and SCCM

    Guides for automating deployment using the following systems management tools are available:

    • Jamf Pro, courtesy of James Cutrone, College of Education
    • Ivanti EPM, courtesy of James Cutrone, College of Education
    • SCCM, courtesy of Nathaniel Selman, School of Engineering

    Deploying Agents inside pre-built images

    Never include an already-linked Nessus Agent in an image that gets deployed to more than one system. To include the Nessus Agent in a distributable system image for use with imaging and configuration management platforms, see the following:

    Installer package automation

    For automated deployments, you may find our direct download links helpful; they bypass the license agreement prompt that is otherwise required when downloading installers directly from Tenable. This may let you avoid the need to download and package installers prior to deployment, and obviates any need to keep packages updated manually.

    Operating System Link
    Windows (64-bit) and Windows Server /nessus-agents/deploy/win-64
    Windows (32-bit) /nessus-agents/deploy/win-32
    macOS /nessus-agents/deploy/macos
    Amazon Linux /nessus-agents/deploy/amazon-linux
    Debian and Kali Linux (64-bit) /nessus-agents/deploy/debian
    Red Hat 6, CentOS 6, and Oracle Linux 6 (64-bit) /nessus-agents/deploy/rhel-6
    Red Hat 7, CentOS 7, and Oracle Linux 7 (64-bit) /nessus-agents/deploy/rhel-7
    Red Hat 8 and Oracle Linux 8 (64-bit)
    Red Hat 9 and Oracle Linux 9 (64-bit)
    Fedora (64-bit) /nessus-agents/deploy/fedora
    Ubuntu (64-bit) /nessus-agents/deploy/ubuntu

    Note that we do not support direct download links for every operating system supported by Tenable; if you would like us to support additional operating system installer packages, please email

    Agent groups for centralized IT support organizations

    For organizations that provide centralized IT support—particularly those that provide support beyond the IT organization's department code—linking supported Agents with an additional, third Agent group allows for easier grouping of Agent-derived vulnerability data in Splunk.

    For systems supported by:

    • Technology Resources, use the additional group supportedby_FISH
    • Liberal Arts Instructional Technology Services, use the additional group supportedby_COLA

    These Agent groups should only be used when linking computer systems managed by these centralized IT support organizations.

    Performance tuning

    In very rare cases, users have observed performance impacts correlated to Nessus Agent scan routines. More information about the resource usage of Nessus Agents, and tuning systems to minimize Nessus Agent impact, is available from Tenable:

    Ongoing Agent management

    Nessus Agents receive updates for both their scan plugin set, and the Agent binary itself, from the central Nessus Manager, so IT staff do not need to manage the patching of Nessus Agents.

    The status of a system's Nessus Agent can be queried using the "nessuscli agent status" command; see nessuscli agent for more information.

    Hostname updates

    By default, the name of an Agent is the hostname of its host system at the time the Agent was linked, and does not change. However, as of January 2023, all Nessus Agents now update their hostnames automatically. You may notice Agent names (designated as agent_name in Splunk) change as systems move between networks. No change is needed on the client side to enable this functionality.

    Transferring systems with Agents between units

    When transferring systems between units, or when the Agent groups of an already-linked Agent otherwise need changing, special procedures must be used. To add or remove Agent groups for a currently-linked or previously-linked Nessus Agent, you must:

    1. Unlink the Agent (if it is currently linked),
    2. Reset the Agent's UUID, and
    3. Re-link the Agent, specifying every desired Agent group.

    TIP Simply re-linking a Nessus Agent using additional or fewer Agent groups before the Agent's UUID has been reset will have unexpected results. Please do not attempt this shortcut!

    To unlink an Agent, use the "nessuscli agent unlink" command; see nessuscli agent for more information.

    To reset an Agent's UUID:

    • On Windows systems, use regedit to delete the HKEY_LOCAL_MACHINE/Software/Tenable/TAG Registry entry.
    • On macOS systems, delete the /private/etc/tenable_tag file.
    • On Linux systems, delete the /etc/tenable_tag and/or /etc/machine_id files.

    Once an Agent has been unlinked and its UUID reset, re-link it using the standard instructions, above.

    Decommissioning systems with Agents

    Be sure to un-link the Nessus Agent on a system before it is decommissioned (for example, to be sent to Surplus Property). To unlink an Agent, use the "nessuscli agent unlink" command; see nessuscli agent for more information.

    Currently, Agents are neither programmatically un-linked nor deleted from the Nessus Manager due to inactivity; decommissioned systems whose Agents are left linked will remain in the "offline" state in perpetuity, and will remain in Isora GRC's inventory. To request removal of offline Agents whose host systems were decommissioned before their Agents were un-linked, please contact

    Scan scheduling

    Our primary Nessus Agent vulnerability scans currently happen every weekday from 11 AM through 3 PM. Any host that is online during a scheduled scan window will report its scan results, which become available in Splunk, generally same-day by 10 PM.

    All scans are configured and scheduled by the Information Security Office. Scans cannot be scheduled on-demand, and there are no end-user controls to manage Agent scanning.

    Viewing scan results

    Departmental Technical Support Contacts (TSCs) can view the results of's Agent scans (as well as the ISO's network-based vulnerability scans) in Splunk. Custom dashboards are available for reporting on hosts scanned by

    Agent scan results reside in the utexas-chomp index and are tagged with repository_dataFormat="Agent". Aside from the available dashboards, the following Splunk query is a good starting place to identify Agent-derived vulnerabilities in your department; be sure to replace UNIT with your department code:

    index="utexas-chomp" app="TENABLE" earliest="-7d" repository_dataFormat="Agent" tenable_scan_name="Daily Scan*" severity_name!="Info" deptcode="UNIT"
    | dedup uuid pluginID
    | rex field=pluginText mode=sed "s/\|/\n/g" 
    | table _time agent_name agent_ip severity_name pluginName pluginText
    | sort by severity_name

    TSCs are only authorized to view vulnerabilities found on systems that are linked to their organizational unit.

    Note that it may take 1-2 business days for newly-deployed Nessus Agents to begin reporting their results to Splunk.

    Tracking policy compliance and Agent health

    To track whether systems in your organizational unit are compliant with the requirement to deploy Nessus Agents to all supported devices, see the "Nessus Agent Compliance" panel of the Departmental Scorecards in Splunk.

    To track the health of linked, previously linked, and un-linked Agents, see the Dude, Where's My Nessus Agent? dashboard in Splunk. This dashboard shows which Agents are functioning properly ("Perfect Agents")—as well as which Agent installations are in need of attention ("Problematic Agents"), either because they:

    • have not been scanned in the past 90 days,
    • have an outdated plugin feed,
    • have an outdated Nessus Agent binary installed, or
    • are un-linked.

    Inventory management integration

    Nessus Agents can be used to identify both on- and off-campus systems for the purposes of UT inventory management.

    For a system to appear as "found" in UT inventory, the following conditions must be met:

    • A Nessus Agent must be deployed to the system and it must be properly linked
    • The system must have undergone at least one Agent scan
    • The system must be listed in Isora GRC Inventory with its UT inventory tag and MAC address

    A system with a Nessus Agent will automatically appear in your department's "Uncurated Hosts" sheet in Isora GRC Inventory after its initial Agent scan, and the Isora GRC entry will include all of the system's detected MAC addresses. You must copy this entry into your department's Isora GRC Inventory sheet, and ensure that the UT inventory tag is added for the system, in order for the system to be marked as "found" for UT inventory purposes. Once moved to your departmental inventory sheet, the system will automatically disappear from the Uncurated Hosts sheet.


    To track the health of linked, previously linked, and un-linked Agents, see the Dude, Where's My Nessus Agent? dashboard in Splunk.

    After you've identified a problematic Nessus Agent installation, on the host, use the command "nessuscli agent status --show-uuid" to view the current status of the installed Nessus Agent. The location of the nessuscli binary is listed at nessuscli agent.

    If nothing is returned, Nessus Agent may not be installed, or the service may be stopped. Try to start or restart the Nessus Agent service using the instructions at Start or Stop a Nessus Agent. Otherwise, the output will generally point to the problem.

    Most often, the Agent has become un-linked from the Nessus Manager, with a link status of "Not linked to a manager". To resolve the issue, re-link the Agent; use sudo, the root account, or an elevated command prompt to run:

    nessuscli agent link --key="05d660528c40cfe1dd8cb21fad465e9bf8aee2403bffe310ec6c976a040bbb47" --host="" --port="8834"

    Assuming the Agent has been previously linked, and the original Agent groups remain correct, Agent groups do not need to be specified during re-linking. Check the status of the Nessus Agent again; it should show that it is successfully linked and connected, with a "last successful connection to controller" in the recent past.

    Automating health checks

    Organizations with large Agent deployments may benefit from periodically checking each system for a successfully linked Nessus Agent. When an Agent reports that its link status is "Not linked to a manager", the Agent should be programmatically re-linked in the manner described under "Troubleshooting", above.


    Please contact us at with any questions about Nessus Agents or vulnerability scanning.

    For Agent issues related to specific hosts, please include the following information when requesting assistance:

    • Current hostname
    • Current IP address
    • Complete output of "nessuscli agent status --show-uuid" (see nessuscli agent for more information)
    • The contents of the Nessus Agent "logs" directory (see Manage Logs for the directory's location)