According to data published by HPE in its analysis of the state of enterprise networks, the number of connected devices will double by 2028. This is not an optimistic projection about the future of technology: it is a warning about what is already happening inside the infrastructure of many mid-sized organizations. Card readers in stores, vital signs monitors in clinics, tablets assigned to students in schools, routers managed at customer sites. Every one of those devices exists on the network. The relevant question is not whether they are there, but whether anyone knows exactly which ones they are, what they do, and whether their behavior matches what is expected.
For most organizations, the answer is no. Network inventories are updated sporadically, often only when an incident or an internal audit forces the issue. In between, devices enter and leave the infrastructure without leaving a clear trace: a medical device added to a clinic’s network during a night shift, a temporary point-of-sale terminal deployed for a retail campaign, a customer router that remains active months after that customer has moved on. Each of those unidentified devices is, from a security standpoint, a door left potentially open.

Why traditional inventory methods fail in the face of IoT device proliferation
For years, IT teams have managed their networks with tools designed for relatively homogeneous environments: corporate workstations, servers, network printers. These systems respond predictably to standard discovery protocols such as SNMP or WMI and can be catalogued with reasonable ease. The problem is that IoT devices do not operate under those same rules.
A patient monitor does not announce its presence the way a Windows laptop does. A transit card reader may communicate through proprietary protocols that no conventional inventory tool can interpret. An industrial gateway may have been installed three years ago, received inconsistent firmware updates, and still be running default credentials that no one has ever changed. None of these devices shows up clearly in a traditional network scan, and those that do appear with information so generic — an IP address, a manufacturer name, a MAC address — that it is impossible to determine what role they actually play on the network or what risks they carry.
This limitation becomes more severe in distributed environments, where infrastructure spans multiple sites, customer premises, or shared spaces. Deploying software agents on every IoT device is not feasible: many of them run no operating system that would allow it. And the physical collectors that some vendors propose as an alternative come with their own scalability problems as the number of locations grows.
The result is an inventory that reflects a fraction of what actually exists on the network and that becomes outdated in days, not months.
What it means not to know what is connected to your corporate network
The lack of visibility into connected devices is not just an operational management problem. It is a security problem with concrete consequences for sectors that handle sensitive information.
In healthcare, an unidentified patient monitor may be transmitting clinical data across a network segment that should never have access to it. In retail, a card reader that no one has recognized as part of the inventory may be used as a pivot point to reach payment systems. At a telecoms company managing its customers’ networks, an uncatalogued device can become an attack vector into someone else’s critical infrastructure. In a school, a tablet that no longer belongs to an active student may still be connected, with valid credentials, and no one will have noticed.
The logic is straightforward: you cannot protect what you cannot see. And what you cannot see, you also cannot segment, monitor, or apply coherent access policies to. Attackers know this. IoT devices are particularly attractive targets precisely because they tend to lack robust security controls and because, sitting outside the inventory, their behavioral anomalies go unnoticed for longer.
Device profiling emerges as a response to this problem. Profiling a device does not simply mean knowing it exists — it means understanding what it is, what it normally does, which systems it communicates with, and what traffic patterns it generates. From that profile, it becomes possible to establish a behavioral baseline and detect deviations that may signal a compromise or misuse. But profiling is only useful when it is continuous. A snapshot of the network taken during an audit does not reflect what is happening at 3 a.m. when no one is watching.
How the absence of continuous monitoring amplifies risk in high-density connected device environments
Environments with large numbers of connected devices — multi-floor clinics, retail chains with dozens of points of sale, schools with hundreds of tablets, operators managing connectivity for hundreds of customers — share a structural problem: the attack surface grows in proportion to the number of devices, while monitoring capacity rarely scales at the same pace.
Periodic scanning is not enough. A device can be completely clean at the moment of a scan and be compromised hours later. Without continuous observation of network behavior, that window of exposure can stretch for weeks. Security teams use the term dwell time to describe the interval between an initial intrusion and its detection: in environments with limited IoT device visibility, that interval can be extraordinarily long.
The challenge of detecting anomalies is not just a matter of volume, either. IoT devices generate very different behavioral patterns from one another. An industrial temperature sensor does not behave like an IP camera, and neither behaves like a student tablet. Without precise categorization of each device, any attempt to set alert thresholds becomes a guessing exercise that produces enough false positives to push IT teams into disabling or systematically ignoring alerts. That outcome is worse than having no alerts at all.
The question that any operations or IT leader in a high-density connected device environment should be asking is not whether their network is vulnerable. It is how many of those devices appear in no current inventory, what they are doing while no one is watching, and what would happen if one of them had been behaving abnormally for weeks without anyone noticing. The honest answer, in most cases, is uncomfortable.
Has your organization ever conducted an up-to-date inventory of every device connected to its network, including those that are not conventional computing equipment? If the answer is not an immediate and unequivocal yes, it is time to start asking the right questions.

