NetFlow and sFlow extend device visibility beyond SPAN gaps

At a glance

What this is: This is a device visibility analysis showing that SPAN alone can miss parts of the network, and that NetFlow and sFlow help close those gaps by adding complementary traffic sources.

Why it matters: It matters because identity, asset, and segmentation decisions depend on a complete view of what devices exist and what they communicate with, especially in IoT, OT, and IoMT environments.

Context

Device visibility is the foundation for governing connected assets, but passive monitoring based on a single mirrored traffic source rarely captures the full estate. When SPAN capacity, session limits, or topology leave parts of the network unseen, inventory quality drops and downstream segmentation or risk analysis starts from partial evidence rather than operational reality.

For IoT, OT, and IoMT programmes, that visibility gap is also an identity problem in practice. If teams cannot reliably see what devices are present and what they talk to, they cannot govern device trust, access boundaries, or exposure with confidence. The article’s core point is that no single traffic source is enough when the environment is heterogeneous and distributed.

Key questions

Q: What breaks when device visibility depends only on SPAN traffic?

A: When SPAN is the only discovery source, coverage depends on mirror capacity, session limits, and topology rather than on the actual network estate. That means devices, subnets, and conversations outside the mirrored path never appear in inventory. The result is not just less telemetry, but weaker segmentation decisions and unreliable exposure analysis.

Q: Why do incomplete visibility gaps matter for segmentation and risk decisions?

A: Because segmentation policy and exposure analysis both assume the inventory is materially complete. If the underlying device list is partial, teams may believe a segment is isolated or a device is low risk when traffic evidence has simply not been captured. That creates governance drift between intended control and observed network behaviour.

Q: How do NetFlow and sFlow compare as visibility sources?

A: NetFlow gives flow-level accounting, which is useful when completeness and conversation mapping matter. sFlow uses sampled packets and counters, which scales better on busy links and can provide richer sample context. The practical choice is usually not either-or, but which source closes the specific gap left by SPAN in that environment.

Q: How should teams build a reliable inventory for IoT and OT networks?

A: They should combine mirrored traffic, flow telemetry, and safe active checks where authorised, then compare the resulting inventory against the segmentation model and known device classes. In connected-device environments, a single observation method rarely covers every segment, so resilient inventory depends on overlapping evidence rather than one sensor type.

Technical breakdown

Why SPAN-based discovery leaves visibility gaps

SPAN works by copying traffic from selected switch ports or VLANs to a monitoring port so a collector can inspect it. The limitation is structural: mirrored traffic depends on switch capacity, session limits, prioritisation, and topology. If a segment is not spanned, or traffic crosses switches outside the mirror path, the collector never sees it. That means passive discovery can build a useful baseline while still missing devices, IP ranges, and conversations. In practice, the blind spot is not malicious concealment but incomplete reach of the observation method.

Practical implication: Treat SPAN as a baseline source, not as complete coverage, and validate whether the mirrored paths actually reach every network segment you need to govern.

How NetFlow improves flow-level device inventory

NetFlow does not copy packets. It exports flow records that summarise who talked to whom, on which ports, over which protocol, and at what volume. That makes it valuable where full packet inspection is not possible or where the question is discovery rather than content analysis. Because it is generated by switches and routers already handling the traffic, it can surface IPs, subnets, and conversation patterns that SPAN may miss. The trade-off is depth for breadth, but for inventory creation, breadth often matters more than payload detail.

Practical implication: Use NetFlow to discover unseen hosts and communication paths before relying on packet-level tools for deeper investigation.

Why sFlow scales where exhaustive capture does not

sFlow samples packets and interface counters instead of accounting for every packet. That design reduces load on network devices and makes it practical on high-speed links where exhaustive capture would be too costly. Because each sample can include headers and payload, it can still provide richer context than pure metadata, even though it is not a full record of every conversation. The point is not perfect fidelity. The point is enough signal, at scale, to keep inventory and exposure analysis current across busy environments.

Practical implication: Use sFlow where link speed or switch overhead makes full flow accounting impractical, then correlate it with other sources to recover breadth and context.

Threat narrative

Attacker objective: Exploit blind spots in network visibility so uncovered devices and conversations evade monitoring and downstream risk controls.

1. Entry occurs when visibility depends on a single mirrored traffic source that does not cover the full switching topology, leaving parts of the environment unobserved.
2. Escalation happens when incomplete discovery produces an asset inventory that undercounts devices, subnets, and communication paths, which weakens segmentation decisions and exposure analysis.
3. Impact is a governance blind spot: teams make control and risk decisions from partial network evidence rather than from the network as it actually operates.

Breaches seen in the wild

• Verkada camera breach 2021: Admin credentials on Verkada's exposed Jenkins support server let hackers into a support interface and customer cameras at 97 customers.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Network visibility is now an identity governance problem as much as a monitoring problem. Connected devices, workloads, and controllers all depend on knowing what exists before access, segmentation, or risk scoring can be credible. If discovery misses devices or conversations, the governance model is already operating on an incomplete asset set, which weakens every downstream control that assumes inventory accuracy.

SPAN-only discovery creates a visibility trust gap. The problem is not that mirrored traffic is useless, but that it is structurally bounded by switch capacity and topology. In environments with IoT, OT, and IoMT assets, that means the absence of evidence can easily be a failure of observation rather than a real absence of risk. Practitioners should treat coverage as a control requirement, not a convenience.

Flow telemetry changes the question from 'can we see packets?' to 'can we govern communication patterns?' NetFlow and sFlow do not replace packet analysis, but they make device inventory and exposure analysis more resilient to routing, scale, and sampling constraints. That is a governance upgrade because segmentation and attack-path analysis only work when the inventory behind them is materially complete.

Multi-source telemetry is the right model for modern connected estates. A single sensor type rarely fits every segment, especially when some traffic is high-volume and some devices are quiet or intermittently active. The practical implication is to build inventory from overlapping evidence sources so one blind spot does not become the programme’s assumption.

Visibility completeness: the real control objective is not collection volume but whether the inventory reflects the network that actually exists. That concept matters because teams often optimise for more telemetry without checking whether the remaining blind spots are the ones that matter most. Practitioners should measure discovery completeness by coverage quality, not by the number of collectors deployed.

From our research library:

• Only 5.7% of organisations have full visibility into their service accounts, according to the Ultimate Guide to NHIs.
• Read next: Identity Visibility and Intelligence Platforms (IVIP) Guide

What this signals

Coverage quality, not sensor count, is the metric that matters. Teams should stop treating SPAN as proof of discovery completeness and start checking whether key subnets, device classes, and inter-switch paths are actually represented. In connected-device programmes, one missed segment can distort segmentation decisions across the rest of the estate.

Multi-source telemetry reduces the risk of visibility drift. NetFlow and sFlow do not solve everything, but they give security teams a second and third view of the same environment, which makes blind spots easier to detect. That matters when inventory feeds attack-path analysis, exposure prioritisation, and device trust decisions.

Visibility completeness: the operational question is whether your inventory reflects the network that exists, not whether your tooling collected more data. The NHI lesson is the same one that applies to machine identity governance: unmanaged blind spots usually start as discovery problems.

For practitioners

• Broaden discovery beyond SPAN-only monitoring Add NetFlow and sFlow as complementary discovery inputs wherever switches and routers support them, so inventory does not depend on a single mirrored path.
• Validate network coverage by segment Map which subnets, switch paths, and high-value device classes are actually represented in your current visibility stack, then identify the areas still dependent on indirect inference.
• Use flow telemetry to verify segmentation assumptions Compare observed flow records against intended segmentation policy to spot communication paths that the mirrored traffic view misses.
• Correlate passive and active discovery carefully Where devices can tolerate it and the organisation authorises it, combine passive traffic visibility with safe active queries so inferred attributes can be confirmed.

Key takeaways

• SPAN-only discovery can leave entire devices, subnets, and conversations outside the inventory, which weakens segmentation and exposure analysis.
• NetFlow and sFlow improve coverage by adding flow-level and sampled packet evidence from infrastructure that already generates it.
• Connected-device programmes need overlapping visibility sources because the accuracy of downstream governance depends on what the network sensors actually see.

Key terms

• Span: A span is one discrete operation inside a trace, such as a retrieval query, prompt assembly step, or model call. Spans make it possible to pinpoint which part of an AI workflow consumed time, introduced error, or passed bad context to the next stage.
• NetFlow: NetFlow is a network traffic export format that records who talked to whom, when, and how much data moved. Defenders use it to spot command-and-control, data exfiltration, scanning, and lateral movement. It does not show packet contents, so analysts must pair it with DNS, firewall, and endpoint telemetry.
• sFlow: sFlow is a sampled traffic and counter telemetry method designed for scale. By sampling packets and interface counters at the switch or router, it reduces overhead while still giving collectors enough evidence to see trends, discover devices, and understand traffic patterns in large or busy networks.
• Device visibility: Device visibility is the organisation’s ability to discover, classify, and continuously track the assets connected to its environment. In segmentation programmes, visibility is not just monitoring. It is the input that determines whether policies are precise, complete, and safe to enforce.

Deepen your knowledge

NHI Mgmt Group covers identity security, NHI governance, and agentic AI through independent research, practitioner guides, and the NHI Foundation Level course. It is designed for security practitioners who need a stronger operating model for machine identities, lifecycle control, and access governance.