Nessus Credentialed Scanning: Setup, Scan Policy Configuration, and Vulnerability Prioritization Workflow
Retool's new app builder is where AI-generated code ships safely
Building apps with AI is easy. Getting them to production safely is another story.
Ran Nessus unauthenticated scans on a 400-server environment for six months and reported a clean vulnerability posture to leadership — average of 12 findings per server, mostly medium-severity SSL configuration issues and banner disclosure vulnerabilities. Then switched to credentialed scans after configuring the service account and firewall exceptions, and the first scan returned 87 findings per server on average, including 14 Critical-severity findings across 60% of servers. Most were missing Windows patches that had been applied to the WSUS server but not actually deployed to workstations and servers due to a WSUS client configuration issue that the unauthenticated scan could not detect.
This experience is common. Unauthenticated scan results give the appearance of a managed vulnerability posture without the substance — they catch what is visible from the network while missing the vast majority of what is exploitable by any attacker who gains initial access. Credentialed scans are the realistic baseline for understanding what is actually patchable and actually exploitable in the environment.
Credential configuration: Windows and Linux service account setup
Credentialed scan reliability depends almost entirely on getting the service account configuration right on target hosts. Nessus uses SMB for Windows and SSH for Linux, and both require specific host-side configuration that does not happen by default. Missing one step — a firewall exception, a registry key, a sudo permission — causes silent authentication failure that produces incomplete scan results without obvious error messaging in the scan results UI.
Create a dedicated Active Directory service account for Nessus scanning with minimum necessary permissions
Create a dedicated Active Directory service account (svc-nessus-scan) rather than using an existing administrator account, enabling the scanning account to be specifically tracked, its permissions audited independently, and its access revoked if the scanner is decommissioned without affecting other administrator accounts. The account needs local administrator rights on all Windows scan targets (add it to the local Administrators group via GPO restricted groups) and the LocalAccountTokenFilterPolicy registry key set to 1 on all targets (via GPO: deploy registry key HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\LocalAccountTokenFilterPolicy with DWORD value 1). Set the service account password to a 25-character randomly generated value, document it in the organization's password vault, and configure the account to never expire. Rotate the password annually and after any personnel change that had access to the vault entry.
Verify credentialed scan authentication using the Plugin 21745 coverage metric before trusting scan results
After the first credentialed scan of any new host group, check the Plugin ID 21745 rate before presenting the results. A high 21745 rate (more than 10% of scanned hosts showing authentication failure) indicates a systemic configuration issue — WMI not enabled, firewall blocking SMB, or the LocalAccountTokenFilterPolicy not applied — that must be resolved before the scan results are meaningful. Filter the scan results by Plugin ID 21745, group by the failure message in the plugin output, and address the most common failure message first since it will remediate the largest number of hosts. After fixing the systemic issue, re-run the scan against the affected host group and verify the Plugin 12634 success rate has improved. Do not report vulnerability findings to stakeholders until the credentialed coverage rate exceeds 90%, because the vulnerability count per host increases 5-10x between unauthenticated and credentialed results — a low credentialed coverage rate means the reported vulnerability count is severely understated.
Result analysis: prioritization and remediation tracking
Nessus findings without a prioritization and tracking workflow produce a vulnerability database that grows faster than it is remediated, eventually becoming too large to manage and too stale to be meaningful. The prioritization model — CVSS score plus exploitability plus asset criticality — distills thousands of findings into a manageable daily remediation queue. The tracking workflow converts that queue into closed tickets with confirmed re-scan verification.
Use scan comparison to identify net-new vulnerabilities introduced since the previous scan
Configure Nessus scan comparison to show only new findings since the previous scan rather than all current findings, enabling the vulnerability management workflow to focus on newly introduced issues without re-triaging previously known vulnerabilities. In Nessus, use the scan history comparison feature to select two scan dates and view the Added (new in latest), Removed (fixed since last scan), and Unchanged (still present) vulnerability categories. The Added category represents new findings that require immediate triage and ticket creation. The Removed category represents fixes that can be used to close existing tickets after re-scan verification. Tracking the ratio of Added to Removed over time shows whether the organization is net-reducing its vulnerability count (Removed > Added each scan cycle) or accumulating debt (Added > Removed). A scan cycle where Added significantly exceeds Removed despite active remediation work indicates either a new deployment of vulnerable software, a Windows update cycle that failed, or a scan coverage expansion that brought new hosts into scope.
Schedule scans to align with the patch management cycle for accurate pre-patch and post-patch verification
Schedule Nessus scans to run both before and after each patch management cycle to verify that patching actually closed the vulnerabilities it was expected to close. Run the pre-patch scan 48 hours before the patch window to establish the baseline finding count, run the post-patch scan 24-48 hours after the patch window completes to verify closure, and compare the results using the scan history comparison. A post-patch scan that shows the same Critical findings as the pre-patch scan despite the patch being marked as applied in SCCM or WSUS indicates a patching failure — the patch did not install, was rolled back, or was applied to a different host group than intended. Post-patch verification scanning is the only reliable mechanism for confirming patch deployment success at the host configuration level rather than at the deployment system status level, where records can show Success without the patch actually taking effect.
Briefings like this, every morning before 9am.
Threat intel, active CVEs, and campaign alerts, distilled for practitioners. 50,000+ subscribers. No noise.
The bottom line
Nessus credentialed scanning delivers 5-10x more vulnerability findings than unauthenticated scanning and provides the accurate software inventory, patch level, and configuration data needed for a defensible vulnerability management program. Configure Windows credentialed scanning with a dedicated service account, LocalAccountTokenFilterPolicy registry key via GPO, and WMI/SMB firewall exceptions. Configure Linux credentialed scanning with SSH key authentication and sudo privilege escalation to root. Verify credentialed scan success with the Plugin ID 21745 coverage metric before trusting any scan results. Prioritize findings using CVSS 7.0+ as the baseline filter, exploitability status for Critical-tier escalation, and asset criticality for triage ordering. Track remediation with API-integrated ticketing and require re-scan verification before closing tickets. Schedule scans around patch cycles to verify patch deployment effectiveness at the host configuration level rather than relying on deployment system status.
Frequently asked questions
How do I set up credentialed scanning for Windows hosts in Nessus?
Set up Windows credentialed scanning by configuring the target hosts to accept SMB authentication from the Nessus service account and creating the scan credential in Nessus. On each Windows target host (or via GPO for the entire domain), configure: the Windows Firewall to allow File and Printer Sharing and WMI traffic from the Nessus scanner IP, the WMI service running (it is enabled by default on domain-joined hosts), and for non-domain accounts or workgroup environments, set HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\LocalAccountTokenFilterPolicy to DWORD value 1 (without this, administrator credentials from non-domain accounts are filtered to standard user access, causing authentication failure). In Nessus, create a credential under Settings > Credentials > Add Credential > Windows, using the domain\serviceaccount format for domain credentials or .\localadmin for local accounts. The Nessus service account needs local administrator privileges on target hosts to read the registry keys, software inventory, and patch level that credentialed checks require. After configuring the credential, run a scan with Plugin ID 21745 check: if this plugin fires for any host, that host's credential failed and the results are unauthenticated-only.
How do I configure SSH credentialed scanning for Linux hosts in Nessus?
Configure Linux credentialed scanning with SSH key-based authentication and privilege escalation for the local root checks that require elevated access. Generate an SSH key pair specifically for Nessus scanning: ssh-keygen -t ed25519 -f nessus_scanner_key -C 'nessus-scanner' with no passphrase (Nessus runs automated scans without human interaction to type a passphrase). Add the nessus_scanner_key.pub public key to the authorized_keys file of the nessus-scan user on all Linux targets. In Nessus, create an SSH credential under Settings > Credentials > Add Credential > SSH, upload the nessus_scanner_key private key, set the username to nessus-scan, and configure privilege escalation to sudo with the sudo command as /bin/sudo and the escalation account as root. Configure the sudoers file on Linux targets to allow the nessus-scan user to run commands without a password: nessus-scan ALL=(root) NOPASSWD:ALL or restrict to specific commands that Nessus uses if you want minimal privilege. The escalation to root is required for Nessus to read kernel-level configuration, network stack settings, and root-owned files that credentialed checks evaluate.
How do I build a scan policy in Nessus to balance thoroughness with scan duration?
Build a balanced Nessus scan policy by selecting plugin families relevant to your environment and disabling plugin families that generate excessive scan time without corresponding security value. Start with the Advanced Scan template which allows full plugin control. Enable these plugin families for Windows targets: Windows, Windows: Microsoft Bulletins, Windows: User Management, Settings, Compliance Check (if doing baseline compliance), and Credentials. Enable for Linux targets: General, Misc., Ubuntu Local Security Checks (or the relevant distro's plugin family), Unix. Disable plugin families that increase scan duration without security relevance for internal scanning: CGI abuses (web application attack testing, inappropriate for internal compliance scans), Denial of Service (can crash target hosts), and Web Servers (if not scanning for web vulnerabilities in this scan). Set the Maximum number of simultaneous checks per host to 5 for internal scans (reduces individual host scan time while limiting load on targets) and Maximum number of simultaneous hosts per scan to 30 for a distributed scan. A well-tuned policy completes a credentialed scan of 500 Windows hosts in 4-6 hours rather than 12-18 hours with default settings.
How do I prioritize Nessus findings for remediation when there are hundreds of vulnerabilities?
Prioritize Nessus vulnerability findings using a three-factor scoring model that combines CVSS severity, exploitability status, and asset criticality. First filter by CVSS: focus remediation effort exclusively on CVSS 7.0+ (High and Critical) findings in the first triage pass — CVSS below 7.0 findings should go into a separate lower-priority queue. Second, within the High/Critical results, sort by exploitability: Nessus marks findings where a public exploit exists in the plugin details (the Plugin Details section shows 'Exploit Available: true' and links to Exploit-DB or Metasploit references). Exploitable Critical CVEs are the top priority regardless of CVSS score. Third, weight by asset criticality: a Critical CVE on a PCI-scoped server is higher priority than the same CVE on an isolated development workstation. In Nessus Professional or Tenable.io, use the VPR (Vulnerability Priority Rating) score rather than CVSS — VPR incorporates real-world exploit activity and asset exposure into a composite score that is more actionable than CVSS alone. Set remediation SLAs of 15 days for Critical+Exploitable, 30 days for Critical without public exploit, 60 days for High, and 90 days for Medium.
How do I verify that Nessus credentialed authentication succeeded on scanned hosts?
Verify credentialed authentication success by checking for Plugin ID 21745 (Authentication Failure - Local Checks Not Run) and Plugin ID 12634 (Authenticated Scan Information) in the scan results. After a scan completes, filter the results by Plugin ID 21745 — any host appearing in these results had credential failure and all vulnerability counts for that host are unauthenticated-only, dramatically understating the actual vulnerability count. For hosts where Plugin ID 21745 fires, the Notes section shows the specific authentication failure reason: 'SMB not enabled', 'Credentials were not accepted', or 'Failed to get filesystem information via WMI', each indicating a different remediation action for the target host. Plugin ID 12634 (Authenticated Scan Information) should appear for every host where authentication succeeded — it is a benign informational plugin that runs only when credentials are valid. Calculate the credentialed scan coverage rate as (hosts with Plugin 12634) divided by (total hosts scanned) and track this metric over time. A credentialed coverage rate below 80% indicates systemic credential or firewall configuration issues that need to be resolved before the scan results can be trusted.
How do I use Nessus compliance templates to audit CIS Benchmark configuration?
Use Nessus compliance scan templates to audit server configurations against CIS Benchmark standards and generate audit evidence for compliance frameworks. In the Nessus scan policy, add a Compliance section and select the appropriate audit file for your operating system: CIS_Microsoft_Windows_Server_2022_Benchmark_v1.0.0.audit or CIS_Red_Hat_Enterprise_Linux_9_Benchmark_v1.0.0.audit are available in the Nessus audit library for licensed versions. The compliance scan runs both the vulnerability plugins and the compliance checks in a single scan pass, producing two result sets: the standard vulnerability findings and a separate compliance report showing each CIS Benchmark control as PASSED, FAILED, or WARNING. The compliance report includes the control ID, description, expected value, and actual value found on the host — audit evidence that demonstrates the specific configuration state at the time of the scan. Schedule compliance scans quarterly (or more frequently for PCI-scoped systems) and export the compliance reports as PDF or HTML for audit documentation. Failed compliance controls generate findings that supplement the CVSS-scored vulnerability findings and should be tracked in the same vulnerability management workflow with their own remediation SLAs.
How do I integrate Nessus scan results with a ticketing system for remediation tracking?
Integrate Nessus scan results with a ticketing system using the Tenable API or Nessus's built-in vulnerability management workflow to automatically create remediation tickets for new high-severity findings. Using the Tenable API (available in Tenable.io), call the /workbenches/vulnerabilities endpoint with filters for severity CRITICAL and HIGH and new_since timestamp to retrieve newly discovered vulnerabilities since the last scan. For each new vulnerability group (same plugin ID and affected host), create a ticket in your ticketing system (Jira, ServiceNow) via API with the vulnerability details, CVE ID, CVSS score, VPR score, affected host, and recommended remediation from the Nessus plugin output. Include the remediation SLA deadline in the ticket based on the severity: Critical tickets due in 15 days, High tickets due in 60 days. Set the ticket status to verified-closed only after the vulnerability is confirmed absent in a subsequent Nessus scan of the same host — this prevents false closes where a team marks the ticket done without actually patching the system. Track mean time to remediation (MTTR) per severity tier using ticket creation and close timestamps as a key vulnerability management program metric.
Sources & references
Free resources
Critical CVE Reference Card 2025–2026
25 actively exploited vulnerabilities with CVSS scores, exploit status, and patch availability. Print it, pin it, share it with your SOC team.
Ransomware Incident Response Playbook
Step-by-step 24-hour IR checklist covering detection, containment, eradication, and recovery. Built for SOC teams, IR leads, and CISOs.
Get threat intel before your inbox does.
50,000+ security professionals read Decryption Digest for early warnings on zero-days, ransomware, and nation-state campaigns. Free, daily, no spam.
Unsubscribe anytime. We never sell your data.
Founder & Cybersecurity Evangelist, Decryption Digest
Cybersecurity professional with expertise in threat intelligence, vulnerability research, and enterprise security. Covers zero-days, ransomware, and nation-state operations for 50,000+ security professionals every morning.
Win a $2,495 Black Hat pass.
Full-access to Black Hat USA 2026 in Las Vegas. Subscribe free to enter.