●cybersecurity

How to Find the Devices Your Network Scanner Never Sees

AR by Anneliese Roth published 27.08.2026 read time 11 min updated 01.09

Your discovery scan returned 1,240 devices. The number is wrong, and it is wrong in ways you can name, predict and correct. A technical account of why scanners miss things (firewalls, sleep states, address families, stale target lists) and the reconciliation method that finds the difference.

Nearly everything written about unknown devices on corporate networks blames people. Shadow IT. BYOD. Hybrid working. A lack of policy. None of that is untrue, and none of it is much use on a Monday morning, because it doesn’t tell you where to look.

Most of the devices your scanner misses are missed for reasons that have nothing to do with anyone’s behaviour. They are missed because of a firewall default that Microsoft recommends you keep, a sleep state working exactly as designed, an address space too large to sweep, or a target list that nobody has edited since the Bristol office opened.

Those are engineering problems, which is good news: engineering problems have addresses. What follows is the mechanism-by-mechanism version, with sources, and then a method for finding what you’re missing without buying anything.

The distinction that organises everything else

There are two failure modes and they need entirely different fixes.

The device was never in the scan’s target range. No amount of probe tuning will find it. You have to change where you look.

The device was in range and didn’t answer. It is reachable. Your probe was refused, ignored, or arrived while the machine was asleep.

Conflating these is why most inventory work stalls: teams tune probes at a problem that is actually a missing subnet, or add subnets to a problem that is actually a host firewall. Sort every gap into one of these two buckets before you do anything else.

Failure mode one: in range, and it didn’t answer

Microsoft’s documented default for Windows Defender Firewall is to “block all incoming traffic, unless solicited or matching a rule,” while allowing all outgoing traffic. That is the correct posture, and Microsoft explicitly recommends keeping it. It also means a properly hardened Windows host is under no obligation whatsoever to answer an unsolicited ping or a probe on a port it does not serve.

Nmap’s own documentation says the same thing from the other side. Because “many hosts and firewalls now block those packets,” ICMP-only sweeps are rarely reliable, and Nmap’s remedies are to probe multiple ports with varied TCP flag combinations, or to skip host discovery entirely with -Pn and treat every address in range as live, which is slower and noisier but honest about what a non-response actually means.

The conclusion is uncomfortable and worth stating plainly: a non-response is not evidence of absence. If your inventory is built from the set of hosts that answered, it is built through a filter you never intended to apply, and the filter is strongest on exactly the machines that are best configured.

The laptop was asleep, and your scanner has no way to tell

Microsoft’s Modern Standby documentation describes adaptive connected standby quiescing network connectivity during sleep unless a background task specifically requires it, the default behaviour since Windows 10 version 2004. A laptop asleep in a bag at two in the morning is, at the network layer, indistinguishable from a laptop that no longer exists.

Two in the morning is, of course, when your discovery scan runs, because that is when it disrupts nobody. So anything you learn from a nightly scan is systematically biased toward the machines that are on at night: servers, desks left logged in, printers, the odd forgotten test box. Which is close to the inverse of the population you are actually worried about.

Should you actively scan OT? The honest answer is that it’s contested

“Never actively scan operational technology” is repeated across this field as settled fact. It is not settled, and it is worth being straight about that.

The common practice within OT environments is to avoid using active scanning approaches because of the risk of degradation or disruption of service.

Tenable, OT scanning documentation

Against that, runZero has published results from testing at the National Renewable Energy Laboratory’s CEC-A facility reporting no negative performance impact from active scanning of operational technology.

Both of these are vendors describing the fit of their own products. Tenable sells passive OT monitoring; runZero’s publication concerns runZero. Neither is independent peer-reviewed work, and I could not find a specific CISA or regulatory advisory that says “do not scan,” despite that claim being widely attributed. The honest position is that the risk is real, poorly quantified in public, and enormously dependent on the specific devices in front of you.

Treat caution as a default you may justify departing from, not as physics. If you do depart from it, do it in a maintenance window with the engineer who owns the plant in the room. What you should not do is quietly leave the OT segment out of scope and then describe the inventory as complete.

Failure mode two: it was never in range at all

The management network, which is separate on purpose

Baseboard management controllers, meaning iDRAC, iLO, IPMI and their equivalents, sit on dedicated NICs and a separate management VLAN, deliberately not routable from user segments. Which means they are usually not in your scan target list either.

These are full computers. They have their own operating system, their own network stack, their own credentials, and they keep running when the host is powered off. Excluded from discovery by design, and very rarely added back deliberately.

The target list is a document, and documents rot

Your scanner scans what you told it to scan. That list was written when the network had a particular shape. Since then: a new site, a merged subnet from an acquisition, a VLAN for the warehouse kit, a guest network somebody stood up for an event in 2024 and left running.

Nothing in the tool will tell you the list is incomplete. A subnet that is not scanned does not return an error. It returns nothing at all, and nothing looks exactly like a clean result.

IPv6, where sweeping simply does not work

RFC 7707, the IETF’s own document on network reconnaissance in IPv6 networks, puts the arithmetic plainly: brute-forcing a single /64 subnet means roughly 1.8 × 10^19 addresses, against about 65,000 for a typical IPv4 site. That is not slow. It is infeasible.

What is striking is the RFC’s list of alternatives, because every one of them is passive or protocol-assisted rather than a sweep: walking ip6.arpa reverse DNS, enumerating AAAA records, querying the all-nodes multicast address ff02::1, reading neighbour caches and logs, and mDNS/DNS-SD.

The standards body’s answer to “how do I discover hosts on IPv6” is, in effect, don’t sweep, read your logs. That is the whole argument of this article, written down in 2015. And if you have deployed anything modern, you have dual-stack hosts whether or not you meant to, which means an IPv4-only sweep is inspecting half the network.

NAT: one answer can conceal an entire network

A scanner probing an address behind a NAT gateway gets exactly one response, from the gateway. If somebody has plugged a consumer router into a wall port, the classic “I needed more ports” incident, then everything behind it appears in your inventory as a single host. That is RFC 3022 behaviour working precisely as specified, which is what makes it so easy to miss.

The devices that never touch your network at all

The remote worker on a split-tunnel VPN or a SASE service whose laptop reaches Microsoft 365 directly and routes only a narrow set of internal ranges through your infrastructure. The 4G-connected sensor at a remote site. The contractor’s machine on their own broadband. The tablet in the van.

There is no scan configuration that finds these, because there is no path from your scanner to them. They appear in identity and endpoint telemetry, or they do not appear anywhere.

Assets with a shorter life than your scan interval

A container that runs for four minutes cannot be found by a scan that runs every four hours. A scaling group that adds and removes instances between windows leaves no trace in the scan record at all, though it does leave a trace in the cloud provider’s API, and, if those workloads count toward your licensing, on your bill.

And then: even when you see it, you may not know what it is

There is a third problem sitting underneath both failure modes, and it is an identity problem rather than a discovery one.

Apple’s Private Wi-Fi Address presents a different MAC address to each network by default. On WPA2 and WPA3 networks that address is stable per network; on open networks it rotates. Android has used a per-network randomised MAC by default since Android 10, generated persistently per network profile, with Android 12 and later re-randomising under certain conditions. Windows exposes the same feature both globally and per-network, though Microsoft’s own documentation does not state the out-of-the-box default, so check that against your own fleet rather than trusting a blog post, this one included.

The consequence for an inventory keyed on MAC address is specific: a laptop that touches the corporate SSID, the guest SSID and a home network can appear as three devices, while a device that re-randomises appears as a brand new one and takes its history with it. You get double-counting on one side and lost continuity on the other. Both look like discovery failures. Neither is.

The method: find the difference set

Every guide on this subject ends with the same advice: use NAC and scanning and wireless intrusion detection and a baseline. That is a list of tools running in parallel, which is not a technique.

The technique that actually surfaces unknown devices is subtraction. Pick a window; thirty days is a sensible start. Pull a device list from every source you already own. Normalise them. Take the union. Then subtract what your scan found.

What remains is your blind-spot list, and the source each item came from tells you which failure mode you are in.

Sources to reconcile against, and what each one can’t tell you

Source	Sees what a scan doesn’t	Its own limitation
DHCP server logs	Every device that took a lease in the window, including ones asleep or offline when the scan ran	Static-IP devices never appear; reused leases muddy the history
Switch CAM and ARP tables	Layer-2 presence regardless of host firewall posture, and the physical port it is on	Point-in-time, per switch; doesn’t cross routed segments; one entry for everything behind a NAT
802.1X / RADIUS logs	Every device that authenticated, with certificate or user identity attached	Only covers segments actually enforcing it, and IoT and legacy VLANs are usually exempted, which is where the interesting devices live
NetFlow / sFlow	Anything generating traffic, including hosts that refused your inbound probe but talk outbound freely	Conversations, not a clean inventory; needs a collector and enrichment
DNS query logs	Devices making lookups, including IPv6-only and roaming hosts, which is the IETF’s own recommended approach	Misses devices configured to use external resolvers directly
EDR and MDM	Deep per-host detail for everything enrolled	Structurally blind to unenrolled devices, which is the entire population in question; use it as the “known” side of the subtraction
Identity provider sign-in logs	Devices authenticating to SaaS from anywhere, which catches the VPN-only and fully remote population no LAN scan can reach	No network context: no MAC, no actionable IP, no switch port
Cloud provider inventory APIs	Instances and containers that existed and vanished between scans	Only the accounts you point it at; a shadow subscription is invisible here too

The sequence, in order of return

Fix the target range before you tune anything. Reconcile the scanner’s target list against your routing tables and your DHCP or IPAM scope list. Missing subnets are consistently the cheapest and largest finding in the whole exercise, and they cost nothing but an afternoon.

Stop treating silence as absence. Run discovery with multiple probe types across varied ports, and where you are confident of the range, with host discovery disabled altogether so that unresponsive hosts are still examined.

Scan at more than one time of day. A midday pass and a 2am pass return meaningfully different populations. The difference between them is your mobile fleet, and it is free to measure.

Add the management network deliberately, in its own scope, with its own credentials, and with someone accountable for the result.

Key on something better than a MAC address. A certificate, a machine identity, a serial number from an authenticated check, or a composite of several. MAC alone stopped being a reliable identifier some years ago.

Reconcile monthly, not annually. The value is in the trend of the difference set rather than its absolute size on any given day. A number that is growing tells you something an audit never will.

Then comes the part that is genuinely harder than the technical work. Once you have a list of things you did not know about, discovery stops and triage begins: establishing what each device is, whether it is authorised, who owns it, and what to do about the ones nobody will claim. Having a documented process for investigating and containing rogue devices written down before you need it is worth more than it sounds, because the awkward cases are rarely technical: the marketing team’s demo kit, the contractor’s laptop, the ageing print server that runs payroll and cannot be touched until Thursday.

Worth resisting

Most writing in this area leads with the intruder: the attacker’s implant, the malicious rogue access point. Those exist. But in an organisation of a few thousand devices, the overwhelming majority of unknown devices are mundane: a personal phone on the guest SSID, a forgotten IoT sensor, an unmanaged switch under a desk, a contractor’s laptop. Leading with the hacker framing is not just alarmist, it is inaccurate about the base rate, and it sends teams looking for the wrong thing.

The actual point

A scanner is not an inventory. It is one instrument with a known, documentable set of blind spots: hosts that will not answer, addresses it was never told about, an address family it cannot sweep, machines that were asleep, and a network layer that hides whole subnets behind a single reply.

None of that is a reason to distrust the tool. It is a reason to stop treating its output as the answer and start treating it as one column in a reconciliation. The devices you are worried about are, almost by definition, the ones that do not show up in the place you are looking.

So look somewhere else as well. And subtract.

Method and limitations

Technical behaviours described here were verified against vendor and standards documentation rather than tested in a lab; specific behaviour will vary by version and configuration, and the Windows MAC randomisation default in particular could not be confirmed from Microsoft’s own documentation and is flagged as such in the text. The OT scanning section describes a genuine disagreement between two vendor sources and should not be read as a recommendation either way. No vendor commissioned or reviewed this article.