After a scan-account password rotation, critical findings on 40 hosts fell by two-thirds overnight; what most likely happened, and how should scan credentials be run?
answer
- good news that is too good
- a failed login does not stop the scan
- per-host authentication status
- rotate through one vault
basics
~20 sThe scanner most likely stopped logging in: a failed authenticated login degrades to remote checks, which find far less, so the drop is lost visibility, not remediation. Hold scan credentials in a vault, rotate through it, and alert on per-host authentication status.
solid answer
~40 sA credentialed scan whose login fails usually carries on with the checks it can run from the network and reports fewer findings, which reads as good news. Authentication can also half-succeed: the account logs in but lacks the privilege local checks need, giving false negatives and some false positives. So treat **per-host authentication status** as a first-class result: alert when the authenticated share drops, and never compare finding counts across runs without it. Run the credentials themselves as privileged secrets: dedicated scan accounts per scope, least privilege with only the escalation the checks require, held in a **vault** the scanner reads at scan time so rotation happens in one place, and monitored so a login outside scan windows raises an alert.
go deeper
Recall that an authenticated scan whose login fails usually keeps running with remote checks only, so a sudden fall in findings can mean lost access rather than fixed hosts.
Explain the three authentication outcomes, including logged in but under-privileged, and how each changes the results, then name where a scanner reports per-host authentication status.
Show the operating model: alerting on the authenticated share, trend reports gated on authentication, scoped least-privilege accounts, a vault read at scan time, and lockout-aware credential mapping.
Weigh scan accuracy against the blast radius of an account that can log into everything, and decide how scoping, escalation rules and monitoring keep that identity from becoming the estate's weakest point.
## What a failed login does to the results An **authenticated** (credentialed) scan logs into each host and reads its installed software and configuration directly. When the login fails, most scanners do not abort the host. They fall back to the checks they can run from the network, which see much less, and the scan completes normally. The report then shows fewer findings, often far fewer, and nothing in the headline numbers says why. In the scenario, the scan account's password was rotated in the directory but not in the scanner's configuration. Every login failed, every host fell back to remote checks, and the dashboard celebrated a two-thirds drop in critical findings. Nothing was fixed; the programme simply stopped looking. ## Three authentication outcomes | Outcome | What the scanner can do | Effect on results | |---|---|---| | **Passed** | Log in and read what local checks need | Most complete and accurate result | | **Passed, insufficient privilege** | Log in but cannot read some files, settings or commands | Missing findings (false negatives) and some wrong ones (false positives) | | **Failed** | Cannot log in; remote checks only | Large silent drop in findings | Scanners generally report this per host, as a status in the scan results or as informational findings about authentication. The problem is that few people look at it unless it is wired into alerting. ## Detecting it 1. **Track the authenticated share** per scan and per segment: hosts where authentication passed, over hosts reached. Alert on a drop between runs. 2. **Separate the insufficient-privilege state** from both passed and failed. It is the hardest to notice because the login itself succeeded. 3. **Gate trend reports** on authentication: a finding-count comparison between two runs is only valid for hosts authenticated in both. 4. **Correlate with change events**: a password rotation, a new host-hardening baseline or a directory policy change should trigger a check of the next scan's authentication status. ## Running scan credentials as privileged secrets A scan account is among the most powerful identities in the estate: it logs into everything. Run it accordingly. - **Dedicated accounts, scoped.** Separate accounts per zone or platform limit what one stolen credential opens. Avoid reusing an all-powerful administrator account. - **Least privilege, found empirically.** Start without escalation, record which commands or reads fail, and grant escalation for exactly those. Some platforms still need administrative read access for accurate local checks; grant it deliberately, not by default. - **A vault, read at scan time.** Many scanners can fetch credentials from a secrets vault when a scan starts. Rotation then happens once, in the vault, and the scanner never holds a stale copy. - **Mind lockout policies.** A scan that tries several stored credentials in turn generates failed logins on each host, which can lock accounts or trigger brute-force alerts. Map the right credential to each target instead of trying a list. - **Monitor the account.** Logins from the scan account outside scan windows, or from anywhere other than the scanners, are worth an alert. - **Protect the transport.** Prefer authentication methods that do not expose the secret to the target, and avoid plaintext protocols for login. ## The rotation incident, done right A rotation that cannot silently break scanning follows a short sequence: 1. Rotate the secret in the vault, which the scanner reads at scan time. 2. Run a small authenticated scan against a handful of representative hosts per platform. 3. Confirm authentication passed with full privilege on all of them. 4. Only then let the full schedule run, with the authenticated-share alert armed. When rotation goes through the vault, the scanner picks up the new secret at the next scan and nothing breaks. If a rotation does break authentication, the authenticated-share alert fires on the first affected run, the drop in findings is annotated as lost visibility, and nobody reports it upward as progress. The difference between the two outcomes is not the scanner; it is whether authentication status was treated as part of the result.
- Why is trying several stored credentials against each host risky?Every wrong credential is a failed login on the target. With a list of several, a scan can lock accounts under the lockout policy or look like password guessing to monitoring. Map the right credential to each target or scope, so each host sees one attempt with the credential meant for it.
- How narrow can a scan account's privilege be made without losing accuracy?Narrower than full administrator in many cases. Run with no escalation first, record which commands and reads fail, then allow escalation for exactly those. Re-check after scanner check-set updates, since new checks may need new reads. Where a platform still needs administrative read access, grant it knowingly and compensate with scoping and monitoring.
saying these in an interview costs you the question
- Fewer findings after a password rotation means patches landed.
- If the login fails, the scanner always aborts the host and reports an error.
- A successful login means the scan saw everything on the host.
- One all-powerful administrator account everywhere is the best scan credential.
- Storing scan passwords in the scan configuration is fine because the scanner is internal.