Nessus agents
Pulls the agents linked to a Nessus manager, with their platform, link state and scan history.
| Type name | nessus_agents |
| Creates | Endpoints |
| Runs on | A sensor with network reach to the Nessus manager |
| Presence flag | nessus_exits |
| Field prefix | nessus_ |
What it contributes
- Identity — agent ID, UUID, name
- Network — IP, MAC addresses
- Platform — platform, distro, upgrade distro
- Agent build — core version, core build, plugin feed ID
- Link state — link status, linked on, unlinked on, auto-unlinked, last connect, status
- Scan state — last scanned
- Grouping — groups, link groups, cluster group ID
- Cluster topology — node ID, node host, node name
- Settings — remote logs, remote settings, settings pending, settings staged, log directory
Alongside its own nessus_* fields it writes the shared asset fields, so its
agents correlate against every other source. os, type and mac are written in
do-not-override mode, so Nessus fills them when they are empty but will not
overwrite what an EDR agent already asserted. See
Exported fields for the complete list.
nessus_last_scanned is a coverage metric, not an inventory oneAn agent that is linked but has not been scanned in months is a vulnerability
blind spot even though the asset looks covered. Filter on the gap between
nessus_last_connect and nessus_last_scanned.
Requirements
The integration is outbound-only: it reads the Nessus API on a schedule, so nothing is installed on the manager, nothing changes on the agents, and nothing has to reach into the deployment.
Network access
| From | To | Protocol | Port |
|---|---|---|---|
| The sensor running the integration | The Nessus manager named in URL | HTTPS over TCP | Whatever the URL names — 8834 on a default Nessus Manager install |
Nessus managers commonly present a self-signed certificate. Install its CA on the sensor host in preference to enabling Ignore SSL — the API keys are sent on every request, as the note under Generating the API keys explains.
Access in Nessus
| Need | Why |
|---|---|
| An account that can generate API keys | The credential is an access key and secret key pair, generated under My Account → API Keys. See Generating the API keys in Nessus |
| That account able to list agents | Nessus keys inherit their creator's permissions, so the account, not the key, decides what the run can read |
| A product variant that exposes the agents API | The run reads /agents and /agents/{id}; not every Nessus product exposes them |
In this deployment
| Need | Why |
|---|---|
| A registered, healthy sensor with reach to the manager | The integration runs on a sensor, on the platform's schedule — see Sensors |
| The agent group names to collect | Nessus groups is mandatory and scopes the run — see the warning under Configuration |
Configuration
| Field | Required | Notes |
|---|---|---|
| Name | Yes | Label for this instance |
| URL | Yes | Nessus manager base URL, e.g. https://nessus.example.com:8834 |
| Access ID | Yes | The Access Key shown when the API keys were generated |
| Secret key | Yes | The Secret Key shown alongside it, once |
| Nessus groups | Yes | Comma-separated list of agent groups to pull |
| Cookies | No | Extra cookies added to requests |
| Sensor | Yes | Sensor that will run the integration |
| Ignore SSL | No | Skips certificate validation — leave off against a manager with a trusted CA |
Nessus groups is mandatory and scopes what the run collects. Agents outside the listed groups are not pulled, and no warning is raised — so an agent group created after this instance was configured stays invisible until you add it here.
Generating the API keys in Nessus
In the Nessus console, open My Account from the top-right corner, go to the API Keys tab and choose Generate. Nessus issues a fresh key pair and shows both values on that screen — they are what you enter when creating the integration instance:
| Nessus shows | Enter it as | Example |
|---|---|---|
| Access Key | Access ID | a1b2c3d4e5f6... |
| Secret Key | Secret key | shown once, at generation |
The keys belong to the user account, not to a client, so Generate invalidates whatever pair that account was already using. If another integration or script authenticates as the same user it will start failing the moment you press it — give this integration its own account rather than sharing one.
Nessus keys inherit the permissions of the user who created them, so generate them under a dedicated read-only account that can list agents rather than under an administrator.
Confirm the minimum Nessus user role that can read /agents and /agents/{id} on
current Nessus Manager and Tenable.sc versions, and note which product variants
expose the agents API at all.
Nessus managers are commonly deployed with a self-signed certificate. Install its CA on the sensor host in preference to enabling Ignore SSL — the API keys are sent on every request.
The integration then authenticates with the X-ApiKeys header, pages /agents,
and fetches /agents/{id} for per-agent detail.
Exported fields
Each agent returned by /agents/{id} becomes one asset record. The integration
copies the Nessus agent attributes into fields prefixed nessus_, keeping the
Nessus name so a value in the platform can always be traced back to the agent
record it came from, and additionally writes the shared fields that make the agent
correlate with other sources.
One rule drops records before anything is written: an agent whose groups do not intersect the Nessus groups list configured on the instance. Every agent that survives that filter is written — see the note on offline agents below.
Identity
| Field | Type | Holds |
|---|---|---|
nessus_exits | Boolean | Always true — the presence flag marking this asset as Nessus-covered |
nessus_id | Text | Nessus agent ID. This is the value the run feeds back into /agents/{id} to fetch per-agent detail |
nessus_uuid | Text | Agent UUID. The strongest match key — an existing asset carrying the same nessus_uuid is what the run correlates against first |
nessus_name | Text | Agent name as Nessus reports it |
Network
| Field | Type | Holds |
|---|---|---|
nessus_ip | IP | Address the agent reports |
nessus_mac_addrs | Text | MAC addresses of the agent's adapters — an array in the source record |
Platform
| Field | Type | Holds |
|---|---|---|
nessus_platform | Text | Platform as Nessus reports it. This single value is the input to all three of the normalised os, os_vendor and type |
nessus_distro | Text | Distribution |
nessus_upgrade_distro | Text | Full distribution string |
Agent build
| Field | Type | Holds |
|---|---|---|
nessus_core_version | Text | Agent core version |
nessus_core_build | Text | Agent core build |
nessus_plugin_feed_id | Text | Plugin feed the agent last received. Compare it across the estate to find agents scanning on a stale plugin set |
Link state
| Field | Type | Holds |
|---|---|---|
nessus_link_status | Text | Link status of the agent |
nessus_status | Text | Agent status |
nessus_linked_on | Date/time | When the agent was linked to the manager |
nessus_unlinked_on | Date/time | When the agent was unlinked, if it has been |
nessus_auto_unlinked | Text | Whether the manager unlinked the agent automatically — a number in the source record |
nessus_last_connect | Date/time | When the agent last connected to the manager. Also the value behind the shared first_seen and last_seen |
Scan state
| Field | Type | Holds |
|---|---|---|
nessus_last_scanned | Date/time | When the agent was last scanned |
Grouping
| Field | Type | Holds |
|---|---|---|
nessus_groups | Text | Agent groups the agent belongs to — an array in the source record. This is also the field the Nessus groups filter is matched against |
nessus_link_groups | Text | Link group |
nessus_cluster_group_id | Text | Cluster group ID |
Cluster topology
| Field | Type | Holds |
|---|---|---|
nessus_node_id | Text | ID of the cluster node the agent is assigned to |
nessus_node_host | Text | Host of that node |
nessus_node_name | Text | Name of that node |
Settings
| Field | Type | Holds |
|---|---|---|
nessus_remote_logs | Text | Remote logging state — a number in the source record |
nessus_remote_settings | Text | Remote settings state — a number in the source record |
nessus_settingsPending | Text | Whether settings changes are pending on the agent — a number in the source record |
nessus_settingsStaged | Text | Whether settings changes are staged on the agent — a number in the source record |
nessus_log_directory | Text | Log directory on the agent host |
Shared fields it writes
These are the normalised, source-independent fields. They are what other integrations correlate against, so their values are cleaned up rather than copied verbatim:
| Shared field | Derived from |
|---|---|
names | nessus_name |
private_ip | nessus_ip |
mac | nessus_mac_addrs — do-not-override |
os | nessus_platform, normalised to a canonical name such as Windows 11 or Ubuntu 20.04 — do-not-override |
os_vendor | nessus_platform, normalised to Windows, Linux, MacOS, OpenBSD or VMware |
type | Inferred from the normalised os — Endpoint, Server, Hypervisor and similar — do-not-override |
first_seen | nessus_last_connect, on the run that creates the asset |
last_seen | nessus_last_connect |
updated_at | Time of the run that produced the record |
os is protected from overwrite but os_vendor is notos, type and mac are do-not-override, so a richer source keeps them.
names, private_ip and os_vendor are not — a Nessus run will overwrite what
another integration asserted. Where a host looks inconsistent, os coming from an
EDR while os_vendor came from Nessus is the usual explanation.
Ignore if host is offline appears in this instance's advanced settings, but
this integration never applies it — an agent that has not connected in a year is
still written. Filter on nessus_last_connect in a view or report instead of
relying on that setting.
See also
- Integrations overview — the shared configuration model
- Scanning — the platform's own scanning, which is separate from Nessus