Asset and Device Visibility FAQ

Security teams usually discover the limits of their visibility one asset category at a time for everything from IT to more diverse Internet of Things (IoT), operational technology (OT), and Internet of Medical Things (IoMT). Endpoint tools cover laptops and servers, a scanner might cover part of the data center, and the cameras, printers, workloads (including AI usage), controllers, and building systems in between appear only when something goes wrong. Teams want to know how to see every device type, what is running on each one, how devices communicate, and how to tell whether their view has gaps. Sometimes, this level of always-available inventory and visibility is mandated.

The answers below address each of those questions. Every answer is written to stand on its own, so security, IT, and OT teams can go directly to the question in front of them.

Visibility by Device Type

How Do I Get Visibility Into Every Device Type on My Network?

Getting visibility into every device type takes one inventory that classifies IoT, OT, IoMT, and IT assets the same way, built from network traffic, existing tool data, and safe targeted queries. Network traffic is required because it’s the only foolproof, 100% safe way to gain information about networked assets, workloads (including AI), and devices without risking a device failure caused by unexpected network traffic. This is often the case for legacy OT and other specialized devices. Separate tools for each device type leave gaps in visibility that attackers know how to exploit.

Each device type reveals itself differently. IT assets report through endpoint agents, directory services, and credentialed scans. IoT devices identify themselves through the protocols they use, such as DHCP, mDNS, and their management traffic. OT devices speak industrial protocols such as Modbus, Profinet, DNP3, BACnet, S7, and HART-IP, which require deep packet inspection to interpret. An approach that reads all of these signals and correlates them into a single record per device covers every type without installing anything.

The result should be consistent across types: every device classified to type, vendor, model, and firmware, with its services and connections, in the same view. That consistency lets one risk model, one set of policies, and one report span the whole network.

Asimily provides that view agentlessly. It combines deep packet inspection, AI and ML classification against a library of well over 10,000,000 observed devices and profiles, active querying, flow data, and correlation with over 150 different sources, including Active Directory, CMDB, NAC, DHCP, vulnerability scanners, Mobile Device Management, threat intelligence, and others, to discover and classify assets. Users can expect nearly 100% of their connected assets, such as IoT, OT, IoMT, and IT devices, workloads, services, applications, middleware, and AI chatbots, to be identified with 98% or higher accuracy. Users can start seeing value within 48 hours of deployment and see most of their devices within 14 days of deployment to ensure that even assets with minimal network traffic are classified.

[Related: Inventory and Visibility]

How Do I Get Visibility Into Medical Devices (IoMT) Like Infusion Pumps and Imaging Systems?

Gaining visibility into Internet of Medical Things (IoMT) devices requires specialized passive monitoring that respects clinical operations and patient safety. Medical devices such as infusion pumps, patient monitors, and MRI machines run proprietary operating systems and protocols (e.g., DICOM, HL7) that often cannot tolerate active scanning or traditional endpoint agents.

Asimily provides specialized IoMT discovery by parsing medical protocols, correlating vendor FDA disclosures, and mapping clinical workflows to identify device make, model, operating system, and software components without risking clinical disruption. Before new devices arrive, Asimily ProSecure uses Asimily’s observed risk data for medical devices in the field to flag risky purchases before spend is committed.

[Related: Medical Device Security]

How Do I Get Visibility Into IoT Devices Like Cameras, Printers, and Badge Readers?

Visibility into IoT devices such as cameras, printers, and badge readers comes from analyzing how each device communicates and classifying each so the vendor, model, firmware, and often software components are known in case vulnerabilities are found against any of these in future. These devices rarely accept agents, can respond poorly to aggressive scans (such as freezing or rebooting), and are often installed by facilities or physical security teams outside IT’s normal process, so network-based discovery is the dependable method.

Each device type has a recognizable signature. IP cameras stream video to a video management system and expose web and streaming services. Printers advertise print services and reach print servers and manufacturer portals. Badge readers talk to access control panels and servers over vendor-specific protocols. Traffic pattern analysis and deep packet inspection read those protocols, including rarely seen vendor-specific protocols, and machine learning matches the patterns against known device profiles.

Useful IoT visibility goes beyond the device name. It shows which firmware each camera runs, which printers expose management services, and which badge readers reach systems they should not.

Asimily starts to identify IoT devices from the first packet using Automated IoT Categorization. It refines classification as traffic arrives, categorizing each device by vendor, model, firmware, and custom facility tags, feeding this detail into Asimily’s vulnerability prioritization engine and microsegmentation capabilities.

[Related: Automated IoT Visibility and Deep Categorization]

How Do I Get Visibility Into OT Devices Like PLCs, HMIs, and Building Controllers?

Visibility into OT devices such as PLCs, HMIs, and building controllers depends on understanding industrial and building automation protocols without disturbing the process. An agentless approach reads the protocols these devices already use, identifies each device by vendor, model, and firmware, and maps which systems control which equipment.

PLCs communicate with HMIs, engineering workstations, and historians over protocols such as Modbus, EtherNet/IP, and S7. Building controllers use BACnet, LonWorks, and Modbus to reach supervisory servers. Deep packet inspection of those protocols reveals device identity and firmware, and it also shows operational context, such as which engineering workstation programs which controller.

Safety sets the method. Many OT devices were never designed to handle unexpected traffic, so discovery should start from observed communication and use active queries only where they are known to be safe for that device type and environment.

Asimily’s Passive and Active Safe Scanning gather OT device information safely through non-intrusive traffic inspection, classifying PLCs, HMIs, and building controllers alongside IT and IoT assets without disrupting operational technology processes.

[Related: OT Security]

How Do I Get Visibility Into IT Assets Alongside Unmanaged Devices?

Visibility into IT assets alongside unmanaged devices comes from combining the data IT tools already hold with network-based discovery, so laptops, servers, and virtual machines appear in the same inventory as the cameras and controllers they share a network with. IT assets are usually well documented in endpoint management, directory, and CMDB tools, but those records sit apart from any view of unmanaged devices.

A single inventory matters because attacks cross device types. An attacker who compromises a camera moves toward servers and workstations, and one who compromises a laptop can reach an HMI through an engineering workstation. Risk assessment and segmentation policy need both ends of that path in one view.

Correlation also improves IT data. Network observation can reveal managed endpoints whose agent stopped reporting, servers missing from the CMDB, and workstations that communicate with OT networks.

Asimily’s Edge Collector analyzes network traffic directly, and the platform can ingest and normalize IT asset telemetry from tools like CrowdStrike, ServiceNow, and Jamf, correlating managed endpoints with unmanaged network assets to eliminate blind spots across IT and OT boundaries. It’s available as software and packaged in a variety of hardware formats from very affordable to very powerful.

[Related: Integrations]

How Do I Identify Legacy and End-of-Life Devices on My Network?

Identifying legacy and end-of-life devices requires knowing each device’s exact operating system, firmware version, and model, then comparing that against vendor support status. Classification to model and version is the prerequisite, since a device recorded only as “Windows Host” or “Controller” cannot be checked against an end-of-life date.

Legacy devices show up across every device type: workstations embedded in industrial equipment running unsupported Windows versions, PLCs and HMIs on firmware the vendor no longer updates, cameras and printers whose manufacturers have stopped issuing patches, and building controllers installed decades ago. Many are still essential to operations, so the first goal is to find and protect them, with replacement planned over time.

Once identified, legacy devices need their own treatment. Their vulnerabilities often cannot be patched, so protection relies on segmentation, restricted access, and monitoring. Some regulations call this out directly. DORA, for example, requires financial entities to assess the risk of legacy ICT systems at least yearly.

Asimily identifies device model, operating system, firmware version, and much more across IoT, OT, IoMT, and IT assets, and flags devices running outdated software or firmware. For devices that cannot be patched, Asimily recommends targeted mitigations and pushes them as access policy through NAC integrations such as Cisco ISE. Where firmware upgrades exist, Asimily IoT Patching can apply them.

[Related: Microsegmentation FAQ: Tools, Zero Trust, and Segmenting IoT and OT Devices Without Disruption]

Visibility Into Assets and Applications

How Do I See Which Services and Applications Run on Each Device?

Seeing which services and applications run on each device comes from observing the ports, protocols, and application traffic each device uses, supplemented where safe by targeted queries and existing scan data. The goal is a per-device view of what the device offers to the network and what it reaches out to.

Services matter for risk. A camera exposing Telnet, a printer running an open FTP service, or a controller with a web management interface reachable from user networks each represents an attack path. Vulnerability matching also depends on service detail, because a CVE in a service the device never runs does not apply.

Applications matter for operations and policy. Knowing that a building controller runs a specific vendor’s management application, or that a workstation hosts engineering software for a particular PLC family, explains why certain connections exist and which ones a segmentation policy must keep open.

Asimily’s deep service inspector analyzes application payloads to discover and record running services, open management ports, and active protocols across all connected endpoints. It can detect rogue AI model usage, certificates from insecure certificate authorities, and much more.

[Related: IoT Device Detail Enrichment]

How Do I Track Firmware and Software Versions Across Device Types?

Tracking firmware and software versions across device types requires pulling version data from every source that has it, keeping it current as devices are updated, and recording it consistently in one inventory. Version is the field that connects a device to its vulnerabilities, so tracking it accurately is what makes vulnerability management possible for connected devices.

Each device type exposes version information differently. Some IoT devices reveal firmware in their network traffic or management interfaces, OT devices report it through industrial protocols, and IT assets report software through endpoint agents and credentialed scans. Where a device does not reveal its version from traffic, a safe targeted query or an existing scanner result can fill the gap.

Version tracking also has to be continuous. Updates, downgrades, and factory resets change versions without notice, and a firmware downgrade can reopen a vulnerability that was already closed.

Asimily’s rich asset profiles and security capabilities display use passive deep packet inspection and safe, targeted queries to monitor operating system and firmware versions (among 150+ available fields for asset records) continuously, flagging unauthorized downgrades or unpatched software instantly.

[Related: Continuous IoT Vulnerability Detection]

How Do I Map Which Devices Communicate With Each Other?

Mapping device communication means tracking observed connections between devices, including protocols, ports, direction, and frequency, to build a map for segmentation, threat detection, and investigation. Network traffic provides the reliable reality, capturing hidden dependencies and cross-zone paths missing from static documentation. A software platform responsible for mapping must understand the sources, destinations, and nature of the communication to create a good map.

An effective map details connection paths across boundaries (such as between IT and OT) and flags new traffic patterns, which are often the first sign of misconfiguration or compromise.

Asimily’s Flow and Topology mapping captures and categorizes all inter-device network flows to create a dynamic topology map used for policy simulation, threat detection (including allowable policy settings), and microsegmentation design.

[Related: How Poor Device Visibility Undermines Segmentation in Connected Environments]

How Do I See Which Devices Connect to Cloud Services or the Internet?

Seeing which devices connect to cloud services or the internet requires monitoring outbound connections for every device and resolving each destination to the service behind it. Many IoT devices are built to reach the cloud: cameras upload to cloud video platforms, and printers (and almost anything updateable) check in with manufacturer portals.

Some of those connections are expected and necessary. Others are warning signs, such as a controller that should never reach outside of the plant network reaching an external address, a device connecting to a provider the organization does not use, or traffic matching known malicious activity (such as the outbound callbacks to attacker-controlled servers seen in Log4Shell exploitation). Telling the two apart requires a baseline of what each device type normally does.

Internet connectivity also changes risk. A device with a vulnerable service that is reachable from, or communicates with, the internet carries more exposure than the same device on an isolated segment, and prioritization should reflect that.

Asimily’s external path analyzer tracks outbound connections, resolves destination clouds, and highlights unexpected internet access paths across unmanaged assets to restrict unauthorized external communications.

[Related: Threat and Response]

Closing Visibility Gaps

How Do I Know If My Device Visibility Has Gaps?

You can tell whether device visibility has gaps by comparing the inventory against independent sources and checking for the signs of missing coverage: subnets or sites with no observed devices, devices seen in DHCP, NAC, or switch data that the inventory does not include, devices classified only as “unknown,” and records missing model, firmware, or owner.

Gaps usually trace to a few causes. Some network segments are not monitored (often remote sites, plant networks, or Layer 3 segments where traffic never reaches a monitoring point). Some devices are present but poorly classified. Some records go stale because the inventory is refreshed periodically instead of continuously.

A regular gap check keeps the inventory honest. Compare device counts by site and segment with network data, track the share of devices classified to model and firmware, review unknown devices, and confirm that new devices appear promptly after they connect.

Asimily lists every device once it can be confidently identified, so devices are visible even before they are fully classified, and it correlates NAC, CMDB, DHCP, scanner data, and other data repositories to expose records that do not match. Gaps become visible and addressable rather than stay hidden.

[Related: Asset Discovery: How to Find Every Device on Your Network]

How Do I Reconcile My CMDB With What Is Actually on the Network?

Reconciling a Configuration Management Database (CMDB) requires continuously comparing static inventory records against live network observation. Static CMDB entries quickly become stale due to unrecorded device moves, decommissioned hardware, or shadow IT deployment.

Asimily integrates bi-directionally with CMDB platforms like ServiceNow, feeding live discovery data to update missing attributes and flagging rogue devices present on the network but missing from the database. Further, Asimily has been built from the ground up to handle the thorniest issues of inventory reconciliation, down to weighting individual fields from specific integration partners at different levels, based on their observed past performance.

[Related: Unified Inventory and Visibility FAQ: Discovering, Classifying, and Tracking Every Connected Device]

How Accurate Is Agentless Device Classification?

Typically, 98-100% in Asimily’s observation. Agentless device classification is most accurate when it combines multiple methods: deep packet inspection of device protocols, machine learning trained on device behavior, and correlation with existing data sources such as the CMDB, NAC, and vulnerability scanners. Accuracy comes from the amount of evidence the system gathers about each device and how it handles uncertainty.

Classification typically improves over time for a given device. The first packets establish that a device exists. More traffic reveals its protocols, services, and communication patterns, and the system narrows its identification from a general category to a specific vendor, model, and firmware version. Integrations add detail where traffic alone is limited.

Some situations are harder. Devices on Layer 3 networks where only IP addresses are visible, mobile devices whose addresses keep changing, and rare or custom devices all need more evidence. A trustworthy system still lists a device it cannot yet fully classify, so no device silently drops out of the inventory.

Asimily combines deep packet inspection, AI and ML analysis, and multi-source correlation, including patented techniques, to classify IoT, OT, IoMT, and IT assets and workloads into families and sub-families. It lists every device it confidently identifies, refines classification as data arrives, and lets organizations customize classification to match how they organize their devices.

[Related: Inventory and Visibility]