An external vulnerability scan runs from outside your network and shows what an internet attacker can see and reach. An internal scan runs from inside and shows weaknesses an attacker would find after getting a foothold. They answer different questions, and NIST guidance says testing from both viewpoints is important.
Definitions
NIST describes vulnerability scanning as a technique used to identify hosts and host attributes and the vulnerabilities associated with them. The viewpoint is the part that changes.
- External scan: run from outside the security perimeter, usually from the internet. It sees only what firewalls and routers let through.
- Internal scan: run from the internal network, often with the access of an ordinary user or a trusted insider.
NIST SP 800-115 notes that internal scanning usually uncovers more vulnerabilities than external scanning, because perimeter devices block traffic from outside and limit an external scanner to the ports allowed through.
Side by side
| Question | External scan | Internal scan |
|---|---|---|
| Where does it run? | Outside the perimeter | Inside the network |
| What does it model? | An anonymous internet attacker | An insider, or an attacker who got in |
| What does it see? | Only ports and services that are reachable | Most hosts, services and configurations |
| Typical count of findings | Fewer | More |
| Good for | Knowing your internet exposure | Knowing how far a foothold could spread |
Which should you run first?
Start external. It is the smaller list, and it covers what anyone can reach today. NIST also suggests that when both are done by the same assessors, external work goes first so the assessors do not gain insider knowledge that a real outsider would lack.
Then add internal scanning once the external list is under control. Internal scans find patch gaps and misconfigurations on systems that were never meant to face the internet but matter once someone is inside.
Steps to set up both
- List what you expect to be internet facing: domains, IP ranges, cloud load balancers.
- Run an external scan against that list and compare it to what the scan actually found. Surprises are the point.
- Fix or close anything that should not be reachable.
- Run an internal scan from a network segment that mirrors a normal user, then repeat from a more privileged segment if you need to.
- Triage by exposure and exploitability, not by raw count.
- Schedule both, and rerun after significant network changes.
Where application dependencies fit
Network scans look at hosts and services. They do not read your application's dependency tree. Libraries inside an application need a software composition scan, which works from your code, lockfiles or images rather than from the network. Treat network scans and dependency scans as complements.
Try it yourself
Open the demo and look at how findings are grouped and prioritized in one view, then think about which of those would be visible from the internet and which only from inside.
Click through it at your own pace, or open it full screen.
Quick check
Is an external scan enough?
Not on its own. It shows what is exposed to the internet, but it will miss the weaknesses that matter after an attacker or malicious insider is inside the network.
Why does an internal scan usually find more?
Perimeter firewalls block most traffic from outside, so an external scanner can only probe the ports that are allowed through. Inside the perimeter, far more hosts and services are reachable.
Safeguard covers the application side of this picture with SBOM and dependency scanning, reachability analysis and policy gates, and you can try a free scan of a repository to see your dependency exposure.
Sources
- NIST SP 800-115, Technical Guide to Information Security Testing and Assessment
- NIST SP 800-115 full text (PDF)
- NIST glossary: vulnerability scanning
Last reviewed: 19 October 2026.
