Why Credentialed Vulnerability Scans Report Success Even When the Scan Account Has Lost Access
Credentialed vulnerability scanning gives the scanner a privileged login so it can verify installed software, patch state, and configuration. PCI DSS 11.3.1.2 has required these authenticated internal scans since March 2025. Results are only as good as the scan account: if it is degraded or revoked, the scanner silently falls back to surface-level checks while the report still says success.
Your quarterly credentialed vulnerability scan finished at 4 a.m. The platform marked it complete, the report lists the expected number of hosts, and the finding count is roughly in line with last quarter. Then the assessor asks the question that takes more effort than it should: show me which of these hosts the scanner actually authenticated to. The report does not say. It says success.
The stakes have not been sitting still. The 2026 Verizon Data Breach Investigations Report found that exploitation of vulnerabilities overtook credential theft as the most common way attackers get in, appearing in 31% of all breaches, a 55% increase from the year before [4]. Every one of those initial footholds starts somewhere on the internal estate your scan claims to cover.
In our vulnerability scanning work at Clone Systems, the most common authentication failure we find is not a scanner problem at all. It is a scan account that was removed from a group, had its password rotated, or was decommissioned, so the host is scanned unauthenticated while the report still says success [7]. Credentialed vulnerability scanning is only as good as the login it is running on, and since March 2025 PCI DSS has made that login mandatory [1]. This post covers what PCI DSS 11.3.1.2 actually requires, the three ways the scan account silently degrades, and the five-point check that proves your scan covered what it claims to cover.
What Does PCI DSS 11.3.1.2 Actually Require for Internal Scans?
PCI DSS v4.0.1 Requirement 11.3.1.2 requires internal vulnerability scans to be run with authenticated credentials, and it has applied to all entities since March 31, 2025 [1]. The requirement sits under 11.3.1, which already required internal scans at least once every three months, resolution of high-risk and critical vulnerabilities, and rescans after significant changes [1]. What 11.3.1.2 adds is the credential requirement: the scan must log in, not just reach.
That wording has practical consequences. "Authenticated" in this context means the scanner has a working privileged login to each in-scope host, not that the scan profile was once configured with credentials. The standard expects that login to be maintained for the life of the requirement, which most teams read as a one-time setup step rather than a standing check.
What Privileges Does the Scan Account Need?
To meet the intent of the requirement, the account needs sufficient privileges to access system-level data. In practice, that is local administrator on Windows and root or passwordless sudo on Linux, enough to read registry settings, patch state, installed packages, and service configurations [2]. If the account allows interactive login, PCI DSS expects it to be managed under Requirement 8.2.2 [2].
A Dedicated Scan Account, Not a Reused Admin Login
Guidance on the requirement is explicit that a dedicated scan account with the required privileges is the right design, rather than reusing an existing administrative credential [2]. Over-privileging is a separate failure: a domain administrator or enterprise-wide credential used for scanning increases the risk if that credential is compromised and raises concerns during a PCI assessment [2].
What If Some Systems Cannot Accept Credentials?
PCI DSS does not permit skipping those systems. The expected treatment is to document the assets that cannot accept credentials and the reason (legacy systems, OT/ICS devices, vendor restrictions), provide a risk-based justification with compensating controls such as network segmentation, endpoint monitoring, or file integrity monitoring, and consider a host-based agent where its detection capability is equivalent [2]. Engage your QSA to validate the approach [2]. If agents are the answer for part of your estate, our agent-based scanning page covers how they fit into an internal program.
Why Does a Credentialed Scan Report Success While the Scan Account Has Lost Access?
Because the platform measures the scan, not the login. The scanner runs the profile, collects what it can reach, and marks the run complete. Authentication is one step inside that run, and the summary view rarely breaks it out per host. Three failure modes produce the same green status.
Failure Mode 1: The Silent Fallback
When the stored password no longer works, or the account has been removed from the local administrators group, many scanner profiles fall back to unauthenticated checks against that host and continue. The host still appears on the report. It still gets port, banner, and web findings. What it no longer gets is the local checks that read installed packages and verify patch state [3]. At the platform level, nothing looks wrong.
Failure Mode 2: Authenticated, but Not Enough
A subtler case: the account can still log in, but no longer has the privileges it had when the profile was configured. Scanner documentation describes this explicitly. A plugin can report commands that failed due to insufficient access, and the result is that authentication reports as successful with insufficient access [3]. Authentication success and local checks are different states: a host can authenticate and still not produce a single local check [3]. The condition is flagged, but in a summary plugin that most review processes never open.
Failure Mode 3: The Forgotten Hosts
In our vulnerability scanning engagements, the hosts where authentication fails are not the ones the team manages actively. They are the backup appliance, the monitoring server, the load balancer, and the management interface, the systems that were added, renamed, or handed off and never revisited [7]. Clients are consistently surprised to learn that "4,000 hosts scanned" and "4,000 hosts authenticated" are different numbers, and the difference is usually that same forgotten set [7]. Those are also the hosts an attacker values most, because they hold the credentials and the lateral movement paths.
The September 2026 Patch Tuesday illustrates why that matters. The one vulnerability Microsoft confirmed was already being exploited, CVE-2026-81963, an elevation of privilege in the Windows Update Stack, carried no CVSS score at all [6]. A queue sorted by severity would have ranked it well down the list. An unauthenticated scan cannot even confirm whether the fix is present, because it infers patch state from banners. A credentialed scan reads the installed package directly. The hosts your scan account cannot reach are exactly the hosts where an unpatched, unscored vulnerability goes unnoticed.
If you need to show an assessor that your internal scanning is authenticated, the fastest path is a scan that reports per-host authentication status by design. Clone Systems runs credentialed internal scanning as part of our network vulnerability assessment service, with dedicated scan accounts and per-host authentication reporting included.
What Does an Unauthenticated Scan Miss That a Credentialed Scan Finds?
The two scan types answer different questions, and a defensible program runs both. An unauthenticated scan shows what an attacker sees from outside: open ports, exposed services, weak banners, and version strings [3]. A credentialed scan shows what is actually installed and configured on the host. The differences that matter in practice:
| Unauthenticated scan | Credentialed scan | |
|---|---|---|
| Perspective | External attacker, no login | Privileged local account |
| Installed software and version | Inferred from banners and headers [3] | Read directly from the system [3] |
| Patch and hotfix state | Inferred, and often wrong where a vendor back-ported a fix [8] | Verified against the installed package [3] |
| Registry, service, and permission configuration | Not visible [2] | Visible [2] |
| False positive rate | Higher, from version fingerprinting [2] | Lower, because the actual state is confirmed [2] |
| Best used for | Attacker-perspective exposure | Internal risk and compliance evidence |
The false positive problem is the one most teams feel first. Where a vendor back-ports a security fix without changing the version string, an unauthenticated scan sees the old version and reports the vulnerability, while the credentialed scan sees the package that is actually installed and does not [3][8]. We covered that evidence problem in Why Your Vulnerability Scanner Flags Patched Systems.
The second consequence is prioritization. Only 26% of CISA KEV vulnerabilities were fully remediated in the period the 2026 data covers [5]. A KEV-driven queue only works if the queue is accurate, and the queue is only as accurate as the patch-state data behind it, which is exactly what the login provides.
How Do You Prove Your Credentialed Vulnerability Scanning Actually Covered the Estate?
The proof is not the summary page. It is the per-host authentication status, and the discipline to check it every run.
The Clone Systems 5-Point Scan Credential Health Check
- Verify the account's rights on a sample before the scan. Pick five representative hosts, one per major operating system and role, and confirm the scan account is still a local administrator, or has sudo, on each. A one-minute check now is cheaper than a failed compliance question later.
- Review the per-host authentication report, not just the run summary. Open the authentication failures for each protocol in use, SMB or WinRM on Windows, SSH on Linux. Every unexplained failure is a host that scanned unauthenticated [3].
- Compare the counts. Hosts in scope versus hosts that authenticated. The difference is your gap, and you should be able to name every host in it.
- Check the local check indicator. The scanner's own status tells you whether credentialed checks actually ran. On major platforms, the equivalent of a "Credentialed Checks: yes" flag is what separates a real credentialed result from a login that produced no local data [3].
- Document the exceptions. Any host that cannot accept credentials gets a written exception: the reason, the compensating controls, and a review date. That is what 11.3.1.2 expects when credentials are not feasible [2].
Test Your Own Environment
Take 15 minutes. Open the report from your last internal scan and find the per-host authentication status. Pick the three hosts that are not a clean success and log in to each one as the scan account. See what it can read, and what it cannot. If you cannot tell from the report you already have which hosts authenticated, you have your finding, and it is the finding the assessor would have found.
Keep the evidence with the report: the authenticated scan results, the per-host authentication status, the documented exceptions, and the cadence record showing scans at least quarterly and after significant changes, per 11.3.1 [1]. We covered how to set that cadence in How Often Should You Run Vulnerability Scans.
How Clone Systems Can Help
Clone Systems runs credentialed internal scanning as part of our vulnerability management work, and our position is simple: an internal scan is evidence only of the hosts it actually authenticated to, and the scan program should prove that on every run. Our network vulnerability assessment service uses dedicated scan accounts, reports authentication status per host, and documents the exceptions your assessor will ask about, so the answer to "show me the authenticated coverage" is a report, not a conversation. Where credentials are not possible, our agent-based scanning covers the gap with local checks on the host itself.
If you are preparing for a PCI assessment and your internal scanning evidence lives in a summary page, talk to our team. We will review your scan configuration, run the credential health check against your estate, and put together the evidence file before the assessor asks for it.
Frequently Asked Questions
What is the difference between credentialed and non-credentialed scanning? A credentialed scan logs in with a privileged account and reads installed software, patch state, and configuration directly, while a non-credentialed scan infers all of it from banners, versions, and exposed services. Only the credentialed result satisfies the authenticated internal scanning that PCI DSS 11.3.1.2 has required since March 2025.
What does PCI DSS 11.3.1.2 require? It requires internal vulnerability scans to be run with authenticated credentials with sufficient privileges to access system-level data, and it has applied to all entities since March 31, 2025. Systems that cannot accept credentials need a documented exception with compensating controls, not a skipped scan.
What permissions should a vulnerability scan account have? Local administrator on Windows and root or sudo on Linux, enough to read registry settings, patch state, and installed packages. Use a dedicated scanning account rather than a reused admin login to limit the blast radius if the credential is compromised.
How do I know if my internal vulnerability scan was actually authenticated? Open the scanner's per-host authentication report, compare the hosts that authenticated to the hosts in scope, and check the local check indicator for each. A host that shows authentication success without the local check indicator is authenticated with insufficient privileges.
What happens if I can't use credentials on some systems? PCI DSS does not permit skipping those systems. Document the reason, add compensating controls such as segmentation, endpoint monitoring, or a host-based agent, and have your QSA validate that the approach meets the intent of 11.3.1.2.
How often should internal vulnerability scans run? At least once every three months, and after any significant change, per PCI DSS 11.3.1, with high-risk and critical vulnerabilities resolved between scans. Our scan frequency guide covers what counts as a significant change for most environments.
Conclusion
Requirement 11.3.1.2 was easy to read and harder to verify. It asks for an authenticated internal scan, but it does not ask for a scan that merely claims to be one. The difference shows up in the per-host authentication status, and the hosts where the login has failed are exactly the hosts an attacker would pick, the forgotten systems that hold credentials and movement paths. Verify the account before the scan, read the authentication report after, and document what you could not reach. If you want a credentialed internal scanning program that can produce that evidence the moment an assessor asks for it, start at www.clone-systems.com.
References
[1] PCI Security Standards Council: PCI DSS v4.0.1, Requirement 11.3.1 (internal vulnerability scans at least every three months, high-risk and critical vulnerabilities resolved, rescans after significant change) and Requirement 11.3.1.2 (authenticated internal vulnerability scans, mandatory for all entities from March 31, 2025). https://www.pcisecuritystandards.org/document_library/ [2] Tevora: Demystifying PCI DSS Requirement 11.3.1.2, November 2025 (privileged scan accounts: local administrator on Windows, root or passwordless sudo on Linux; dedicated account rather than a reused admin credential; documented exceptions and compensating controls where credentials are not feasible). https://www.tevora.com/resource/demystifying-pci-dss-requirement-11-3-1-2-why-authenticated-internal-vulnerability-scans-matter/ [3] Tenable: Vulnerability Assessment/Scanning (authenticated versus unauthenticated scanning; local checks require elevated access; authentication can report as successful with insufficient access; "Credentialed Checks: yes" as the indicator of a successful credentialed scan). https://docs.tenable.com/cyber-exposure-studies/vulnerability-management/Content/vuln-assessment-scanning.htm [4] Verizon: 2026 Data Breach Investigations Report (exploitation of vulnerabilities the most common initial access vector, 31% of breaches, up 55% year over year, overtaking credential theft). https://www.verizon.com/business/resources/reports/dbir/ [5] Veracode: 2026 Verizon DBIR Highlights (2026 State of Software Security: only 26% of CISA KEV vulnerabilities fully remediated). https://www.veracode.com/resources/webinars/2026-verizon-data-breach-investigations-report [6] Absolute: September 2026 Patch Tuesday (CVE-2026-81963, Windows Update Stack elevation of privilege, confirmed exploited in the wild, no published CVSS score). https://www.absolute.com/blog/microsoft-patch-tuesday-september-2026-exploited-cve-no-cvss-score [7] Clone Systems: In our vulnerability scanning engagements, the scan account is usually the degraded component, not the scanner: a group membership removed, a password rotated, or a service account decommissioned, so hosts scan unauthenticated while the platform marks the run complete, and the hosts that fail are disproportionately backup appliances, monitoring servers, load balancers, and management interfaces. [8] Clone Systems: Why Your Vulnerability Scanner Flags Patched Systems (And What Actually Closes the Finding). www.clone-systems.com/blog/why-your-vulnerability-scanner-flags-patched-systems [9] Clone Systems: How Often Should You Run Vulnerability Scans? www.clone-systems.com/blog/how-often-should-you-run-vulnerability-scans [10] Clone Systems: Network Vulnerability Assessment Services. www.clone-systems.com/network-vulnerability-assessment-services/ [11] Clone Systems: Agent-Based Scanning. www.clone-systems.com/agent-based-scanning/