The external attack surface is everything an attacker can reach from outside your network, such as public websites, APIs, mail servers and login pages. The internal attack surface is what is reachable once someone has a foothold, such as file shares, internal apps and admin tools. Both matter, but they are managed differently.
The shared definition
NIST defines an attack surface as the set of points on the boundary of a system, a system element, or an environment where an attacker can try to enter, cause an effect on, or extract data from it. The word "boundary" is doing the work. Move the boundary and the surface changes.
If you draw the boundary at the internet edge, you get the external surface. If you draw it around a single laptop, a single service or a single SaaS tenant, you get something smaller and more specific. Neither drawing is wrong. They answer different questions.
What sits on each side
External surface examples:
- Public web apps and APIs
- DNS records and the hosts they point to
- Mail gateways and remote access gateways
- Cloud storage and test environments that were left reachable
- Login pages for SaaS tools your staff use
Internal surface examples:
- Internal web apps and dashboards
- Shared drives and wikis
- Service accounts and tokens with broad access
- Admin consoles that only work from the office network
- Developer machines and build systems
Why the split matters
External exposure decides how often you are tried by strangers. Internal exposure decides how far one mistake travels. A phished password on a well-segmented network is a bad day. The same password on a flat network where every service trusts every other is a breach.
This is why a single "attack surface score" is rarely useful. Two companies can have the same number of public hosts and very different internal blast radius.
Who watches which side
External discovery looks at your organisation the way an outsider would: from DNS, certificates, IP ranges and search results, with no credentials. Internal review needs access: asset lists, network maps, identity settings, and conversations with the teams that own things.
Because the work differs, it often falls between teams. The network team owns the edge, the platform team owns cloud accounts, IT owns SaaS, and nobody owns the join between them. Writing down who owns each boundary is a small step that prevents most of the gaps.
A sensible order of work
- Build one list of things you run that face the internet. Assign an owner to each line.
- Remove what nobody can justify.
- Put authentication and logging on what remains.
- Only then map the internal surface, starting with identities and secrets, since those let an intruder move.
Where Safeguard fits
Safeguard is not an external attack surface product. It does cover asset discovery and software side exposure, such as dependency scanning and reachability analysis, which help you understand what your own code brings in. A free scan is available at gold.safeguard.sh/scan.
Quick check
Is the cloud internal or external?
It depends on how each resource is configured. A storage bucket or database with a public address is part of your external surface even if it sits in your own cloud account.
Which should I start with?
Start with the external surface, because it is where unsolicited attempts begin and where the list is easiest to build from public data.
Sources
Last reviewed: 19 October 2026.
