Choosing the right scan for the question

Why this matters

Domain 2 is a quarter of the exam, and it opens with the most consequential decision in the whole discipline: which kind of scan to run. That choice determines what you can find, what you will miss, and what you might break.

The framing to carry through this domain is that a scan is not a search for truth. It is a question asked in a particular way from a particular vantage point, exactly like the sensor placement in lesson 3. Change the vantage point and you get a different answer — not because one is wrong, but because they asked different things.

The lesson

Credentialed versus uncredentialed

The single largest factor in scan quality.

An uncredentialed scan interacts with a target from outside, with no account. It sees open ports, service banners, certificate details, and whatever responses it can provoke. It infers versions and therefore vulnerabilities.

A credentialed scan logs in and inspects directly: installed packages and patch levels, registry and configuration settings, local accounts and group membership, file versions and permissions.

The differences that matter:

Credentialed scanning finds more and finds it more accurately, so it is the default recommendation, and the exam expects that answer when asked how to reduce false positives or find client-side vulnerabilities.

The counter-consideration is real though: scan credentials are privileged accounts stored in a scanner, which is a valuable target. They should be dedicated, scoped to the minimum required, monitored — and they are exactly the kind of service account lesson 4 warned about.

Uncredentialed scanning still has a job. It answers a different question: what does an attacker without credentials see? That is genuinely useful for external perimeter assessment, and running both gives you both answers.

Agent-based versus network-based

A different axis, often confused with the first.

Network-based scanning reaches out from a scanner to targets. It needs network reachability, produces load on the network, scans on a schedule, and misses anything switched off or absent at the time.

Agent-based scanning installs software on the host, which assesses locally and reports in. It needs no inbound reachability, works for laptops that are rarely on the corporate network, produces results whenever the device is on, and is unaffected by firewalls between scanner and target.

Where each wins:

• Agents are the answer for remote and mobile fleets, for hosts behind restrictive firewalls, for continuous rather than periodic assessment, and for avoiding the scan-window problem entirely.
• Network scanning is the answer for devices that cannot take an agent — printers, network equipment, appliances, industrial systems, medical devices — and for discovering hosts nobody told you about, which agents by definition cannot do.

That last point is the important complement: an agent-only programme has a blind spot exactly the shape of your unmanaged assets, which is the same coverage problem as EDR in lesson 11 and needs the same answer — comparison against an independent inventory.

Most mature programmes run both: agents for the managed estate, network scanning for discovery and for everything that cannot host an agent.

Internal, external and cloud-native scanning

Vantage point again, this time by network position.

External scanning runs from the internet against your public footprint. It answers "what is exposed?", which is the highest-priority question because it is the one attackers ask first. It should cover everything registered to you, including things spun up outside normal process — which requires attack-surface discovery rather than a static list.

Internal scanning runs inside the network and sees far more, because most services are not exposed externally. It answers "what could an attacker reach after gaining a foothold?", which is the lateral-movement question from lesson 3.

Segmentation complicates it: a scanner in one zone cannot see into another, so an internal programme usually needs several scanners or carefully opened paths — and those paths are themselves a risk worth documenting.

Cloud-native assessment is different in kind. Rather than sending packets, it queries the provider's API for configuration: storage permissions, security group rules, identity policies, encryption settings, logging configuration.

This matters because in cloud, misconfiguration outnumbers software vulnerability as a cause of incidents. A public storage bucket is not a CVE; it is a setting. No amount of network scanning finds it, and the scanner that does is reading the control plane — which is the same shift in vantage point that lesson 8 described for detection.

Passive discovery and why it finds different things

Every method above is active: it sends something. Passive discovery watches traffic and infers what exists — which hosts are talking, what software their traffic implies, what protocols and versions are in use.

Its advantages are specific:

• Zero risk to the target. Nothing is sent, so nothing can be destabilised. This is the answer for fragile systems where active scanning is prohibited — industrial control, medical devices, legacy platforms — and the exam does ask.
• Continuous. It sees things as they appear rather than at scan time.
• Finds the unknown. A device that appears for an hour is invisible to a weekly scan and visible to passive monitoring.
• No credentials, no agents, no scheduling.

Its limits are equally specific: it only sees what talks, it infers rather than confirms, it cannot see patch level or configuration, and encryption limits what it can infer — the same constraint as lesson 6, for the same reason.

So passive discovery is an excellent complement and a poor substitute. Its best use is as the independent inventory that everything else gets compared against.

Scan windows, throttling and fragile hosts

The operational half, and the source of most of the friction between security and operations teams.

Active scanning can cause harm. Genuine, documented outcomes include printers producing hundreds of pages of garbage, legacy services crashing on malformed input, industrial controllers halting, and devices rebooting under connection load. "Scanning is read-only" is false: probing is interaction.

Practices that keep it manageable:

• Agree windows with system owners, and honour them. Trust lost here takes a long time to rebuild.
• Throttle — limit concurrent connections and packet rate per host. Slower scans are usually acceptable; outages are not.
• Exclude or specially handle fragile assets, with the exclusion documented and reviewed. An undocumented exclusion becomes a permanent blind spot, which is the same failure as a SIEM tuning exclusion in lesson 10.
• Use safe-check modes that skip tests known to be disruptive.
• Warn before you scan, so an incident during the window is not misattributed — and so your scan does not consume an incident response.
• Watch the network impact, particularly on constrained links.
• Tell the SOC. A scan looks exactly like reconnaissance, and analysts have spent many hours investigating their own colleagues.

The recurring principle: an exclusion is a decision to be blind somewhere, and it is legitimate only if it is written down, owned, dated and compensated for by some other control. Otherwise it is just a gap that nobody remembers choosing.

Topics this lesson owns

• [x] Credentialed versus uncredentialed
• [x] Agent-based versus network-based
• [x] Internal, external and cloud-native scanning
• [x] Passive discovery and why it finds different things
• [x] Scan windows, throttling and fragile hosts