Credentialed Vulnerability Scanning: How to Configure Authenticated Scans in Nessus and Qualys
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.
The difference between what an unauthenticated vulnerability scan finds and what a credentialed scan finds is not a matter of degree — it is the difference between seeing the exterior of a building and being able to inspect every room. An unauthenticated scanner enumerates services and checks externally visible behavior. A credentialed scanner reads the patch level of every installed package, checks every configuration file against benchmarks, and enumerates every locally installed application with a known CVE history.
Most vulnerability management programs start with unauthenticated scanning and stay there because configuring credentials at scale is operationally complex. The result is a vulnerability program that sees only the attack surface visible from the network, missing the majority of the actual risk. This guide provides the configuration details that move a scan program from unauthenticated to fully credentialed.
Windows credentialed scanning: the configuration checklist
Windows authentication for vulnerability scanning requires three things to work together: the scan account has sufficient permissions, the required services are running on the target, and the firewall allows the scanner's connection. The two most common failure points are a disabled Remote Registry service and Windows Firewall blocking TCP 445 and TCP 135 from the scanner appliance. Configuring both via Group Policy Object ensures consistent coverage across all domain-joined systems. The scan account itself must be a domain service account with WMI access rights, not a Domain Admin — scoped, minimal permissions reduce the risk if the account is ever compromised. Testing connectivity from the scanner before the first scheduled scan prevents running a large scan and discovering authentication failed silently on every target.
Configure the Remote Registry service and firewall rules via GPO
The most common cause of Windows credentialed scan failures is the Remote Registry service being disabled or the WMI ports being blocked by Windows Firewall. Configure both via GPO: (1) Remote Registry service: Computer Configuration > Windows Settings > Security Settings > System Services > Remote Registry: set to Automatic. (2) Windows Firewall: Computer Configuration > Windows Settings > Security Settings > Windows Firewall with Advanced Security > Inbound Rules: create rules allowing TCP 445 (SMB) and TCP 135 (RPC Endpoint Mapper) from the scanner IP address. Apply this GPO to all OUs containing hosts that will be scanned. For agentless scanning, these two configurations are prerequisites — without them, authentication will fail silently.
Create and test the scan account before the first credentialed scan
Create the scan account in AD, apply the GPO that grants required permissions, and test connectivity from the scanner appliance before the scheduled scan. Test with: net use \\TARGET\IPC$ /user:DOMAIN\scan-account PASSWORD — if this succeeds, SMB connectivity and authentication are working. Test WMI: wmic /node:TARGET /user:DOMAIN\scan-account process list brief — if this returns a process list, WMI authentication is working. Both tests should be run from the scanner appliance or a host on the same network segment as the scanner before relying on scan results. Failed tests before the scan prevents the wasted effort of running a large scan only to discover after the fact that authentication failed on every target.
Agent-based scanning: covering endpoints that leave the network
Laptops and endpoints that travel outside the office network are typically the poorest-covered asset class in vulnerability programs — agentless scans miss them when they are off-network, and VPN-based scanning creates performance problems. Agent-based scanning solves the off-network coverage gap by running the vulnerability check locally on each endpoint, then sending results to the central platform over HTTPS regardless of the network the device is connected to. Tenable.io and Qualys VMDR both support agents deployed via Intune for Windows endpoints and Jamf for macOS, meaning agent deployment follows the same MDM workflow as any other endpoint tool. Both platforms provide an agent coverage dashboard that cross-references enrolled agents against the managed device inventory, making gaps visible before they affect scan completeness.
Deploy agents via MDM/configuration management before scheduling scans
Agent deployment requires a package manager or MDM system to be effective at scale. For Tenable.io on Windows endpoints managed by Intune: create an Intune app deployment for the NessusAgent MSI with the linking key as an install parameter. All Intune-managed Windows devices receive the agent automatically, including newly enrolled devices. For macOS endpoints managed by Jamf: create a policy in Jamf that installs the Nessus Agent package and runs the linking command. Coverage tracking: both Tenable.io and Qualys provide an 'agent coverage' dashboard showing which managed assets have agents reporting versus which have no agent. Cross-reference this against your MDM device inventory to identify coverage gaps.
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
Credentialed vulnerability scanning is the configuration step that transforms a vulnerability scanner from a network reconnaissance tool into a genuine vulnerability inventory system. The operational investment — scan account creation, GPO configuration, firewall rules, and agent deployment — pays back immediately in the first credentialed scan, which typically reveals three to five times more findings than the unauthenticated baseline. Track authentication success rate per scan cycle as the key metric: 95%+ authentication success means your findings are accurate; lower rates mean your vulnerability count is understated. Agent-based scanning for endpoints and agentless credentialed scanning for servers provides full coverage across asset types with different connectivity patterns.
Frequently asked questions
What permissions does the Windows scan account need for credentialed vulnerability scanning?
Minimum Windows scan account permissions for Nessus and Qualys: the account does not need to be a local Administrator — minimum required permissions are: (1) Member of the local Administrators group OR explicitly granted rights to: access the computer from the network (SeNetworkLogonRight), log on as a batch job (SeBatchLogonRight), allow WMI access through the WMI namespace (WMI namespace security: root/cimv2 with Execute Methods, Enable Account, Remote Enable, Read Security). (2) Remote Registry service enabled and running on all target hosts (required for registry reads by the scanner). (3) Windows Firewall must allow inbound traffic from the scanner IP on ports 445 (SMB) and 135 (WMI/DCOM). (4) UAC Remote Restrictions must be disabled for non-domain accounts: add HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System — LocalAccountTokenFilterPolicy = DWORD 1. For domain environments: create a domain service account in a dedicated OU, apply GPO granting the required logon rights, and use this account for all Windows credentialed scans. Do not use Domain Admin — it is unnecessary and represents excessive privilege for a scan account.
How do I configure SSH key authentication for Linux credentialed scanning in Nessus?
Linux credentialed scan setup with SSH keys: (1) Create a dedicated scan user on all Linux targets: useradd -m -s /bin/bash nessus-scan (or qualys-scan). This account should have no interactive login capability: usermod -s /usr/sbin/nologin nessus-scan is incorrect as it will prevent SSH login — instead, the account needs SSH access but should be configured with ForceCommand in /etc/ssh/sshd_config if further restriction is needed. (2) Generate an SSH key pair on the scanner or a management system: ssh-keygen -t ed25519 -f scan-key -C 'vulnerability-scan'. (3) Deploy the public key to all Linux targets: ssh-copy-id -i scan-key.pub nessus-scan@TARGET-IP (for initial setup where password auth is still available). (4) Configure sudo without password for the commands the scanner needs: add to /etc/sudoers: nessus-scan ALL=(ALL) NOPASSWD: /usr/bin/find, /bin/cat, /usr/bin/rpm, /usr/bin/dpkg. The specific sudo commands vary by scanner vendor — check your scanner vendor's documentation for the required sudo command list. (5) In Nessus: Credentials > SSH > add the private key, username, and sudo escalation method. (6) Verify: run a test scan and check the plugin output for 'SSH login was successful.'
What is the difference between agent-based and agentless vulnerability scanning?
Agentless scanning: the scanner connects to each target over the network using credentials (SSH, WMI) and runs checks remotely. Advantages: no software to install on targets, scanner can be deployed rapidly, works for any host reachable from the scanner network. Disadvantages: credentials must be managed and rotated, scanner must have network access to all targets (fails for hosts behind NAT or on isolated segments), authentication failures are silent (scan appears complete but is unauthenticated), and high network traffic from scanning. Agent-based scanning: a lightweight agent is installed on each host and sends scan results to the scanner platform without the scanner needing network access to the host. Advantages: works for laptops that leave the office network, no credential management, faster scan cycle (agent runs locally), authentication failure is impossible since the agent runs with local privileges. Disadvantages: requires agent installation and maintenance on every host, agent updates need to be managed, cloud/container workloads may not support persistent agents. Recommendation: use agent-based scanning for endpoints (laptops, workstations) that travel outside the office network. Use agentless credentialed scanning for servers with stable network connectivity where agent installation is operationally complex. Most enterprise VM programs use both: Tenable.io and Qualys VMDR support both modes from the same platform.
How do I verify that a credentialed scan actually authenticated successfully?
Authentication success validation: most vulnerability scanners include a dedicated plugin that reports authentication status. In Nessus/Tenable: search the scan results for Plugin ID 21745 (Authentication Failure - Local Checks Not Run) or Plugin ID 110385 (Authentication Success - Local Checks Enabled). If Plugin 21745 fires for a host, the authentication failed and all results for that host are unauthenticated. In Qualys: check the scan results for 'Authentication Status' in the host details — it shows 'Authentication Successful' or the specific failure reason (port blocked, account locked, WMI service not running). Validation process after every scan: (1) Export the authentication status for all scanned hosts. (2) Calculate the percentage of hosts with successful authentication (target: 95%+ for a mature scan program). (3) Investigate hosts with failed authentication: was the port blocked? Was the Remote Registry service stopped? Was the account locked after too many failed attempts from the scanner? (4) Track authentication success rate as a metric for the scan program's effectiveness.
Should I use a local account or a domain account for Windows credentialed scanning?
Domain account versus local account for Windows scanning: Domain account (recommended for domain-joined hosts): create a service account in Active Directory in a dedicated OU, apply GPO to grant the required WMI and logon permissions across all domain-joined workstations and servers, configure the scanner with this single account. The domain account works across all domain-joined hosts without configuring individual local accounts. Rotate the password on a schedule and update the scanner credential store. Local account (required for non-domain hosts): create the scan account locally on each host with the same username and password, or use the Nessus/Qualys SMB hash authentication to avoid password distribution. For workgroup environments or DMZ hosts not joined to the domain: local account is the only option. Security considerations: the scan account (domain or local) should be a member of the local Administrators group (required for WMI deep access) but should be restricted from interactive logon (set 'Deny log on locally' via GPO). Use a unique password for the scan account — do not share the password with any other service account. Enable auditing on the scan account to detect if it is used outside scan windows.
How do I deploy Nessus or Qualys agents across a fleet of Linux and Windows hosts?
Agent deployment at scale: Nessus Agent (Tenable.io): download the agent package from Tenable. For Linux: distribute via package manager (RPM for RHEL/CentOS, DEB for Ubuntu/Debian) using Ansible, Chef, Puppet, or your MDM system. Linking key: generate a linking key in Tenable.io console, include in the install command: /opt/nessus_agent/sbin/nessusagent link --key=LINKING_KEY --host=cloud.tenable.com --port=443. For Windows: distribute MSI via SCCM/Intune with the linking key in the MSI property: msiexec /i NessusAgent-x64.msi NESSUS_SERVER=cloud.tenable.com NESSUS_KEY=LINKING_KEY /qn. Qualys Cloud Agent: similar architecture — download the agent from Qualys, distribute via your configuration management or MDM tool, activate with your Qualys activation key. Both platforms provide dashboards showing agent-connected hosts versus unconnected hosts, making coverage gaps visible. For initial deployment: target 100% coverage on servers first (highest value for vulnerability detection), then extend to endpoints. Track deployment progress as a metric: agents deployed / total managed hosts.
What is the minimum scan frequency and scan window for credentialed vulnerability scanning?
Scan frequency requirements by compliance framework: PCI DSS: internal vulnerability scans quarterly (minimum), recommended monthly. External: quarterly with ASV-qualified scanner. NIST SP 800-53 (federal): continuous or periodic scanning, frequency defined by risk level (high-impact systems: monthly, moderate: quarterly). SOC 2: no specific frequency in the criteria, but 'regular' scanning is expected — quarterly is commonly audited as the minimum. ISO 27001: 'regular' technical vulnerability management; quarterly is the common interpretation. Operational recommendation: scan servers monthly, endpoints (laptops) weekly via agent-based scanning. Scan windows: schedule agentless scans during low-traffic periods (weekends, overnight) to minimize performance impact on targets. Stagger scans so all servers are not scanned simultaneously — scanning 500 servers at once creates significant WMI/SSH session load on Active Directory and the scanner appliance. Qualys and Tenable both support scan scheduling with rate limiting to control scan parallelism.
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.