A vulnerability scanner holds privileged credentials for most of your estate and a complete map of its exposures, so the way you configure it matters as much as the findings it produces. This guide covers Tenable One Vulnerability Management (the cloud platform) and Tenable Nessus as a defender would run them: choosing scan templates, setting up credentialed scans with dedicated accounts, deploying Tenable Agents, prioritising with the Vulnerability Priority Rating (VPR), and locking down API keys, roles and platform access. It is written for vulnerability management leads, platform owners and identity teams who own the scan accounts. For the vendor-neutral method behind all of this, see the Vulnerability Scanning Guide.
This is an independent guide from NHI Mgmt Group, based on Tenable's public documentation as of November 2026. It is not sponsored or reviewed by Tenable. Product features change, so confirm settings against Tenable's current documentation.
Key takeaways
- Credentialed scanning is the accuracy lever. Tenable recommends credentialed scans whenever possible, because they enumerate installed software and patches from the host itself rather than inferring them over the network.
- Scan accounts are privileged non-human identities. A Windows scan account usually needs local administrator rights, so give it a dedicated identity, store it in a vault integration and scope it with group policy.
- Combine agents and network scans. Tenable Agents cover laptops and sensitive hosts without stored credentials, while network scans see external exposure such as TLS services; Tenable recommends using both.
- Prioritise with VPR, report with CVSS. VPR runs from 0.1 to 10.0, updates daily from threat intelligence and helps decide what to fix first; CVSS severity stays useful for findings without a CVE.
- Treat API keys as secrets. Use one key pair per integration, store it in a secrets manager, restrict API access by IP allow list and regenerate keys when an integration owner changes.
What the tool does
Tenable Nessus is the scanning engine: it runs plugins against targets to detect vulnerabilities, missing patches and configuration drift. Tenable One Vulnerability Management is the cloud management platform that schedules scans across three sensor types, stores findings and assets, and adds prioritisation, dashboards and remediation tracking. Tenable Nessus Manager is the on-premises option for managing agents.
| Component | What it is | Typical use |
|---|---|---|
| Nessus scanner | Internal scanner you deploy and manage, linked to the platform | Credentialed and network scans of internal ranges, configuration (compliance) scans, tactical scans |
| Tenable Agent | Lightweight user space program installed on the host, reporting to Nessus Manager or the cloud platform | Laptops, remote workers, Domain Controllers, DMZ and other hosts where storing credentials is undesirable |
| Cloud scanner | Tenable-hosted scanner | Internet-facing assets seen from outside your network |
| Cloud connectors | Platform integrations with cloud providers | Ephemeral assets: connectors detect terminations and release licences |
The platform groups scans into assessment scans (find vulnerabilities), discovery scans such as Host Discovery (find assets, which do not count towards the licence), configuration scans that check settings against industry benchmarks, tactical scans for specific newly published issues, and agent-only Inventory Collection, which uses Frictionless Assessment for a smaller footprint.
Defender use cases
- Asset discovery: run Host Discovery across each network segment first, so assessment scans target known, owned ranges. Tenable describes an accurate asset inventory as the foundation of vulnerability management.
- Patch verification: the Credentialed Patch Audit template gives the Nessus scanner direct host access to enumerate missing patches, which is the evidence change boards and auditors ask for.
- Configuration assurance: configuration scans compare hosts to recognised benchmarks, turning hardening standards into measured findings that map to NIST SP 800-53 CM-6.
- Rapid response: tactical scans and remediation scans (started from a vulnerability's detail page) re-check affected assets outside the normal cycle once a fix is deployed.
- Remote and sensitive estates: agents scan laptops when they reconnect and cover Domain Controllers and certificate authority networks without placing a domain credential in the scanner.
- Integration feeds: the API exports findings to ticketing, SIEM and reporting pipelines, which is where API key hygiene becomes an identity concern.
Deployment and safe use
Choose the right template
| Template | Sensor | When to use it |
|---|---|---|
| Host Discovery | Nessus scanner | First pass on any new range; builds the asset list |
| Basic Network Scan / Basic Agent Scan | Scanner or agent | Default day-to-day vulnerability scanning with all current plugins |
| Advanced Network Scan / Advanced Agent Scan | Scanner or agent | Fine-tuned scans; Tenable cautions that misconfiguration can cause outages or network saturation, so test in a pilot range first |
| Credentialed Patch Audit | Nessus scanner | Patch compliance evidence |
| Collect Inventory | Agent | Low-footprint software and patch inventory |
Save a tuned configuration as a user-defined template and reuse it. When automating through the API, Tenable advises changing targets with the alt_targets parameter rather than creating a new policy per scan, and reusing on-demand schedules rather than multiplying them (there is a limit of 10,000 scan schedules).
Set up credentialed Windows scanning
- Create a dedicated account. Use a unique scan account, never a shared administrator. In a domain, Tenable describes creating a security group (for example "Nessus Local Access") containing the account and a GPO restricted group that adds it to local Administrators. Only Domain Administrator accounts can scan Domain Controllers, which is a strong reason to cover Domain Controllers with agents instead.
- Set the sharing model. Set "Network access: Sharing and security model for local accounts" to Classic so the account authenticates as itself rather than as Guest.
- Enable the services the checks use. Nessus uses SMB and WMI. Enable the predefined inbound rules for WMI (ASync-In, WMI-In, DCOM-In) and File and Printer Sharing (TCP 139 and 445), then narrow the WMI rule to the scanner IP addresses. Remote Registry is disabled by default and must run for registry checks; it can be set to manual so the scan starts it. Administrative shares (IPC$, ADMIN$, C$) are controlled by AutoShareServer and AutoShareWks.
- Handle UAC for local accounts. Tenable recommends the
LocalAccountTokenFilterPolicyregistry value set to 1 over turning UAC off. Apply it only where local account scanning is actually used. - Pilot and verify. Scan a pilot group, confirm authentication succeeded in the scan results, then widen the scope. Roll back by removing the GPO and disabling the scan account.
Set up credentialed Unix and Linux scanning
SSH credentials support public key, certificate, password and Kerberos authentication. Prefer key or certificate authentication and use the "Elevate privileges with" option (for example sudo) on a non-root account rather than logging in as root. The global "Attempt least privilege" setting tries lower privilege first and escalates only when a command fails; Tenable notes it can add up to 30% to scan time, so use it where least privilege matters more than speed. Database, VMware, SNMPv3, patch management and cloud service credentials are configured in the same Credentials area, and when several credentials of one type exist, Nessus tries them in the order added.
Keep scan credentials out of the scanner
The Host Credentials page lists integrations with a range of PAM and secrets vault products for Windows and SSH credentials, plus Windows LAPS. Use one of these so the scanner retrieves a rotating password at scan time instead of holding a static one. For on-premises Nessus, note that scan credentials are stored in the scanner's local database, so protect the scanner host as a tier zero system. See the Privileged Access Management Guide and the Local Administrator Password Solution (LAPS) Guide.
Deploy agents
Install agents through your software distribution tooling on Windows, macOS and Linux. After installation an agent links to its manager after a random delay of zero to five minutes to spread load; agents linked to the cloud platform download plugins after their first scan assignment. Tenable's guidance is to plan agents and network scans together: agents need no host credentials and keep scanning off-network devices, while network scans handle network checks and remote-only actions such as testing default credentials. Keep agent hosts online long enough to take plugin updates before scheduled scans, so each scan uses the current plugin set.
Detection and hardening value
Prioritise with VPR
VPR is calculated by Tenable, ranges from 0.1 to 10.0 (Critical 9.0 to 10.0, High 7.0 to 8.9, Medium 4.0 to 6.9, Low 0.1 to 3.9) and is updated daily. Its drivers include exploit code maturity, exploit probability, listing in CISA's catalogue of known exploitation, the intensity and recency of threat reporting, and targeted industries. Drivers reflect the global threat picture and are not tuned per customer, and VPR values are set by Tenable rather than by the customer. Findings without a CVE generally have no VPR, so remediate those on CVSS severity. A practical policy: fix VPR Critical on internet-facing assets first, then VPR High on servers holding sensitive data, and use CVSS for compliance reporting. See the Risk-Based Vulnerability Management Guide.
Harden platform access
| Control | Where it lives | Recommended setting |
|---|---|---|
| Single sign-on | Settings, SAML | Connect your SAML 2.0 identity provider so joiner and leaver controls and MFA apply at the IdP; leave assertion encryption off on the IdP side, as the platform docs specify |
| Two-factor authentication | Access Control, Users, Actions | Turn on for any account that signs in locally, starting with administrators |
| Roles | Access Control, Roles | Built-in roles range from Basic to Administrator; create custom roles for scan operators who should not manage users |
| User groups and permissions | Access Control, Groups and Permissions | Grant access to scanners, scan results and asset lists by team, not by individual |
| Target groups and access groups | Scans and Access Groups | Limit which hosts each team can scan and which findings it can see |
| API IP allow list | Access Control, API Access Security | List the egress addresses of your integration hosts; add both IPv4 and IPv6 ranges unless your network uses only one |
| Activity logs | Settings, Activity Logs | Export to your SIEM and alert on role changes, key generation and SAML changes |
Handle API keys as non-human credentials
Each user has one API key pair (an access key and a secret key) that works across all licensed products on the platform, so regenerating it for vulnerability management also changes it for web application and container scanning. Generating new keys replaces the old ones immediately, and the secret cannot be retrieved after you close the API Keys tab. That shapes the operating model:
- One integration, one identity: Tenable advises one API key per application. Create a dedicated service user per integration, with a custom role holding only the permissions it needs, so a key regeneration affects one pipeline.
- Store in a vault: place keys in a secrets manager and inject them at runtime. See the API Key Management Guide and the Secrets Management Guide.
- Rotate on change: regenerate keys on a schedule and whenever the owner of an integration leaves. Use the Users table's Last API Access column to find service users whose keys are stale.
- Restrict by network: combine per-user keys with the API Access Security allow list.
Keep the platform itself current
Apply Tenable security updates to Nessus scanners, Nessus Manager and agents promptly, and subscribe to the Tenable Product Security Advisories email list or RSS feed.
Measure it
- Credentialed scan success rate per scan (target above 95% of live hosts authenticated).
- Agent coverage: share of endpoints with a linked agent that reported in the last 7 days.
- Median time to remediate VPR Critical findings on internet-facing assets.
- Number of API keys older than your rotation period, and service users with keys and no recent API access.
- Stale asset count after age-out, which shows whether inventory hygiene keeps licence counts accurate.
Alternatives
Within the same platform, the main choice is between sensors, and most estates use all of them:
| Approach | Choose it when | Trade-off to plan for |
|---|---|---|
| Credentialed network scan | Servers on stable networks where a vaulted scan account is acceptable | Credential management for every host; transient devices are missed |
| Non-credentialed network scan | External view, network devices, quick discovery | Less accurate patch detail and some disruption risk |
| Agent scan | Laptops, Domain Controllers, DMZ hosts | Pair with a network or cloud scan for network checks |
| Cloud connector | Short-lived cloud workloads | Depends on cloud provider permissions granted to the connector |
Outside the tool, operating system patch compliance reporting and configuration management can confirm patch state, and the vendor-neutral method is covered in the Vulnerability Scanning Guide and the Authenticated vs Unauthenticated Scanning Guide.
Framework mapping
| Activity in the platform | NIST SP 800-53 Rev 5 | NIST CSF 2.0 |
|---|---|---|
| Assessment, agent and tactical scans | RA-5 Vulnerability Monitoring and Scanning | ID.RA-01 |
| Configuration scans against benchmarks | CM-6 Configuration Settings | PR.PS-01 |
| Dedicated, vaulted scan accounts and API keys | IA-5 Authenticator Management | PR.AA-01 |
| Custom roles, target groups, access groups | AC-6 Least Privilege | PR.AA-05 |
Practitioner checklist
- Run Host Discovery on every range before assessment scans and enable asset age-out to match your scan schedule.
- Create dedicated Windows and SSH scan accounts, scoped by GPO restricted groups or sudo rules, and retrieve them from a PAM or vault integration.
- Narrow WMI and SMB firewall rules to scanner addresses and set Remote Registry to manual rather than permanently running.
- Cover Domain Controllers, DMZ hosts and laptops with Tenable Agents, and pair them with network scans for external exposure.
- Pilot any Advanced Network Scan template on a test range before production use.
- Write a remediation policy that orders work by VPR and asset exposure, with CVSS for findings without a CVE.
- Connect SAML SSO, turn on two-factor authentication for local logins and assign custom roles with the least privilege needed.
- Issue one API key pair per integration on a dedicated service user, store it in a secrets manager and set the API IP allow list.
- Forward activity logs to your SIEM and alert on role changes and key generation.
- Apply Tenable security updates to scanners and agents promptly and subscribe to the product security advisories.
Standards and references
- Tenable: Scans (Tenable One Vulnerability Management)
- Tenable: Scan Best Practices
- Tenable: Credentialed Checks on Windows (Nessus)
- Tenable: Host Credentials (Nessus)
- Tenable: Agent Benefits and Limitations
- Tenable: CVSS vs. VPR
- Tenable: Generate API Keys
- Tenable: API Access Security
Related NHI Mgmt Group resources: Vulnerability Scanning Guide · Service Account Security Guide · API Key Management Guide · Risk-Based Vulnerability Management Guide