Internal vs External Vulnerability Scanning: Why PCI DSS Requires Both
Internal vs external vulnerability scanning differs by vantage point and purpose. External scans test internet-facing systems from outside your network. Internal scans test systems from inside, where attackers land after a perimeter breach. PCI DSS v4.0.1 requires both: quarterly external scans by an Approved Scanning Vendor (Requirement 11.3.2) and quarterly credentialed internal scans (Requirement 11.3.1.2).
One of our clients recently opened a compliance review by handing us a clean ASV attestation and asking what was left to fix. The attestation was correct: every in-scope external system had passed its quarterly ASV scan. The answer was still that almost everything was left to fix, because the systems that touch cardholder data were not in that scan's view at all. In our assessments, that gap traces back to one confusion: what internal vs external vulnerability scanning actually measures. The external ASV result is evidence about the perimeter, and it gets read as evidence about the whole environment.
That misreading is the subject of this post, and the timing is not random. In mid-September, Cisco disclosed that an unauthenticated zero-day in Identity Services Engine (CVE-2026-76460, CVSS 10.0) was being actively exploited, and CISA added the vulnerability to its Known Exploited Vulnerabilities catalog on September 16 [4]. ISE is the access-control appliance that sits inside enterprise networks. No external scan will ever flag it, and CISA's September 19 federal remediation deadline for it landed the same week [4]. Below we break down what each scan actually measures, what PCI DSS v4.0.1 requires of each, and how to scope the internal side so it proves something.
What Is the Difference Between Internal and External Vulnerability Scanning?
An external scan tests your systems from outside your network, from the vantage point of an attacker on the internet. An internal scan tests them from inside your network, from the vantage point of an attacker who has already got in. The two measurements answer different questions, and the findings they produce overlap only in a small band.
| External scan | Internal scan | |
|---|---|---|
| Vantage point | Outside the network (internet) | Inside the network (a host, segment, or vantage system) |
| What it sees | Internet-facing services, ports, TLS, web applications, exposed management interfaces | Shared services, internal applications, identity infrastructure, management planes, patch state |
| Typical technique | Unauthenticated | Unauthenticated or credentialed (authenticated) |
| PCI DSS role | Requirement 11.3.2, by an ASV, at least quarterly [1] | Requirement 11.3.1.2, with authenticated credentials, at least every three months [2][3] |
| What a pass means | The perimeter is quiet | Nothing about the perimeter, and only as much as the vantage point and credentials allow |
The row that causes the most confusion is the technique row. An internal scan is not automatically a credentialed scan. You can run an unauthenticated scan from a host inside the network and get only a network view of what that host can reach. Requirement 11.3.1.2 is explicit that the internal scan must use authenticated credentials, so the scanner can see installed software, missing patches, and configuration state, not just open ports [2][3]. We covered why that distinction matters in why credentialed vulnerability scans can report success even when the scan account has quietly lost access.
Why Does PCI DSS Require Both Scans?
Because a pass on one of them is not evidence about the other. Requirement 11.3.2 requires evidence of external scans performed by an ASV, passing at least once every three months, and PCI DSS v4.x added that obligation to SAQ A specifically because breaches of external-facing web properties had been targeting SAQ A merchant environments at alarming rates [1]. The external scan exists to protect the link between your store and the payment provider.
Requirement 11.3.1.2 is the companion obligation. It requires internal vulnerability scanning at least once every three months, using authenticated credentials, with rescans until high-risk vulnerabilities are remediated [3]. It is a new requirement from PCI DSS v4.0, and it applies to organizations on the v4.0.1 standard [2]. The standard's logic is straightforward: the breach path in a payment environment usually starts outside and finishes inside, and the outside measurement is structurally blind to the second half.
Clone Systems' position, from the assessment side of this: the external ASV pass is a compliance artifact, and the credentialed internal scan is the security result. Organizations routinely budget, document, and defend the ASV attestation line by line. The internal scan gets a vantage point, a credential, and whatever cadence the team remembers. When the two are compared in an audit, the gap shows up as a program that is strong on the document and weak on the measurement.
What Can an External Scan Never See?
By design, the systems that do not face the internet. That is not a defect to be fixed with better configuration; it is the geometry of the measurement. An ASV scanner sits outside your network and can only test what the internet can reach: storefronts, checkout pages, mail, remote-access portals, and any management interface that is (mistakenly) exposed. Everything else, the databases, the identity platform, the internal application servers, the management planes, is invisible to it.
CVE-2026-76460 is a good example of why the geometry matters. The flaw sits in the web-based management API of Cisco ISE and ISE-PIC, and an unauthenticated remote attacker can exploit it with a crafted request to bypass authentication and gain root-level command execution on the device [4]. It scores 10.0 on CVSS. In most deployments the ISE management interface is not internet-facing, so no external scan will ever test it. Cisco reported active exploitation, said there is no workaround, and recommended infrastructure ACLs to restrict management traffic to the device while the patch is applied [4]. CISA's KEV listing makes the priority unambiguous for anyone watching that catalog [5].
The internal geometry matters just as much as the external one. Zero Networks' 2026 Lateral Movement Exposure Report, built from 54 trillion activities across 312 live enterprise environments, found that 80% of enterprise servers are reachable from anywhere inside the network, that 87% accept inbound RDP or SSH from broad internal sources, and that a single compromised host can reach 85% of internal systems on the first hop [6]. Once an attacker is in, the question is not whether the vulnerability exists. It is whether your scanning program can see it from the side the attacker is standing on.
What Does an Internal Scan Actually Find?
This is where the coverage matrix earns its keep. The Clone Systems Scan Coverage Matrix maps the finding classes we see in payment environments to the scan type that reliably finds them:
The Clone Systems Scan Coverage Matrix
| Finding class | External (ASV) | Unauthenticated internal | Credentialed internal |
|---|---|---|---|
| Internet-facing service misconfigurations, TLS, web app issues | Yes | No | No |
| Exposed management interfaces (if internet-facing) | Yes | Yes | Yes |
| Open ports and running services on internal segments | No | Yes, from reachable vantage points | Yes |
| Missing OS and application patches | No | Partially (banner inference) | Yes |
| Local privilege escalation and weak service accounts | No | No | Yes |
| Configuration drift, excessive privileges, stale credentials | No | No | Yes |
| Reachability of the CDE from a foothold | No | Partially (network layer only) | Yes, combined with scope design |
Read the matrix the way an assessor reads it. The top rows are what the ASV attestation covers, and a pass there is real evidence, but it is evidence about a narrow question. The bottom rows are where a breach gets finished, and they are only visible to a credentialed scan with the right scope.
In our engagements, the most common internal program we inherit is a single unauthenticated scan from one vantage point, run quarterly and shared with the acquirer as "the internal scan." It reliably finds the shared services that vantage point can see. It says nothing about what a foothold on the office segment, a jump server, or a compromised identity appliance can actually do, and it does not meet the credential requirement of 11.3.1.2 in the first place [7]. Two more failure modes are worth naming because they are common even in credentialed programs: the scan account that quietly loses access and still returns a green report, which we dissected last week [8], and the patched system that still looks vulnerable because the scanner reads a version string rather than the package state, covered in why your vulnerability scanner flags patched systems [9].
If you run an ASV program for your external obligation, Clone Systems is a PCI SSC Approved Scanning Vendor. For the internal side, our network vulnerability assessment service runs credentialed internal scans with multi-vantage coverage, and our agent-based scanning and credentialed scanning offerings exist for the systems a network scan cannot reach cleanly. Talk to our team if you want a second look at what your current program actually covers.
How Do You Decide Your Internal Scan Scope?
The scope question is where most programs quietly fail, because the tempting answer is "the CDE IP range." In practice, the systems that produce findings are not the CDE servers. They are the shared management planes, the identity infrastructure, the backup and monitoring channels, and the standing vendor access that can reach the CDE without crossing a tested segmentation boundary. We made that argument for pen test scope in why PCI DSS internal penetration testing finds the systems your scope diagram missed [11], and the same logic applies to scanning: scope by reachability, not by address range.
A three-question test you can run against your current scope in about ten minutes:
- List every system that can reach the CDE without crossing a tested segmentation boundary. That list is your scan scope, regardless of where the systems sit on the network diagram.
- Check the credentials, not just the status. For every in-scope system, confirm the scan account can still do what 11.3.1.2 expects, and that a loss of access would fail the scan rather than pass it silently [8].
- Date the last rescan after a significant change or a new exploited class. A quarterly schedule that did not rescan the ISE fleet this week, or after a recent internal change, is a schedule, not a program.
Cadence is the easy part. Quarterly is the floor for both obligations, and the systems that change fastest need more [10].
How Clone Systems Can Help
We run all three columns of the coverage matrix. The external obligation: ASV scanning with quarterly attestation, rescans included, and a human on the other end when a finding turns out to be a false positive. The internal obligation: credentialed scanning from multiple vantage points, agent-based coverage where the network cannot reach, and a scope built on reachability rather than a network diagram. The deliverable is not just a report. It is evidence you can put in front of an assessor: what was scanned, from where, with which credentials, and what the pass actually covers.
If your last internal scan came from one vantage point and you are not certain it met the credential requirement, start with a conversation about your scope. We will show you the gap between your attestation and your actual internal coverage before the assessor does.
Frequently Asked Questions
What is the difference between internal and external vulnerability scanning? An external scan tests your systems from outside your network, the way an attacker on the internet would. An internal scan tests them from inside, the way an attacker who has already breached the perimeter would, and PCI DSS v4.0.1 requires both on separate cadences.
How often should internal vulnerability scans be run? PCI DSS 11.3.1.2 requires internal vulnerability scans at least once every three months, with rescans until high-risk vulnerabilities are remediated. Many environments benefit from more frequent internal scanning where systems change often.
What does PCI DSS requirement 11.3.1.2 require? It requires organizations to perform internal vulnerability scans using authenticated credentials at least once every three months. The scan must be able to see installed software, patches, and configuration state, not just open ports.
Can an external ASV scan replace an internal scan? No. An external scan only tests what the internet can reach, so it cannot see the internal systems, identity infrastructure, and management planes where most post-breach risk lives, which is why PCI DSS treats the two as separate obligations, 11.3.2 and 11.3.1.2.
Do internal vulnerability scans have to be done by an ASV? No, PCI DSS does not require an ASV to perform the internal scan the way it does for the external scan [1][2]. The requirement is on the method and cadence: authenticated credentials, at least every three months, and rescans until high-risk findings close.
Conclusion
A passing external scan is the cheapest good news in payment compliance, and it is also the most incomplete. The perimeter being quiet is one question. The question that decides whether a breach ends at the perimeter is what an attacker can do from inside, and that is only measurable from inside, with credentials, on a scope built around reachability. Run the three-question test, put the credentialed internal scan on the same cadence and the same rigor as the ASV attestation, and treat the two reports for what they are: one about the door, one about what is behind it.
Start with www.clone-systems.com. We will walk you through both.
References
[1] PCI Security Standards Council: Resource Guide: Vulnerability Scans and Approved Scanning Vendors, July 10, 2024 (Requirement 11.3.2 requires passing external ASV scans at least once every three months; the obligation was added to SAQ A in PCI DSS v4.x). https://blog.pcisecuritystandards.org/resource-guide-vulnerability-scans-and-approved-scanning-vendors
[2] PCI Security Standards Council: PCI DSS v4.0.1, Requirement 11.3.1.2 (internal vulnerability scanning using authenticated credentials, at least every three months). https://www.pcisecuritystandards.org/document_library/
[3] Tevora: Demystifying PCI DSS Requirement 11.3.1.2: Why Authenticated Internal Vulnerability Scans Matter, November 18, 2025 (credentialed scans at least every three months, rescan until high-risk vulnerabilities remediated). https://www.tevora.com/resource/demystifying-pci-dss-requirement-11-3-1-2-why-authenticated-internal-vulnerability-scans-matter/
[4] The Hacker News: Cisco Warns of New Zero-Day ISE Auth Bypass (CVSS 10.0) Exploited in Active Attacks, September 17, 2026 (CVE-2026-76460, unauthenticated remote authentication bypass on the ISE/ISE-PIC management API, active exploitation, root command execution, no workaround, iACL mitigation, CISA KEV addition on September 16 with a September 19 FCEB remediation deadline). https://thehackernews.com/2026/09/cisco-warns-of-new-zero-day-ise-auth.html
[5] CISA: Known Exploited Vulnerabilities Catalog (authoritative list of vulnerabilities exploited in the wild, used as a prioritization input for vulnerability management). https://www.cisa.gov/known-exploited-vulnerabilities-catalog
[6] Zero Networks: 2026 Lateral Movement Exposure Report (80% of enterprise servers reachable from anywhere internally; 87% accept broad RDP/SSH; a single compromised host reaches 85% of internal systems on the first hop; analysis of 312 live enterprise environments). https://zeronetworks.com/resource-center/reports/2026-lateral-movement-exposure-report
[7] Clone Systems: In our PCI and vulnerability assessments, the most common internal scanning program we inherit is a single unauthenticated scan from one vantage point, run quarterly, which reliably finds the shared services that host can reach and says nothing about lateral reach from other segments.
[8] Clone Systems: Why Credentialed Vulnerability Scans Report Success Even When the Scan Account Has Lost Access. https://www.clone-systems.com/blog/why-credentialed-vulnerability-scans-report-success-even-when-the-scan-account-has-lost-access
[9] Clone Systems: Why Your Vulnerability Scanner Flags Patched Systems (And What Actually Closes the Finding). https://www.clone-systems.com/blog/why-your-vulnerability-scanner-flags-patched-systems
[10] Clone Systems: How Often Should You Run Vulnerability Scans? https://www.clone-systems.com/blog/how-often-should-you-run-vulnerability-scans
[11] Clone Systems: Why PCI DSS Internal Penetration Testing Finds the Systems Your Scope Diagram Missed. https://www.clone-systems.com/blog/pci-dss-internal-penetration-testing-scope-gap
[12] Clone Systems: Network Vulnerability Assessment Services. https://www.clone-systems.com/network-vulnerability-assessment-services/