New PCI DSS Requirement: Authenticated Internal Vulnerability Scans – Effective April 1, 2025

Starting April 1, 2025, PCI DSS Requirement 11.3.1.2 introduces a new obligation for organizations: internal vulnerability scans must be performed using authenticated scanning.

You will find all the details below but first let's start with the common questions that often have no answer or are not clearly defined in the standard

1. What level of permissions should be assigned to the account used for scanning? Should it be admin/root, or are there specific guidelines from the PCI Council regarding this?

PCI DSS 11.3.1.2 requires sufficient privileges to allow a comprehensive authenticated scan, but it does not explicitly mandate admin/root access.

Key point from the standard: “Sufficient privileges are those needed to access system resources such that a thorough scan can be conducted that detects known vulnerabilities.”

That means:

• Admin/root is not required by default, but may be necessary depending on the system architecture and the scanning tool’s requirements.
• The least privilege principle should be applied wherever possible — privileges should only be as high as needed for effective scanning.
• Credentials used for scanning are considered highly privileged and must be protected and managed according to Requirements 7 and 8 (access control and authentication), including secure storage, rotation, and possibly MFA if interactive login is allowed.

2. Should all systems be scanned in an authenticated manner, or is sampling allowed? If sampling is permitted, who is responsible for selecting the samples? Can QSAs handle this?

PCI DSS 11.3.1.2 requires authenticated scans for all in-scope internal systems, except those where credentials cannot be used (e.g., some appliances, mainframes, or containers).

There is no allowance for sampling for this requirement unless explicitly justified and documented.

Sampling is not allowed unless:

• The system cannot technically support credentialed scanning (must be documented).
• A targeted risk-based approach (TRA) is used — in which case sampling must be defined, justified, and approved by the entity and verified by the QSA.

So in short:

• ✅ All in-scope systems must be scanned with authentication, unless technically not feasible.
• ❌ Sampling is not permitted for convenience.
• 👤 QSAs cannot independently decide on sampling — but they do verify and approve entity-defined justifications, especially if a TRA is involved.

3. Are SSH and Windows authentication sufficient to meet PCI DSS requirements for authenticated scanning?

Yes — SSH for Unix/Linux systems and Windows authentication (typically with SMB/WinRM) are the standard and accepted methods for authenticated scanning under PCI DSS.

PCI DSS does not prescribe specific protocols, but requires that:

As long as:

• The credentials provided via SSH or Windows auth allow the scan to access necessary resources,
• And the scanning results reflect a deep, accurate system assessment,

👉 then SSH and Windows authentication are sufficient to meet PCI DSS 4.0.1 authenticated scanning requirements.

Here's what this means — and why it matters.

✅ What Is an Authenticated Scan?

An authenticated scan uses system credentials (such as a username and password or SSH key) to access a system from the inside. This method allows the scanning tool to:

- Access internal resources like registries, configuration files, and installed software.

- Detect vulnerabilities in applications, libraries, packages, and system configurations.

- Identify issues that unauthenticated (network-based) scans cannot see.

🔍 Think of it as an "inside-out" view of system security, rather than the "outside-in" approach of traditional scans.

🔄 Key Differences: Authenticated vs. Unauthenticated Scans

⚙️ What’s Required to Perform an Authenticated Scan?

To perform authenticated vulnerability assessments effectively and securely, organizations must ensure:

- Valid Credentials: Accounts with sufficient privileges to access system resources (but with least privilege where possible).

- Secure Credential Management: Credentials must be encrypted, rotated, and tightly controlled.

- Access Controls: Ensure scanners can reach all in-scope systems while enforcing strict monitoring.

- System and Network Configuration: Firewalls and segmentation may need temporary adjustments during the scan.

- Resource Planning: Scans can be resource-intensive; schedule accordingly to avoid impact.

- Policy Compliance: Scans should align with internal security and compliance frameworks.

🔐 Security Considerations for Credential Use

Scanning accounts are highly privileged and must be managed accordingly.

If these accounts allow interactive login, they must comply with PCI DSS Requirement 8.2.2, including secure authentication mechanisms.

Privileges must be “sufficient” to allow a full vulnerability assessment — but should not exceed what’s necessary.

Systems unable to support credentialed scans (e.g., network appliances, some containers, or third-party-hosted platforms) must be clearly documented.

⚠️ Challenges to Be Aware Of

Performing authenticated scans brings powerful benefits — but also new challenges:

- Credential errors: Mismatched usernames/passwords or expired keys.

- SSH key issues: Incorrect passphrases or unsupported key formats.

- Parsing failures: Bad formatting or corrupted credentials.

- Permission mismatches: Accounts lacking access to critical components.

- Effort: The time and resources required to perform a scan may increase significantly.

These issues must be proactively addressed to ensure successful scans and avoid false negatives.

📜 PCI DSS Requirement 11.3.1.2 in Summary

Internal vulnerability scans are performed via authenticated scanning as follows:

- Systems that are unable to accept credentials are documented.

- Sufficient privileges are used for systems that support credentialed scanning.

- Interactive accounts follow Requirement 8.2.2 if applicable.

🎯 Why This Matters

Authenticated scanning provides significantly greater insight into your security posture — identifying critical vulnerabilities that may be invisible in unauthenticated scans.

🔐 Attackers may exploit these hidden flaws, so organizations must evolve their scanning practices to uncover and remediate them early.

🧠 Best Practices Moving Forward

- Treat scanning credentials with the same level of protection as other privileged accounts.

- Integrate authenticated scans into your internal vulnerability management program.

- Start preparing well ahead of April 2025 to ensure full compliance without operational disruption.

💬 Need help adapting your vulnerability scanning processes to meet the new requirements? Reach out — we’re here to help make your transition smooth and secure.

#PCIDSS #CyberSecurity #VulnerabilityScanning #Compliance #AuthenticatedScan #RiskManagement #InfoSec