Authenticated Internal Scanning: What Requirement 11.3.1.2 Means for You

Requirement 11.3.1.2 in PCI DSS v4.0 says your internal vulnerability scans must be authenticated. The scanner logs in to each system, or runs an agent on it, instead of only probing it from the network. You need to use sufficient privileges, document any systems that can't accept scan credentials, and manage scan accounts that allow interactive login under Requirement 8.2.2. It's a best practice until March 31, 2025, when it becomes mandatory. With v3.2.1 retiring at the end of this month, many organizations face their first v4.0 assessment this year, which makes now a good time to get scanning right.

What does requirement 11.3.1.2 say?

The requirement reads: "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.

The applicability notes add useful detail. Authenticated scanning tools can be host-based or network-based, so agent-based scanning counts. The requirement doesn't apply to system components that can't accept credentials for scanning. The standard gives some network and security appliances, mainframes and containers as examples of systems that may fall into that group.

What's the difference between authenticated and unauthenticated scans?

An unauthenticated scan sees what any host on the network sees: open ports, service banners and how services respond. The scanner infers versions from those clues and misses anything that isn't exposed on the wire. That includes missing operating system patches, vulnerable libraries, weak local configuration and outdated software that doesn't listen on a port.

An authenticated scan reads the system directly. It checks installed packages, patch levels, file versions and configuration settings. Results are more complete and involve less guesswork.

Expect a big jump in findings the first time you switch. That doesn't mean your environment got worse overnight. You're seeing what was always there.

How does 11.3.1.2 relate to 11.3.1 and 11.3.1.1?

The three requirements work as a set:

Think of 11.3.1 as the cadence and pass criteria, 11.3.1.2 as how the scans are run, and 11.3.1.1 as what you do with everything below the high-risk line. Severity comes from the risk ranking process you define under Requirement 6.3.1.

The pairing is deliberate. Authenticated scanning surfaces many more medium and low findings, and 11.3.1.1 requires a documented, risk-based way to handle them instead of letting them pile up. Your targeted risk analysis (TRA) for 11.3.1.1 should say which findings get fixed, in what timeframe, and why. The PCI SSC published targeted risk analysis guidance in November 2023, along with a sample template, which is a sensible starting point.

What counts as "sufficient privileges"?

Sufficient means the scanner can see everything it needs to detect known vulnerabilities: installed software and versions, patch state and the relevant configuration. A scan account that can log in but can't read the package database or registry will authenticate successfully and still miss most of what matters.

What that looks like varies by platform:

• Windows servers and workstations usually need rights to read the registry and file system remotely, which often means an administrative-level account.
• Linux and Unix systems need an account that can read package and configuration data. Some checks need elevated rights, typically granted through tightly scoped privilege escalation rules.
• Databases and other applications may need their own credentials if you scan them directly.

Assessors will examine scan tool configurations and scan results to confirm authenticated scans are happening with sufficient privileges. Most scanners report whether authentication succeeded on each host, so make reviewing that list part of every scan cycle. Treat a failed login as a coverage gap, not as noise.

How should you manage scan accounts?

If a scan account can be used for interactive login, 11.3.1.2 points you to Requirement 8.2.2. That requirement was written for group, shared and generic accounts, and it expects:

• Account use is prevented unless needed for an exceptional circumstance.
• Use is limited to the time needed for that circumstance.
• A business justification is documented.
• Use is explicitly approved by management.
• Individual identity is confirmed before access is granted.
• Every action taken is attributable to an individual user.

Those controls are awkward for an account a scanner uses unattended every week. The cleaner route is to design the scan account so a person can't log in with it interactively in the first place:

• Deny interactive and remote desktop logon rights to the scan account through policy.
• Use key-based authentication limited to the scanner's source addresses, without an interactive shell where your tooling allows it.
• Keep credentials in the scanner's credential store or a secrets vault, so no person needs to know them.
• Alert on any use of the account outside scan windows or from anywhere other than the scanner.
• Rotate credentials and include the account in your regular access reviews.

Where interactive login genuinely can't be blocked, apply 8.2.2 in full and treat human use of the account as a documented, approved, time-limited exception. Requirements 8.6.1 through 8.6.3, also future-dated to March 31, 2025, cover system and application accounts more broadly, so it's efficient to handle scan accounts in the same process.

How do you document systems that can't accept credentials?

Keep a simple register. For each system, record:

• The component and its owner
• Why it can't accept credentials, such as a vendor limitation or no supported login method
• What you do instead, for example unauthenticated scanning, tracking vendor security advisories and firmware versions, or configuration reviews
• When the entry was last reviewed

Revisit entries when firmware or platforms change, because vendors do add scanning support over time. For containers, many teams scan images before deployment and cover the host underneath with authenticated scans or agents.

Keep the register honest. A system that could accept credentials but nobody has set them up isn't an exception. It's a gap.

A practical rollout plan

1. Inventory in-scope systems by platform and planned scanning method.
2. Choose the credential approach for each platform: network credentials, agents or a mix.
3. Create scan accounts with sufficient privileges, blocked from interactive use wherever possible.
4. Pilot on a representative subset and compare results with your unauthenticated baseline.
5. Fix authentication failures until coverage is complete.
6. Triage the backlog. High-risk and critical findings fall under 11.3.1; everything else follows your 11.3.1.1 TRA.
7. Document systems that can't accept credentials.
8. Run at least one full quarterly cycle before March 31, 2025, so your first mandatory authenticated scan isn't your first real one.

Frequently asked questions

Does 11.3.1.2 apply to external ASV scans?

No. It covers internal vulnerability scans. External scans by an Approved Scanning Vendor fall under Requirement 11.3.2, which 11.3.1.2 doesn't change.

Can we use agents instead of network credentials?

Yes. The applicability notes allow host-based or network-based tools, and many organizations use both.

If we switch early, can the extra findings hurt our assessment?

They can. 11.3.1.2 is best practice until March 31, 2025, but 11.3.1 is in effect now. Any new high-risk or critical vulnerabilities an authenticated scan uncovers still have to be resolved and confirmed by rescan. Line up remediation capacity before you switch, not after.

Is authenticated scanning safe for production systems?

Authenticated checks mostly read information rather than send exploit traffic, but any scanning can affect fragile systems. Test on non-production first, schedule scans sensibly and watch the first few runs closely.

Next steps

• Read 11.3.1, 11.3.1.1 and 11.3.1.2 together and plan them as one project.
• Build scan accounts that can't be used interactively, and store their credentials where no person needs to see them.
• Start the exceptions register and the 11.3.1.1 TRA now.
• Get at least one authenticated quarterly cycle done well before March 31, 2025.