Authenticated Scans: The Key to a PCI DSS Certification Without Surprises

What is PCI DSS?

PCI DSS 4.0.1

Now that we have a clear understanding of this standard, let's look at how it affects authenticated scans. One thing to highlight is that this set of guidelines has different versions, which are updated over time to keep pace with evolving security standards.

Earlier versions already included requirement 11.3.1, which mandates performing an internal vulnerability scan at least every three months. This analysis must cover all in-scope systems and requires resolving vulnerabilities classified as critical or high risk, followed by verification scans until these vulnerabilities are confirmed as remediated. The standard also requires that the scan be performed by qualified personnel independent from the systems being evaluated.

The sub‑requirement 11.3.1.2 introduces the authenticated scan modality. Its main requirements include:
▪️Systems that cannot accept credentials for authenticated scanning must be documented.
▪️Sufficient privileges must be used for systems that do accept credentials.

After any significant change, requirement 11.3.1.3 mandates repeating the internal scan to demonstrate that the change did not introduce new risks.

Requirement 11.3.2 maintains the obligation of quarterly external scans performed by an Approved Scanning Vendor (ASV) to monitor the organization’s public-facing surface.

What is a vulnerability scan?

Up to this point, the concept of scanning has been mentioned several times, but what exactly are we referring to?

A vulnerability scan is an automated process in which a specialized tool, such as Nessus or Qualys, analyzes systems, devices, and applications to identify security weaknesses. The tool collects information (open ports, active services, configurations, software versions) and compares it with a database of known vulnerabilities.

This process detects outdated patches, misconfigurations, or obsolete software that could be exploited by an attacker.

With this information, the auditing team will produce a report outlining the vulnerabilities detected, as well as their corresponding solutions.

Difference Between an Authenticated and an Unauthenticated Scan

An unauthenticated scan analyzes the network from the perspective of an external intruder: it enumerates ports, extracts service banners, and detects basic exposure issues. It is faster and requires less preparation but is not exhaustive.

An authenticated scan, however, “opens the hood” of the system: it inspects files, compares versions and patches, analyzes security configurations, verifies encryption algorithms and permissions. It is more thorough and reliable but requires a user account with sufficient privileges on each host. 

What is an Internal Authenticated Scan?

An authenticated scan is a vulnerability analysis executed from within the corporate network (physically or via VPN) using valid credentials on the systems being analyzed. These credentials allow the scanner to directly query the operating system, registry, running services, and installed libraries.

The PCI DSS standard emphasizes that this approach provides a much deeper and more realistic view of the security posture of the assets, as it reveals vulnerabilities that could be exploited by an attacker with initial access to the network.

Requirements for an authenticated scan:  
That said, an authenticated scan has a series of requirements that are not necessary in a ‘normal’ scan. When performing authentication, not only are valid credentials required, but also an account with sufficient privileges and visibility to access everything contained on the system being analyzed.

Authenticated Scan: On‑site or Remote? 

Authenticated scans can be carried out in two different ways: on‑site or remotely.

If the scan is performed through a VPN or a similar connection to the servers that need to be scanned, this results in a higher load on the VPN network and slower scanning speeds.

On the other hand, if the scan is performed on‑site, auditors must be granted access to the location where the servers are hosted or where they can be directly accessed in order to analyze the environment. This approach provides faster scanning speeds due to the higher bandwidth available when connecting directly to the servers.

Recommendations for Performing an Authenticated Scan

 Below, we will list a series of steps to prepare an authenticated scan: 

1. Define the scope. It is necessary to inventory the environment and the systems connected to the networks that will undergo the scan. Any devices that the client chooses not to scan in an authenticated manner—whether due to technical or business limitations—will be analyzed without credentials, and this will be justified in the subsequent report.
2. Credential management. Create accounts with sufficient privileges on each host. It is recommended that the created users be able to authenticate via SSH in the case of Linux systems, or via WinRM/SMB for Windows machines. It is necessary to validate the credentials on all hosts to ensure that authentication works correctly.
3. Infrastructure preparation. For this stage, we recommend two network rules :
   ▪️Temporary whitelisting of the scanner’s IP address in firewalls, IPS/IDS, and EDR solutions.
   ▪️Adjusting multi‑factor authentication policies for the scanning account. 
4. Scan impact. It is recommended to schedule the task during low‑traffic windows to avoid service disruptions or similar issues on the host or the network.
5. Log monitoring. Verify with the auditing team that the scan was successfully completed. If any hosts failed, the scan must be repeated on those systems.
6. Analyze and remediate. The vulnerabilities that resulted in a PCI FAIL, as well as any others considered high‑priority, must be addressed. A plan should also be created to mitigate the remaining findings.
7.  Verification audit. Once the vulnerabilities have been resolved, a new scan must be performed to demonstrate that they were properly remediated. 
8. Evidence documentation. Finally, the scan task files and the result reports must be retained.

Common issues and possible solutions

As discussed earlier in the article, authenticated scans provide a deeper and more accurate analysis of the environment, but they also introduce technical and operational challenges that must be properly managed. Below are some of the main issues that typically arise and their possible solutions.

1. Credentials and authentication
   ▪️Hosts that will not undergo an authenticated scan must be properly identified and documented. In such cases, a non‑authenticated scan is recommended. 
   ▪️Incorrect or low‑privilege credentials lead to false negatives (vulnerabilities that exist but the scanner cannot detect). The best approach is to validate the credentials before the scan. 
   ▪️In some cases, authentication requires a specific type of encryption. This must be configured on the server. 
2.  Impact on the network and systems 
   ▪️It is recommended to reduce the number of scanning threads and/or enable “safe checks” in the tool. 
   ▪️Ideally, the scanner’s IP should be temporarily authorized and the change logged to avoid blocks. 
   ▪️Since authentication allows for deeper analysis, authenticated scans take longer than non‑authenticated ones. 
3.  Operational complexity and organization 
   ▪️In critical or sensitive networks, it is necessary to schedule a maintenance window that does not affect production. 
   ▪️Expired passwords: The credentials used for the scan may be expired or inactive, preventing authentication. For this reason, they must be checked beforehand, ensuring for example that they will not expire before the scan. 
   ▪️Systems offline: Some hosts may be powered off, disconnected, or unavailable during the scan. 
   ▪️Inactive protocols: Services such as SSH or WMI may be disabled, blocked by firewalls, or not configured to allow this type of traffic. 

Conclusions and key practices

▪️Adopting internal authenticated scanning reduces the risk of overlooking deeply rooted vulnerabilities that would otherwise remain undiscovered.
 
▪️During the first authenticated scan, it is likely that new vulnerabilities will appear. PCI is correct in noting that many components are outdated and contain vulnerabilities that a normal scan would never detect. Fortunately, most of the vulnerabilities found in these cases are related to outdated versions, which means the remediation process is, in most cases, simpler. 
 
▪️A key practice is to keep both software and hardware up to date. Quarterly scans verify that everything is in order and help resolve potential issues, resulting in a more secure infrastructure and, ultimately, achieving PCI DSS certification.