PCI DSS 11.3.1.2: Internal vulnerability scans are performed via authenticated scanning
PCI DSS v4.0.1 control 11.3.1.2: the requirement in full, the 4 testing procedures an assessor uses to verify it, and the related controls in section 11.3.
Requirement 11: Test Security of Systems and Networks Regularly › Section 11.3
Internal vulnerability scans are performed via authenticated scanning as follows:
- Systems that are unable to accept credentials for authenticated scanning are documented.
- Sufficient privileges are used for those systems that accept credentials for scanning.
- If accounts used for authenticated scanning can be used for interactive login, they are managed in accordance with Requirement 8.2.2.
Summary
Internal scans log in to the systems they scan, with enough privilege to see what is there.
What the assessor will examine
These are the testing procedures the standard defines for this control. They tell you what evidence to have ready.
| Procedure | |
|---|---|
| 11.3.1.2.a | Examine scan tool configurations to verify that authenticated scanning is used for internal scans, with sufficient privileges, for those systems that accept credentials for scanning. |
| 11.3.1.2.b | Examine scan report results and interview personnel to verify that authenticated scans are performed. |
| 11.3.1.2.c | If accounts used for authenticated scanning can be used for interactive login, examine the accounts and interview personnel to verify the accounts are managed following all elements specified in Requirement 8.2.2. |
| 11.3.1.2.d | Examine documentation to verify that systems that are unable to accept credentials for authenticated scanning are defined. |
The single largest quality difference between one internal scan and another. An unauthenticated scan sees what a stranger on the network sees: open ports and banners. An authenticated scan sees installed package versions, configuration and missing patches, which is most of what a vulnerability scan is for. Three elements, and the third is easy to miss: if the accounts used for scanning can be used for interactive login, they are managed in accordance with 8.2.2, the shared-account exception rules. Scan accounts are privileged and shared by nature, so that link is doing real work. Procedure 11.3.1.2.d tests the first element separately: systems that cannot accept credentials must be documented, so "some things can't be scanned properly" needs to be a list rather than a remark.
What to prepare
- Scan tool configuration showing credentials in use and the privilege level they carry.
- Scan reports demonstrating authenticated results rather than port-only findings.
- The documented list of systems that cannot accept credentials, with the reason for each.
- The scanning accounts themselves, and whether they permit interactive login.
How to implement it
1. Check the scan actually authenticated. Most tools report authentication success per host, and a credentialed scan that silently failed to log in looks like a clean result.
2. Give it sufficient privilege, and say so. The second element is about privilege being sufficient, and a read-only account that cannot see patch state produces an authenticated scan with unauthenticated coverage.
3. Stop the scan account logging in interactively where you can. It removes the 8.2.2 obligation entirely and is a better arrangement anyway, since these accounts exist for a machine.
4. Keep the exception list short and current. It is examined directly, and a long list is an argument that the scanning programme does not cover the environment.
Where this commonly fails
- Credentials configured and authentication failing, producing thin results that look like a healthy scan.
- Insufficient privilege, so patch and configuration state is invisible.
- Scan accounts usable interactively with no 8.2.2 handling, failing the third element.
- Systems that cannot be credentialed known informally and never documented, which fails 11.3.1.2.d.
Related controls
This control refers to 8.2.2.
Others in section 11.3:
| Control | What it requires |
|---|---|
| 11.3.1 | Internal vulnerability scans… |
| 11.3.1.1 | All other applicable vulnerabilities… |
| 11.3.1.3 | Internal vulnerability scans are performed after any significant change… |
| 11.3.2 | External vulnerability scans… |
| 11.3.2.1 | External vulnerability scans are performed after any significant change… |
← 11.3.1.1 · All controls · 11.3.1.3 →
Source
The requirement text and testing procedures above are reproduced from PCI DSS v4.0.1 (June 2024), ©2006-2024 PCI Security Standards Council, LLC. All rights reserved. The commentary is our own.
The official standard is authoritative and also contains the Customized Approach Objective, applicability notes and guidance for this control. Download it from the PCI Security Standards Council document library. PCI DSS is a registered standard of the PCI Security Standards Council, LLC, which does not endorse this site. Nothing here is a substitute for advice from a Qualified Security Assessor.