Internal and external vulnerability scanning are the same technique pointed in two different directions. External scanning tests your internet facing addresses from outside the perimeter. Internal scanning tests what is reachable once someone is already inside. The comparison gets explained badly almost everywhere, usually by bundling in credentials, tooling, and intent that have nothing to do with where the scanner sits. This guide separates them properly, covers what each one misses, and gives you a decision rule for which to run first.
Internal vs external vulnerability scanning: the short answer
External vulnerability scanning tests your internet facing IP addresses and domains from outside the network, showing what a remote attacker sees before they have any access. Internal vulnerability scanning tests hosts behind the firewall, showing what becomes reachable after an attacker gets a foothold. External finds the way in. Internal finds how far they get.
You need both, and they are not interchangeable. But if you are starting from zero, start external, for reasons covered further down that come from two independent authorities rather than opinion.
| External scan | Internal scan | |
|---|---|---|
| Scanner sits | Outside the perimeter | Inside the network |
| Answers | How does an attacker get in | How far do they get once in |
| Typical targets | Public IPs, domains, VPN and mail and DNS endpoints, cloud instances | Servers, workstations, routers, switches, printers, databases |
| Finds | Exposed services, unpatched perimeter software, weak TLS, open management ports | Missing patches, default credentials, weak segmentation, insecure configuration |
| PCI DSS requirement | 11.3.2, ASV required | 11.3.1, no ASV required |
| PCI DSS frequency | At least every 3 months | At least every 3 months |
| CIS Controls v8.1 | Safeguard 7.6, monthly or more often | Safeguard 7.5, quarterly or more often |
| Credentials | Optional, often unauthenticated | Should be authenticated, required by PCI 11.3.1.2 |
| Deployment | Cloud based, nothing to install | Connector, scanner VM, or agents |
Both are types of network vulnerability scanning, which covers the underlying mechanics that these two share.
What is an external vulnerability scan?
An external vulnerability scan runs from outside your network against the IP addresses, domains, and services you expose to the internet. It has no credentials and no privileged access, because neither does the attacker it is imitating. It enumerates what is reachable, fingerprints the software behind each open port, and reports which of those carry known vulnerabilities.
The case for running these often got a lot stronger recently. In the Verizon 2026 DBIR, exploitation of a known vulnerability became the most common initial access vector for the first time in the report’s nineteen year history, at 31 percent of breaches. More pointedly, breaches driven by exploitation of edge devices and VPN appliances jumped from 3 percent to 22 percent in a single year. Those are precisely the assets an external scan looks at, and precisely the assets an internal scan does not.
What external scanning finds
External scanning surfaces the exposures that need no insider help to reach. In practice the recurring findings are unpatched perimeter software such as VPN concentrators, firewalls, and mail gateways, which is where the CVEs with public exploit code do the most damage. It finds management interfaces that should never have been public: RDP on 3389, SSH open to the world, database ports bound to a public interface, admin panels with no IP restriction. It finds expired certificates and deprecated encryption such as SSLv3 and early TLS. And it finds assets nobody remembered, because an external scan starts from your public footprint rather than your asset list, which is the one situation where a scanner can tell you about something you never entered into it.
How external scanning is deployed
External scanning is the easier of the two to stand up, which is part of why it is the right first move. It runs from the provider’s infrastructure against addresses you nominate, so there is nothing to install, no connector to place, and no credential exchange required to get a first result. The practical work is scoping rather than deployment: listing every public IP range, every domain and subdomain, every cloud account with public addresses, and every third party host that carries your name. That list is almost always incomplete on the first attempt, which is why continuous external attack surface management sits alongside scanning rather than after it. If you only need to check a handful of addresses, a focused scan of a single public IP covers it.
What is an internal vulnerability scan?
An internal vulnerability scan runs from inside the network against hosts that are not reachable from the internet. It tests servers, workstations, network hardware, and internal applications for missing patches, insecure configuration, weak or default credentials, and anything else that helps an attacker move sideways once they are past the perimeter.
Internal scanning is usually authenticated, and under PCI DSS v4.0.1 it has to be. Requirement 11.3.1.2 made authenticated internal scanning explicit, which was one of the more consequential changes in the version and one that a lot of programs built under 3.2.1 still have not absorbed.
What internal scanning finds
The internal findings that matter are rarely the ones with the highest severity scores. They are the ones that shorten an attacker’s path. Default credentials on a switch, a printer, or a management interface come up constantly and are almost never caught by agent based tooling, because you cannot install an agent on a printer. Missing patches on internal file servers matter because SMB is the classic lateral movement route, which is why a service still exposed to EternalBlue, CVE-2017-0144, remains a live finding on internal scans nine years after Microsoft patched it. Flat network segments show up as an absence rather than a finding: everything can reach everything, so one compromised laptop reaches the domain controller. Insecure configurations, weak file permissions, and local privilege escalation paths only appear once the scanner has credentials, which is the entire argument for authenticated internal scanning.
The insider threat framing is mostly wrong
Almost every guide on this comparison justifies internal scanning with the disgruntled employee. It is a memorable story and it is not what the data says. Internal scanning earns its place because of what happens after an external compromise, not because of malicious staff. The DBIR found that credential abuse appears somewhere in 39 percent of all breaches, making it the most pervasive technique in the dataset even though it is no longer the top initial access vector, and that 73 percent of ransomware victims had prior infostealer activity on their systems. That is the actual sequence: an attacker gets in through an exposed service or a stolen credential, and then everything your internal scan would have found becomes their roadmap. Framing internal scanning as insider threat defense understates it and, worse, makes it easy for a budget holder to dismiss as paranoia about their own staff.
How internal scanning is deployed
Internal scanning needs something inside the network, and you have three options. A lightweight connector or scanner appliance sits on the network and reaches hosts over the wire, which is the only approach that covers routers, switches, firewalls, printers, and other devices you cannot install software on. Agents install on each endpoint and report back, which wins on laptops that are rarely on the corporate network and on cloud instances that come and go. A scanner VM is the traditional self hosted option and carries the most maintenance. Most real environments end up with a connector for network hardware and servers plus agents for roaming endpoints, and the same checks extended to cloud and hybrid hosts so the estate stays in one view instead of three.
Four axes people confuse with internal vs external
This is where most explanations of this comparison go wrong, including all three of the pages currently ranking for it. Internal versus external is one axis. It is not a bundle. Four independent properties get collapsed into it:
| Axis | Options | What it actually controls |
|---|---|---|
| Vantage point | External or internal | Which assets are reachable at all |
| Credentials | Authenticated or unauthenticated | How deep the scan sees into each host |
| Method | Active or passive | Whether the scanner sends traffic |
| Delivery | Network based or agent based | Which device types you can cover |
A scan picks one option from each row. External and authenticated is a valid, common combination. So is internal and unauthenticated.
Vantage point is not the same as credentials
The most persistent error on this topic is treating internal as a synonym for credentialed and external as a synonym for uncredentialed. They are different questions. Vantage point decides which hosts the scanner can reach. Credentials decide how much it can see on each host it reaches. Confusing them causes two concrete mistakes. The first is assuming external scans cannot be authenticated, which leads teams to accept a shallow view of internet facing web applications and cloud hosts where an authenticated scan would find considerably more. The second is assuming internal scans are automatically credentialed, so nobody notices when the credentials expire and the scan quietly degrades to a surface check while still producing a report that looks normal. CIS safeguard 7.5 asks for both authenticated and unauthenticated scans of internal assets precisely because they return different things.
When unauthenticated internal scanning is the right choice
There is a genuine use for running an internal scan without credentials, and it is not the insider simulation it is usually sold as. An unauthenticated internal scan tells you what a compromised device on that segment can see before it escalates anything: which services answer, which ports are open, what the segmentation actually permits as opposed to what the firewall rules claim. That is a segmentation test in miniature, and it answers a question the authenticated scan cannot, because the authenticated scan has permission and the attacker does not. Run both against internal assets. They are cheap, they overlap less than people expect, and PCI DSS treats segmentation validation as a separate annual requirement under 11.4.5 for the same underlying reason.
What each scan type misses
Neither view is complete, and knowing the shape of each blind spot is what stops a program from producing false confidence.
- External scanning misses everything behind the firewall. That includes the default credentials, the flat segments, the unpatched internal servers, and the local privilege escalation paths that turn a small foothold into a full compromise. It also misses anything that requires authentication to see, when run unauthenticated, which is most of the depth on any given host.
- Internal scanning misses your exposure. It cannot tell you that a firewall rule was changed last Tuesday and now exposes a management port, because from inside the network that port was always reachable. It also misses assets outside the ranges you configured, which in cloud environments changes weekly.
- Both miss the same three things. Neither finds zero-days, because both work by matching against published vulnerability data. Neither finds business logic flaws, which is why penetration testing remains a separate control. And neither chains findings into an attack path, because scanners score vulnerabilities one at a time while attackers combine them.
One more shared limit is worth naming because it gets missed on both sides. A network scan of either kind fingerprints the web server, not the application running on it. SQL injection, cross site scripting, and broken access control sit above the layer these scans inspect, so they need web application scanning regardless of how thorough your internal and external network coverage is.
Which should you run first?
If you have to choose, run external first. That is not a preference, it is what two independent authorities both point at.
CIS Controls v8.1 asks for automated scans of externally exposed assets monthly or more often under safeguard 7.6, while internal assets get quarterly or more often under 7.5. That is a three to one cadence asymmetry in a framework that is otherwise conservative, and it exists because internet exposure changes faster and matters more.
Then in June 2026, CISA’s BOD 26-04 revoked and replaced BOD 22-01 and BOD 19-02, and built its entire remediation model on three variables. The first is whether the vulnerable asset is publicly exposed. The second is whether the CVE appears in the Known Exploited Vulnerabilities Catalog. The third is whether an adversary can automate every step of exploitation. When all three line up, federal civilian agencies have three days. Nobody outside that scope is bound by it, but the signal is unambiguous: internet exposure is now the top level sort for vulnerability risk, which makes knowing your external exposure the prerequisite for prioritizing anything else.
The decision rule that follows is simple. Scan external first and continuously, because that is where the exploitation is and where the cadence expectation is highest. Add internal authenticated scanning as soon as you can place a connector, because that is where the damage happens and where compliance will ask for evidence. Do not treat the second step as optional just because the first one came back clean.
What compliance actually requires for each
This is the section the ranking pages skip, and it contains the single most decision relevant difference between the two scan types. Vague claims about helping with compliance are worth nothing without requirement numbers.
| Framework | External requirement | Internal requirement |
|---|---|---|
| PCI DSS v4.0.1 | 11.3.2, at least every 3 months, by a PCI SSC listed ASV; 11.3.2.1 rescan after significant change | 11.3.1, at least every 3 months; 11.3.1.2 must be authenticated; 11.3.1.3 rescan after significant change |
| CIS Controls v8.1 | Safeguard 7.6, monthly or more often, SCAP compliant tool | Safeguard 7.5, quarterly or more often, authenticated and unauthenticated |
| NIST SP 800-53 Rev 5 | RA-5, both perspectives, plus SI-2 flaw remediation | RA-5, both perspectives |
| ISO 27001:2022 | Annex A 8.8, process required, frequency not fixed | Annex A 8.8, same |
| SOC 2 | CC7.1, scan history commonly accepted as evidence | CC7.1, same |
Three details cause real problems in audits.
- Only an ASV can satisfy the external requirement. Requirement 11.3.2 does not just ask for an external scan, it asks for one performed by a vendor on the PCI Security Standards Council’s Approved Scanning Vendor list, and only an ASV can issue the Attestation of Scan Compliance your acquirer wants. Running an excellent external scan with a non-ASV tool does not close 11.3.2. The internal requirement, 11.3.1, has no equivalent restriction, so you can run internal scans with whatever tool you like.
- The ASV pass bar is stricter than most internal programs. Under the ASV Program Guide, any vulnerability scoring CVSS 4.0 or higher is an automatic fail, and you must remediate and rescan to pass. That is a far lower threshold than the critical and high triage most teams apply internally. Vulnerabilities that are purely denial of service do not cause a PCI failure.
- Scope is broader than people expect. ASV scanning must cover all public IPs and URLs routed to the in-scope environment, including mail servers, DNS, and VPN endpoints, and sitting behind a DMZ does not exempt anything. Separately, PCI DSS 4.0.1 brought SAQ A merchants into 11.3.2 scope for the first time, which the PCI SSC explains in its ASV resource guide. A great many small online stores using a hosted checkout are now required to scan and have never done it.
How often should you conduct internal and external vulnerability scans?
Treat every framework number as a floor rather than a target, because they were written as audit minimums and not as risk based recommendations.
| Cadence | External | Internal |
|---|---|---|
| Compliance minimum | Every 3 months, PCI DSS 11.3.2 | Every 3 months, PCI DSS 11.3.1 |
| Framework guidance | Monthly, CIS 7.6 | Quarterly, CIS 7.5 |
| Practical baseline | Continuous or weekly | Weekly on critical servers, monthly on the wider estate |
Calendar cadence alone misses the events that actually change your risk, so both scan types need triggers. Rescan externally after any change to internet facing services, after a firewall or DNS change, and whenever a new public asset appears. Rescan internally after network changes, after new systems are deployed, and after every remediation to verify it worked. When a major CVE lands in software you run, rescan both. The gap this closes is significant: the DBIR put median time to patch at 43 days, up from 32, against exploitation windows now measured in days, and a quarterly scan can leave something undiscovered for most of that 43 day average before the clock even starts. With roughly 48,000 CVEs published in 2025, a figure our 2026 vulnerability statistics breaks down by source, a host that scanned clean last quarter can be exploitable now without anyone touching it. Scheduled and event driven scanning across both perspectives is how our scanning plans are structured for that reason.
Why “external” is getting harder to define
The internal and external distinction assumes a perimeter, and that assumption is aging badly. It still holds well enough to be useful, but the edges have blurred in four ways worth planning around.
Cloud infrastructure hands out public IP addresses on demand, so your external footprint changes when a developer deploys, not when a network team files a change request. A quarterly external scan against a fixed IP list will systematically miss whatever was created and destroyed between scans. VPN concentrators and remote access gateways are simultaneously perimeter devices and the front door to the internal network, which is exactly why edge device exploitation rose sevenfold in the DBIR data. Remote and hybrid work means an internal host is often a laptop on a home network, reachable by neither an external scan nor a connector based internal scan unless an agent covers it. And SaaS and third party services hold your data on infrastructure you cannot scan at all, which is one reason third party involvement now appears in 48 percent of breaches.
None of this makes the distinction useless. It means external scanning has to be driven by continuous discovery rather than a static list, and it means the honest scope question is not “internal or external” but “which of my assets is reachable, by whom, and did that change this week”. Continuous network port and exposure monitoring answers the last part.
Prioritizing internal and external findings together
Once both scans are running you have two result sets and one remediation team, so they need a single queue rather than two competing ones. Running both through a single network vulnerability scanner rather than two tools is mostly about this, not about licensing: findings that arrive in separate dashboards get triaged against separate mental baselines. Four signals decide the order.
- Check exposure first. An internet facing host outranks an internal one at equal severity, which is now the explicit position of BOD 26-04 rather than just conventional wisdom.
- Check exploitation evidence next. If the CVE is in the KEV catalog, it moves to this week regardless of which scan found it.
- Check exploitation probability. FIRST’s EPSS model scores the likelihood of exploitation in the next 30 days, which regularly inverts a naive severity ranking. A CVSS 7.0 on an exposed service with a high EPSS score genuinely outranks a CVSS 9.0 nobody can reach.
- Apply business context last. Only you know which host holds customer data and which is a lab machine.
The one situation where an internal finding should jump the queue is when it sits directly behind a confirmed external exposure. An unpatched internal file server is a medium priority on its own and an emergency if the VPN in front of it has a public exploit, because those two findings are one attack path that neither scan reported as such. Reducing overall security exposure means reading the two result sets together, not filing them separately.
Common mistakes
- Running external only and calling it covered. External scanning validates the perimeter and tells you nothing about what happens after it fails. The DBIR data on credential abuse across the full breach chain makes that gap concrete.
- Running internal only because it finds more. Internal scans return higher volumes, which feels productive, but volume is not risk. Exposure is.
- Assuming a non-ASV external scan satisfies PCI DSS 11.3.2. It does not, no matter how thorough the tool.
- Letting scan credentials expire. An authenticated internal scan with dead credentials silently becomes an unauthenticated one and still produces a clean looking report.
- Scoping external scans from a static IP list. In any cloud environment that list is stale within weeks.
- Believing external is proactive and internal is reactive. Both are proactive. That framing appears in widely read comparisons on this topic and it quietly justifies deprioritizing internal scanning.
- Never comparing the two result sets. Attack paths live in the join between them, and nobody sees the path if the reports are read in isolation.
Frequently asked questions
What is the difference between external and internal vulnerability scanning?
External scanning tests internet facing IP addresses and domains from outside the perimeter, showing what a remote attacker sees first. Internal scanning tests hosts behind the firewall, showing what becomes reachable after a foothold. External finds the way in, internal finds how far an intruder gets.
Which should I run first, internal or external?
External. CIS Controls asks for external scans monthly against quarterly for internal, and CISA’s BOD 26-04 makes public exposure the first prioritization variable. Both point the same direction. Add authenticated internal scanning as soon as you can place a connector, because that is where the damage happens.
What is a PCI DSS external vulnerability scan?
It is the quarterly scan required by PCI DSS requirement 11.3.2, covering all internet facing systems in or connected to your cardholder data environment. It must be performed by a PCI SSC listed Approved Scanning Vendor, and any finding scoring CVSS 4.0 or higher is an automatic fail requiring remediation and rescan.
How often should you conduct internal and external vulnerability scans?
PCI DSS requires both at least every three months. CIS Controls asks for external monthly and internal quarterly. Treat those as floors. Continuous external scanning and weekly authenticated internal scans on critical servers is a realistic target, plus rescans after any change.
Can an external vulnerability scan be authenticated?
Yes. Vantage point and credentials are independent choices. Authenticated external scans are common for internet facing web applications and cloud hosts, and they find considerably more than an unauthenticated scan of the same targets. Assuming otherwise is one of the most common errors on this topic.
Do internal vulnerability scans need an ASV?
No. Only the external requirement, PCI DSS 11.3.2, requires a PCI SSC Approved Scanning Vendor. Internal scans under 11.3.1 can be run with any capable tool, though they must be authenticated under 11.3.1.2 and rescanned after significant changes under 11.3.1.3.
Is internal vulnerability scanning about insider threats?
Mostly no. Internal scanning matters because of post compromise lateral movement, not malicious employees. An attacker who gets in through an exposed service or a stolen credential uses exactly what an internal scan would have found. The insider framing understates the case considerably.
Do I still need a penetration test if I run both scans?
Yes. Scanning finds known vulnerabilities one at a time. Penetration testing chains findings into attack paths, tests business logic, and proves impact. PCI DSS puts them in separate requirements, 11.3 and 11.4, precisely because satisfying one does nothing for the other.
Where to start
Run an external scan this week, because it needs nothing installed and it tells you what the internet can already see. Use the result to build the asset list you thought you already had. Then place an internal connector and run an authenticated scan against your servers and network hardware, expecting a larger and less alarming pile of findings. Read the two together, sort by exposure and exploitation evidence rather than severity, and fix the paths where an external exposure sits in front of an internal weakness.
ScanTitan runs both perspectives from one platform, external scanning from the cloud with nothing to install and internal scanning through a lightweight connector that reaches the routers, switches, and printers agent based tools cannot. Findings from both land in one queue, confirmed with request and response evidence and ranked by CVSS, EPSS, and reachability. You can run a free scan on your own ranges to see what the external view returns.
