344 Live Hosts Against a 280-Record CMDB

The gap is not automatically 64 missing assets, and the report should not say so. Work the discrepancy in both directions.

Explain the inflation first:

• Load balancer VIPs and shared MACs mean several IPs can be one logical asset. Nine IPs sharing three MACs should collapse to a small number of devices, confirmed with the network team.
• DHCP churn and multi-homing inflate counts; fourteen IPs with changing names need to be matched by MAC, DNS, or switch port rather than by name.
• IPv6 addresses that map to known hosts are duplicates of existing records, not new assets.

Then classify the 61 unmatched into defensible buckets:

1. Known-but-unrecorded (onboarding backlog, recent builds) - confirmed by owner.
2. Shadow IT or lab equipment - needs an owner and a decision.
3. Infrastructure addresses (VIPs, HSRP/VRRP, iLO/iDRAC, printers, OT) that were never intended to be in the server CMDB.
4. Truly unknown - escalate for investigation.

State the evidence for each bucket (DNS PTR, TLS certificate subject, HTTP banner, owner confirmation) rather than asserting it. Finish with a statement of confidence: the reconciled count, the residual unknowns, and the fact that an 11-month reconciliation gap means the CMDB cannot currently be relied on as the inspection population.

No. An unauthenticated SMB guest response is not an authenticated configuration assessment, and reporting those hosts as 'assessed' would overstate coverage in a way that a later auditor will catch.

Diagnose before re-engineering:

• Confirm the cause is Kerberos-only policy and not account lockout, firewall rules, or a scanner credential misconfiguration. Test the same account manually against two of the 58 hosts.
• Check whether the service account is in the right groups, whether SPNs resolve, and whether the scanner is negotiating NTLM when it should use Kerberos.

Options, in order of preference:

1. Reconfigure the scanner for Kerberos authentication and re-scan the 58 hosts within the window.
2. Use a jump host or agent-based collection where Kerberos from the scanner subnet is blocked.
3. Collect exported policy and registry baselines from the platform team, clearly labelled as owner-supplied rather than independently verified.
4. Where none of these work, report the 58 as not assessed, with the reason and the residual risk.

In the report, give three numbers rather than one: hosts discovered, hosts authenticated and assessed, hosts not assessed with cause. Also note that the same authentication issue would blind any future continuous scanning, which is a finding in its own right about the inventory and assessment pipeline.

These are two different problems and should not be merged into one 'incomplete inventory' line.

Ephemeral containers (~30, under six hours):

• A scan-based inventory will structurally never see them; that is a methodology limitation, not a one-off miss.
• The finding should say the inventory method cannot cover workloads whose lifetime is shorter than the scan cadence, and recommend an image registry, orchestration API, or agent-based source of record instead.
• Note the risk consequence: short-lived workloads still consume secrets, mount data, and expose services, so they belong in the population even though they are hard to see.

DHCP churn and changing names:

• Treat identity as MAC plus switch port plus DNS where possible, and record the observation windows. An IP that changes name between nights is one asset seen twice, not two assets.
• Recommend DHCP lease logging be correlated into the CMDB feed so reconciliation becomes continuous rather than annual.

In the report, present a reconciliation table: discovered addresses, de-duplicated devices, matched to CMDB, unmatched, and out-of-method (ephemeral). Then state the residual unknowns explicitly. The aim is a defensible inventory assertion, not the smallest possible gap number.