Authenticated vs unauthenticated scanning

Two scanners point at the same server and return different findings. Neither is broken. An unauthenticated scan sees what the host tells a stranger; an authenticated one reads the package list. They are measuring different things, and most arguments about scanner accuracy are really arguments about which question was asked.

What an unauthenticated scan actually knows

It connects to ports and reads what comes back. Service detection infers a product and version from the banner, the TLS certificate, response headers and protocol quirks, and that inference is then matched against CVE data.

That gives you two things nothing else does. First, ground truth on exposure: if the scanner reached port 5432 from the internet, so can anyone, and no firewall diagram claiming otherwise survives that. Second, the attacker's own view — what an unauthenticated stranger can enumerate before they have any access at all.

What it cannot know is everything the host does not announce. A vulnerable library used by an application behind a reverse proxy, a package installed but not listening, a configuration weakness with no wire signature — invisible.

The backporting problem

The most common false positive in unauthenticated scanning has one cause. Distribution maintainers backport security fixes into the version they ship rather than bumping the version number. A Debian or RHEL package will report itself as an old release long after the specific vulnerability was patched in it. The banner is honest, the CVE match is arithmetically correct, and the finding is still wrong.

The mirror error runs the other way: a banner that has been suppressed or rewritten produces no finding for a service that is genuinely vulnerable. Absence of a banner is absence of evidence.

Both are treatable. Confirm a suspected backport against the distribution's security tracker before scheduling emergency work, and treat a scanner's version inference as a lead rather than a verdict — which is the same discipline behind why a CVSS score alone is not a priority order.

What authenticated scanning buys and costs

Log in, and the guessing stops. An authenticated scan reads the installed package inventory with exact versions, sees software that is not listening on anything, and can check configuration — password policy, service settings, file permissions — that no external probe reaches.

The cost is access. You need credentials on every scanned host, distributed and rotated, and the account that can read all of that is a high-value target by construction. A scanner with domain-wide credentials is infrastructure that needs the same protection as your identity provider, because compromising it returns both a map and a key.

	Unauthenticated	Authenticated
Answers	What can a stranger reach?	What is installed here?
Version accuracy	Inferred from banners	Read from the package manager
Sees non-listening software	No	Yes
Sees configuration weaknesses	Rarely	Yes
Proves exposure	Yes	No
Needs credentials on the host	No	Yes, on every host
Typical false positive	Backported fix read as vulnerable	Few, but scope is what you gave it

Note the row that gets forgotten: an authenticated scan does not prove reachability. It will report a vulnerable package on a host with no route from the internet at exactly the same severity as one on your public gateway. That is why an internal-only programme tends to produce a large undifferentiated backlog — everything is a finding and nothing is a priority.

Use them for the jobs they do

Run unauthenticated scans from outside, continuously, against everything that resolves publicly. That is the exposure question, it changes without anyone deploying, and it is the only view that matches what an attacker starts with.

Run authenticated scans on the estate you control, on a slower cadence, to get accurate inventory and to settle the version questions the external scan can only guess at. Where the two disagree about a version, the authenticated answer wins. Where they disagree about whether something is reachable, the unauthenticated one does.

CyberSpec runs external, unauthenticated scans — nmap with service detection, correlated to CVEs through the vulners NSE script, producing findings with CVSS scores and vectors, CVE and CWE references, and host:port detail. No credentials on your hosts, because none are needed for the question it answers. Ownership of each asset is verified by DNS TXT record or a well-known file before anything is scanned. See network scanning and vulnerability management.

If you only have budget or appetite for one, start outside. The findings an external scan misses are ones an attacker also has to work for; the ones it catches are already sitting in the open.