Credentialed or Not, Agent or Agentless: How to Choose the Scan Before You Read the Report
Chris Rees
25+ years in IT · Pluralsight author, 4.6/5 across 2,000+ ratings
Every vulnerability scanner will happily produce a report. Whether the report describes your environment depends on decisions made before the scan started: from where, with what access, how often, and against what. CySA+ Domain 2 opens with those decisions because they determine everything downstream, including the prioritization the rest of the domain is about. Choose badly and you spend the quarter fixing findings that were never real while the real ones sat invisible.
Every scan is a compromise
A vulnerability scan trades four things against each other: coverage (what it can see), accuracy (how many findings are real), intrusiveness (what it might break), and cost (time, bandwidth, licensing, and the people who have to run it). No configuration maximizes all four, and the exam's questions are almost always a scenario that has prioritized one of them and asks which scan type serves it.
Before any of that comes the asset inventory. You cannot scan what you do not know exists, and the finding the exam most likes to describe is the server nobody knew about, discovered because it showed up in a scan of a range someone assumed was empty. Discovery scanning of every range you own, on a schedule, is the first step; everything below assumes it happened.
From where: internal versus external
An external scan runs from outside the perimeter and sees what an internet attacker sees: exposed services, the public web application, the VPN gateway. An internal scan runs from inside and sees what an attacker who has already gotten in, or an insider, can reach. They answer different questions and organizations need both. A stem asking about the attack surface facing the internet wants external; one about lateral movement after a phishing compromise wants internal.
The compliance angle matters here too. PCI DSS, for example, requires quarterly external scans by an approved vendor and internal scans separately, which is a favorite way for the exam to test whether you know that the two are not interchangeable.
With what access: credentialed versus non-credentialed
This is the distinction that carries the most marks, because it changes the report by an order of magnitude.
A non-credentialed scan probes services from the network and infers vulnerabilities from what responds. It sees what an attacker without access sees, which is useful, and it guesses at versions from banners, which produces false positives (the banner says a vulnerable version, but the vendor backported the fix) and false negatives (the vulnerable component is not network-facing at all).
A credentialed scan authenticates to the host and reads the installed software, patch state and configuration directly. It is dramatically more accurate, it finds local vulnerabilities the network can never reveal, and it can check configuration against a benchmark. Its cost is the credential: a privileged account that the scanner holds and that must be vaulted, rotated and monitored, because a scanner's service account is a high-value target.
The exam's pattern: a scenario complaining about false positives wants credentialed scanning. One asking for the attacker's perspective wants non-credentialed. One that describes a compromised scanner account has described why the credential needs the same protection as any other privileged one.
How it runs: agent versus agentless, active versus passive
Agentless scanning runs from a central scanner across the network. It covers anything with an IP address, including devices that cannot run software, and it depends on the network being reachable at scan time, which laptops and remote workers regularly are not. Agent-based scanning installs software on the host that reports in on its own schedule. It follows the device wherever it goes, needs no scanning credentials because it already runs locally, and consumes no network bandwidth in bursts. Its cost is deployment and maintenance, and it cannot cover devices that will not take an agent: network gear, printers, appliances, embedded systems.
The exam's rule of thumb: agents for endpoints that roam, agentless for infrastructure that stays put and cannot host software, and most programs run both.
Active scanning sends traffic to the target and observes the response. It is thorough, and it is intrusive: it can crash fragile services, trip intrusion detection and consume bandwidth. Passive scanning listens to traffic that is already flowing and infers what is there from it. It cannot crash anything and it cannot see what does not talk. Passive is the answer for operational technology, medical devices and anything the scenario describes as fragile or unable to tolerate downtime; active is the answer everywhere the organization can afford to be thorough.
What the frameworks require
Scanning is not always a free choice. PCI DSS dictates scan frequency and, for external scans, who may perform them. CIS Benchmarks define the configuration baseline a credentialed scan checks against. ISO 27001 expects a managed vulnerability process with evidence. A scenario that names one of these is telling you the scan's scope and cadence are not up to the analyst, and the answer will reflect the framework's requirement rather than the analyst's preference.
Scheduling follows the same logic: scan windows are negotiated with the business, critical systems may need maintenance windows, and a scan that took down the order system during peak trading is the exam's way of asking about scope and timing rather than technology.
Reading Nmap without guessing
Objective 2.2 asks you to read output, and Nmap is the tool it reads most. Three port states carry the meaning.
| State | What Nmap saw | What it means |
|---|---|---|
| open | a service accepted the connection | something is listening, and it is reachable |
| closed | the host answered and refused | the host is up, nothing listens on that port, no firewall in the way |
| filtered | no answer, or an ICMP unreachable | a firewall or filter dropped the probe; state unknown |
The trap is reading filtered as safe. It means Nmap could not tell, which is not the same as nothing listening. And closed is the state that proves there is no firewall between you and the host, which is useful information in itself: a range where every port is closed rather than filtered is a range with no packet filtering.
Beyond port states, know what the common options add: service and version detection turns "open 443" into "nginx 1.24," script scanning runs checks against what it found, and OS detection guesses the platform from packet fingerprints. Masscan and similar tools trade Nmap's detail for speed across enormous ranges; they are for discovery, not analysis.
The tool families
| Family | Tools the objective names | What they scan |
|---|---|---|
| Network and host vulnerability | Nessus, OpenVAS, Nuclei | hosts, services, missing patches, configuration |
| Web application | Burp Suite, ZAP, Nikto | the application layer: injection, misconfiguration, known web flaws |
| Cloud and infrastructure code | Trivy, Checkov, ScoutSuite, Prowler | container images, infrastructure-as-code templates, cloud account configuration |
| Breach and attack simulation | Atomic Red Team, Caldera | whether your controls detect known techniques, not whether vulnerabilities exist |
Four stems, chosen
- The report lists 300 critical findings on a server the administrator insists is fully patched, and half cite versions the vendor backported. The scan guessed from banners. Run it credentialed.
- Field engineers' laptops appear in the scan report once a month, when they happen to be in the office. Agentless scanning cannot reach a roaming device. Deploy agents.
- A scan of the plant network took a programmable controller offline for two hours. Active probing against fragile equipment. Switch to passive monitoring for the OT segment and scope active scans away from it.
- The compliance team needs quarterly evidence of external exposure and separate evidence of internal patch state. Two scan types, two reports, on a schedule the framework sets, not the analyst.
The last row of the tool table is the one candidates misplace. Breach and attack simulation does not find vulnerabilities; it runs attacker techniques safely to see whether your detection fires. A scenario asking whether the SOC would notice a specific technique is a BAS question. One asking whether a host is missing a patch is a scanner question. And the cloud row exists because a misconfigured storage bucket is not a missing patch: it is a configuration finding, and it takes a configuration scanner to find it.
Key takeaways
- Scan choice is a trade among coverage, accuracy, intrusiveness and cost. The stem prioritizes one; pick the scan that serves it. Inventory first, always.
- External sees the internet's view; internal sees the insider's. Compliance frameworks often require both, separately.
- Credentialed scans read the truth from inside and cut false positives dramatically. The scanner's account is privileged and needs vaulting.
- Agents for roaming endpoints, agentless for fixed infrastructure; passive for anything fragile. Active scanning can crash what it touches.
- Nmap: open means listening, closed means no firewall, filtered means unknown. BAS tests detection, scanners find vulnerabilities, cloud tools find misconfiguration.
Scan selection and output analysis are objectives 2.1 and 2.2 of CySA+ Domain 2, Vulnerability Management, 26% of the exam, and they feed the CVSS, EPSS and KEV prioritization that objective 2.3 tests and the wider vulnerability management lifecycle. Work all 26 topics with our CySA+ Domain 2 study guide.
#CySA #CS0004 #VulnerabilityManagement #Nmap #Nessus #CredentialedScan #VulnerabilityScanning #BlueTeam #CompTIA #CyberSecurity
Turn 61,000 findings into a plan
Vulnerability Management is the second-largest domain on CySA+ CS0-004. Work all 26 topics across the four objectives, from asset inventory and scan selection through reading real Nmap, Nessus and Nikto output line by line, with 80 practice questions.
- Find your gapsA free readiness quiz scores you domain by domain.
- Study what's on the testWork through every objective, with practice questions.
- Book it with confidenceSchedule the exam when you're scoring well in every domain.
Read a free excerpt from CySA+ Domain 2: Vulnerability Management
Keep reading
Declare, Escalate, Report: Incident Communication, the After Action Report, and the SOC Metrics CySA+ Tests
A technically perfect incident response can still end as a crisis if the communication goes wrong, and CySA+ objective 4.2 is where the exam tests that. Incident declaration and why it starts clocks, the escalation ladder, who gets told in what order and why legal goes first, the executive summary as a discipline, the anatomy of the incident report, root cause and lessons learned, and the eight SOC metrics with the way each one can be gamed.
Read CySA+ deep divesWhy the Patch Never Ships: Inhibitors to Remediation, and the Reports That Get Vulnerabilities Fixed
Finding a vulnerability is the cheap part. CySA+ Domain 4 is about the harder half: turning findings into decisions. Scan reports versus risk scorecards, the six inhibitors to remediation the exam names and the answer to each, action plans with owners and dependencies, the metrics that show a program improving, and the incident communication discipline that decides who hears what, when.
Read CySA+ deep divesIsolate, Segment, or Remove: Containment, Eradication, and Recovery Techniques the Way CySA+ Scenarios Test Them
At 04:12 the alert says mass file modification and someone's hand is already on the power button. CySA+ objective 3.3 is the largest in Domain 3 and it is tested as scenarios: which technique, in which phase, and why. Evidence acquisition and chain of custody, isolate versus segment versus remove, reimaging versus patching, restoring from backup, and the scoping and impact questions that decide the answer.
ReadFollow Skillthropic
Keep learning between study sessions
The same exam-focused teaching, in smaller pieces, wherever you scroll.
Enjoyed this? Get the AI security news that matters.
Join The AI Security Brief for the top AI security news, plus what's important to the C-suite. Free, straight to your inbox.
No spam. Unsubscribe anytime.