PCI DSS v4.0: How to Move from Formal Scanning to Managed Security 

06.10.2026

The PCI DSS requirement to scan once every 3 months is not enough to build comprehensive security.

It is necessary not only to launch a scanner, but also to verify whether it covered all required systems and how complete the results are. They are affected by scanner settings, account privileges, and connection stability.

Next, identified vulnerabilities must be assessed, remediated, and re-tested. It is precisely on such a cycle that the PCI DSS approach to infrastructure protection is based.

Let us consider how to organize this process and not turn scanning into a formal compliance procedure.

Authenticated Scanning under PCI DSS

This is a vulnerability detection method during which the scanner logs into the system using credentials. After this, it executes local diagnostic procedures within the limits of the granted privileges. Authenticated scanning makes it possible to collect comprehensive data about the node’s state, in particular to analyze:

During regular network scanning, part of this data may be inaccessible or determined incorrectly.

The requirement for authenticated internal scanning is established by requirement 11.3.1.2 of PCI DSS v4.0. Previously, it was a best practice (recommendation), but starting from April 1, 2025, it became mandatory.

The requirement applies to systems for which authenticated scanning is technically feasible. For them, it is necessary to use an account with privileges sufficient to detect known vulnerabilities.

If the environment technically does not support authenticated scanning, this must be documented and a technical justification provided. For systems that support it, one should monitor not only authentication success, but also the completeness of local checks.

How Does Regular Scanning Differ from Authenticated Scanning?

Unauthenticated scanning checks the system over the network without credentials.

Usually, it discovers:

During authenticated scanning, the utility uses credentials and performs local checks within the granted privileges. It is capable of analyzing installed software, packages, security updates, services, and configuration parameters.

The scanner can check installed software, packages, security updates, services, and configuration parameters. At the same time, successful authentication itself is not enough: additional privileges may be required for a full check.

Unauthenticated scanning
Scanner ───► network interface ───► accessible services

Authenticated scanning
Scanner ───► credentials ───► OS ───► local data and checks

What Privileges Does the Scanner Account Need?

Creating a separate account for the scanner is only the first step. The status “Authentication successful” means that the scanner gained access to the system, but does not confirm that all necessary local checks were performed.

According to requirement 11.3.1.2, account privileges must be sufficient to collect system parameters:

Standard user rights are mostly insufficient for this. For example, a scanner may successfully connect to a Linux server via SSH, but not have the rights to execute administrative commands or read system logs. In such a case, the check will be incomplete.

This does not mean that the scanner account must be granted maximum privileges in the domain or operating system. The access level is determined based on scanner vendor recommendations, the OS type, and the principle of least privilege.

The key question is: does the scanner, after authentication, have sufficient rights to collect the data necessary to detect vulnerabilities?

How to Verify Actual Coverage

The “Scan completed” notification means only that the task has finished. It does not confirm that every system was actually scanned and authentication was successfully performed.

Let us consider an example of a PCI DSS environment with 100 servers:

If on some servers credentials did not work or file access errors occurred, such systems cannot be considered fully scanned. It is necessary to remediate the access issue and conduct a re-scan.

When There Is Risk, but No CVE

Not all vulnerabilities have a CVE identifier. Risk can be created by excessive access privileges, insecure configuration parameters, superfluous active services, or incorrect file permissions.

A scanner may classify such an issue as a medium-level defect. However, this rating does not always reflect the real danger to the business. The base CVSS score shows only the technical criticality of the defect, but does not take into account the context of a specific infrastructure. For example, the same configuration defect has a different impact on an isolated test server versus in a PCI DSS payment environment.

For example, a single configuration issue can have a different impact on a test server and on a critical component of a PCI DSS environment.

PCI DSS Requirement 6.3.1 obliges an organization to independently classify risks taking into account the specifics of its environment. Scanner reports provide data for analysis, but do not replace internal expertise.

Scan Profiles: Vulnerabilities and Configuration

Scanners can check various aspects of security:

These checks do not replace each other. A vulnerability scan may not detect insecure settings, such as unnecessary services, weak password policies, or improper file permissions.

At the same time, compliance with CIS Benchmarks does not mean that there are no known vulnerabilities in the installed software. Therefore, results of vulnerability and configuration checks must be analyzed together.

Outdated Configuration Standards — A Hidden Problem

Configuration check reports capture not only server deviations. They may also indicate that the company’s internal security standard is already outdated.

For example, servers might be configured according to an old internal guideline, while technology vendors or CIS have already updated their recommendations. If the scanner uses an up-to-date profile, it will reveal new deviations from these recommendations.

In such a case, fixing individual server settings is not enough. It is necessary to review the internal configuration hardening standard and update it in accordance with current requirements.

From the Scanning Process to Vulnerability Remediation

Scanning captures the state of systems at a specific point in time, whereas vulnerability management covers the entire cycle:

Identify → Assess → Prioritize → Remediate → Re-check → Confirm result

According to Requirement 11.3.1, internal scanning must be performed at least once every 3 months and after significant changes in the environment. Critical and high-risk vulnerabilities must be eliminated within established timeframes. Following this, a re-scan must be performed to document and confirm resolution of the issue.

Requirement 6.3.3 specifies a timeframe for applying critical security patches — within one month of their release.

Regularly running a scanner by itself does not demonstrate an adequate security posture. If the same vulnerability carries over from one quarterly report to the next, the scanner is doing its job, but the vulnerability management process requires review.

The controllability of an environment is indicated by:

Find the Weak Points in Your Vulnerability Management Process

A quarterly scanner report shows only part of the real picture. Mature vulnerability management involves controlling what was verified, what issues were discovered, how they were resolved, and whether the result was confirmed.

This helps prevent situations where the same gaps carry over from one report to another.

GetPCI specialists will analyze your current security posture, identify weak points, and gather the necessary evidence for PCI DSS assessment. Contact us today!