Authenticated vs Unauthenticated Scanning Guide

An unauthenticated vulnerability scan sees a host the way an attacker on the network sees it, so it misses most missing patches, vulnerable libraries and insecure local settings, while an authenticated scan sees far more but depends on a highly privileged account that touches every system. That trade-off is the whole subject of this guide. It explains what each scan type can and cannot find, how to set up credentialed scanning on Windows, Linux, network devices and databases, and how to run the scan account as a well-governed non-human identity rather than a domain-wide master key. It is for vulnerability management engineers, infrastructure teams and identity teams who own scanner credentials. Scanner selection and scheduling basics are in the Vulnerability Scanning Guide; this page goes deep on authentication.

Key takeaways

Use both, for different questions. Unauthenticated scans show your exposed attack surface; authenticated scans show what is actually installed and misconfigured. Neither replaces the other.
Credentials change what a scan can see. Tenable's documentation says a credentialed scan can do anything a local user with the same account could do, and that more privilege yields more thorough results.
The scan account is a high-value NHI. It usually holds local administrator or root on most of the estate, logs on to every host on a schedule, and is a prime target for relay and credential theft.
Prefer keys, vaults and tiers. Use SSH keys over passwords, retrieve credentials from a vault at scan time, and use separate scan accounts per tier so a single compromise does not reach domain controllers.
Measure authentication success. A credentialed scan that silently falls back to unauthenticated checks is the most common source of false assurance.

What each scan type sees

An unauthenticated (non-credentialed, network) scan probes open ports and services, reads banners, and tests remotely reachable flaws. An authenticated (credentialed, local check) scan logs on to the host and reads the installed package list, file versions, registry values and configuration directly.

Finding type	Unauthenticated scan	Authenticated scan
Open ports, exposed services, TLS configuration	Yes: its main strength	Yes
Remotely exploitable service flaws	Often, based on banners and probes; version guesses cause false positives	Yes, with exact installed version
Missing operating system patches	Limited to what services reveal	Yes: reads installed updates and package versions
Client-side software (browsers, office suites, PDF readers, runtimes)	Rarely: no listening port	Yes
Vulnerable libraries inside applications	No	Partly, where the scanner checks file versions on disk
Local configuration and hardening (CIS Benchmark style audits)	No	Yes, with compliance or audit policies
Weak or default credentials on services	Yes, if credential testing is enabled	Not the purpose
Attacker's view of the perimeter	Yes: run it from outside	No: it sees more than an attacker would initially

Rule of thumb: unauthenticated scans answer "what can someone reach?" and authenticated scans answer "what is actually vulnerable on the box?". The CIS Control 7 Continuous Vulnerability Management Guide covers the safeguard expectations: CIS Controls v8.1 Safeguard 7.5 calls for automated scans of internal assets on at least a quarterly basis using both authenticated and unauthenticated scans, and 7.6 for scans of externally exposed assets at least monthly. PCI DSS v4.0 requirement 11.3.1.2 requires internal vulnerability scans to be performed using authenticated scanning; see the PCI DSS 4.0 Guide.

Setting up credentialed scans by platform

Windows

Account rights: Tenable notes that the scan account needs enough privilege to read required files and registry keys, which usually means local administrator; without it, scans are limited to registry-based patch checks. Domain Administrator is only needed to scan domain controllers.
Services and ports: SMB over TCP 139 and 445 (File and Printer Sharing), inbound WMI rules (WMI-In, DCOM-In, ASync-In), the IPC$, ADMIN$ and C$ administrative shares, and the Remote Registry service, which is disabled by default. Some scanners can start Remote Registry for the scan and stop it afterwards.
Local accounts and UAC: remote UAC token filtering strips administrator rights from local accounts over the network. Tenable recommends the DWORD LocalAccountTokenFilterPolicy set to 1 under HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System rather than disabling UAC. Treat this as a security trade-off: it also helps attackers who hold a local admin hash (T1550.002 Pass the Hash). Prefer domain accounts with Kerberos for domain-joined hosts.
Restrict the exposure: Tenable suggests restricting the WMI firewall rules by source IP and user once scanning works, so only the scanner can use them.

Linux and Unix

Keys over passwords: Tenable recommends SSH keys instead of passwords where possible, a dedicated account with the same name on every target, a locked password (passwd -l), and keeping the private key only on the scanner.
Privilege: local checks on Linux need root-level visibility; grant it through tightly scoped sudo rules or su where your scanner supports escalation, and log every escalation.
Restrict the key: in authorized_keys, limit the scanner key with from="scanner-ip" so a stolen key cannot be used from elsewhere.

Network devices, databases and cloud

Network devices: use SNMPv3 with authentication and privacy, or read-only SSH accounts, never SNMPv1 or v2c community strings.
Databases: scanners support database credentials (Tenable lists MongoDB, Oracle, MySQL, DB2, PostgreSQL and SQL Server); use a read-only audit role, not a database administrator account.
Cloud and containers: agentless cloud scanning and posture tools use API roles; give them read-only roles and federated, short-lived credentials. See the Prowler and Cloud Posture Scanning Guide.

When authentication fails

Access denied with valid credentials: on Windows, usually remote UAC filtering of a local account, a missing administrative share, or the domain-joined host using the "Guest only" sharing model; Tenable notes the setting must be "Classic - local users authenticate as themselves".
Partial results: the account authenticated but lacked privilege, so only registry-based checks ran. Check the scanner's per-host privilege report, not just the logon result.
Lockouts: scanners open several concurrent authenticated connections, and Tenable warns against strict lockout policies tied to concurrent sessions; a stale password in the scanner can also lock the account across the estate.
SSH timeouts: unsupported key exchange or cipher algorithms on hardened hosts, or interactive prompts in login scripts.

The scan account as a non-human identity

A credentialed scanner is an automated identity that authenticates to almost every system on a schedule with administrative rights. That makes it one of the most powerful non-human identities in the estate. The main risks:

Risk	How it happens	Control	ATT&CK
Credential capture by relay or poisoning	Scanner authenticates over NTLM to a host or name the attacker controls; credentials are relayed or cracked	Require SMB signing, prefer Kerberos, scan by hostname, disable LLMNR and NBT-NS	T1557.001 Name Resolution Poisoning and SMB Relay
Credential theft from a scanned host	Interactive or cached logons leave reusable credentials on a compromised host	Network logons only, Credential Guard, add the account to Protected Users where compatible	T1550.002 Pass the Hash
Over-privileged single account	One domain admin scan account used for every tier	Separate accounts per tier; domain admin only for domain controller scans from a tier 0 scanner	T1078.002 Domain Accounts
Theft from the scanner itself	Credentials stored in the scanner database or config; scanner host compromised	Vault integration, hardened scanner host, restricted console access	T1078.002 Domain Accounts
Lockout and spray noise	Many concurrent logons; failed credentials look like spraying	Tune lockout exemptions narrowly, alert on use outside scan windows	T1110.003 Password Spraying (as a look-alike)

Relay is the most important of these for Windows. Microsoft's SMB signing documentation states that signing confirms the sender's and receiver's identities and prevents relay attacks, and recommends Kerberos over NTLMv2 and connecting by computer name rather than IP address, because IP addresses and CNAME aliases cause NTLM to be used. Many scanners default to scanning by IP. Configure targets by hostname where the scanner allows it, and work through the NTLM Relay Guide and the NTLM Deprecation and Elimination Guide.

Credential Guard, enabled by default from Windows 11 22H2 and Windows Server 2025 on eligible domain-joined systems that are not domain controllers, isolates NTLM hashes and Kerberos tickets, which reduces what an attacker on a scanned host can harvest. The scanner's network logons should not leave reusable credentials on the target in any case; never let a scan account log on interactively.

Governance for scan accounts

Owner and purpose: each scan account has a named owner, a documented scope (which tier, which hosts) and an entry in the service account inventory. See the Service Account Inventory Template.
Logon restrictions: deny interactive and remote desktop logon; restrict logon to the scanner's source addresses where the platform allows; deny use on tier 0 for non-tier-0 accounts through GPO user rights.
Vaulted credentials: retrieve the password or key from a privileged access or secrets vault at scan time and rotate it on a schedule, so the scanner database does not hold a long-lived secret. See the Service Account Security Guide.
Monitoring: baseline when and where the account logs on. Any logon outside scan windows or from a non-scanner address is a high-priority alert.

Choosing the approach

Approach	Best for	Trade-offs
Unauthenticated network scan	External attack surface, unmanaged and unknown devices, segments where you cannot hold credentials	Misses most local vulnerabilities; banner-based false positives
Authenticated network scan	Servers and fixed infrastructure, network devices, databases	Needs privileged credentials on the wire; firewall and service dependencies
Agent-based assessment	Laptops and remote devices that are rarely on the corporate network; hosts where you do not want inbound admin access	Agent deployment and maintenance; less useful for network-exposure view
Agentless cloud API scanning	Cloud workloads, images and posture	Depends on cloud read roles; coverage varies by provider

Small organisations often get the best coverage-to-risk ratio from agents on endpoints plus an unauthenticated external scan, avoiding a fleet-wide admin credential altogether. Large organisations typically combine agents for endpoints, tiered credentialed scanning for servers and infrastructure, and unauthenticated scans from inside and outside to validate exposure. In all cases, keep domain controllers and other tier 0 systems on a separate scanner and account.

Implementation: rolling out credentialed scanning

Inventory and tier the estate: group assets by tier and platform so each scan account has a defined scope.
Create dedicated accounts per tier: no shared human accounts, no reuse of existing service accounts. Apply logon restrictions before first use.
Harden the path first: require SMB signing, prefer Kerberos, configure targets by hostname, and restrict WMI and SSH to the scanner sources.
Pilot on a small ring: scan [20] representative hosts per platform and check the authentication result for every host, not just the vulnerability count.
Compare results: run authenticated and unauthenticated scans of the pilot ring and review the difference. It shows the value and catches hosts where authentication silently failed.
Integrate the vault: move credentials into the vault and turn on rotation before scaling.
Scale by ring: expand to each tier in turn, watching for lockouts, service impact and helpdesk tickets.
Roll back cleanly: if a scan causes service impact, disable the scan policy for that group, not the account, and record the cause. If the account is suspected of compromise, disable it, rotate it, and review its logon history.

Detection and measurement

Log scan account activity in the SIEM: Windows Security events 4624 (logon, with logon type and authentication package), 4625 (failed logon) and 4672 (special privileges assigned), SSH authentication logs on Linux, and the scanner's own audit trail of who changed credentials or policies. Track these metrics:

Authentication success rate: percentage of in-scope hosts where the credentialed scan authenticated with full privileges. Aim for above [95] percent and investigate every drop.
Credentialed coverage: percentage of assets covered by an authenticated scan or an agent in the last [30] days.
NTLM share of scan logons: percentage of scan account logons using NTLM rather than Kerberos; drive it down.
Out-of-window use: scan account logons outside scheduled windows or from non-scanner addresses. Target zero.
Credential age: days since each scan credential was rotated, against your rotation standard.

Framework mapping

Framework	Reference	Relevance
NIST SP 800-53 Rev. 5	RA-5 Vulnerability Monitoring and Scanning; RA-5(5) Privileged Access	RA-5(5) is the enhancement for privileged access for selected scanning activities
NIST SP 800-53 Rev. 5	AC-6 Least Privilege; AC-6(9) Log Use of Privileged Functions; IA-5 Authenticator Management	Scan account scope, logging and credential rotation
NIST CSF 2.0	ID.RA-01; PR.AA-01	Vulnerabilities identified and recorded; identities and credentials for services managed
CIS Controls v8.1	Safeguards 7.5, 7.6; Control 5 Account Management	Authenticated and unauthenticated scanning cadence; service account governance
PCI DSS v4.0	Requirement 11.3.1.2	Authenticated internal vulnerability scans
MITRE ATT&CK v20	T1557.001, T1550.002, T1078.002, T1110.003	Techniques that target or resemble scan account use

Common failure patterns

Silent fallback: credentials fail on part of the estate and the scan reports fewer findings, which looks like improvement. Always report authentication status per host.
One domain admin for everything: a single scan account with domain admin rights authenticating to every workstation turns any relay or compromised host into a domain compromise.
Scanning by IP over NTLM: the default target list uses IP addresses, so every logon is NTLM and relayable where signing is not required.
Weakening hosts for the scanner: disabling UAC or leaving Remote Registry and admin shares open everywhere without restricting who can use them.
Treating the scanner as trusted infrastructure: the scanner holds the keys to the estate and its software is itself supply chain. In the Trivy Supply Chain Attack 2026, pipelines that ran poisoned releases of a security scanner had their CI secrets harvested. Pin versions, verify releases and limit what credentials the scanner's runtime can see.
Never rotating the scan password: scan credentials set up years ago, known to former staff and stored in scanner exports.

Practitioner checklist

Run unauthenticated scans for exposure and authenticated scans or agents for depth; document which assets get which.
Create separate scan accounts per tier; reserve domain admin for a tier 0 scanner scanning domain controllers only.
Use SSH keys with a locked password and from= restrictions on Linux; SNMPv3 on network devices; read-only roles on databases.
Require SMB signing, prefer Kerberos, and configure Windows targets by hostname.
Deny interactive and remote desktop logon for scan accounts and restrict logon to scanner sources.
Store scan credentials in a vault, retrieve them at scan time and rotate them on schedule.
Report authentication success per host on every scan and investigate drops.
Alert on scan account use outside scan windows or from non-scanner addresses.
Harden and patch the scanner host and restrict access to its console and credential store.

Authenticated vs Unauthenticated Scanning Guide: See more without handing attackers the keys