Unified Asset Inventory FAQ: How to Normalize and Reconcile Device Data From Many Sources

Most security teams face a common challenge: an abundance of disconnected data. A typical cybersecurity arsenal includes dozens of tools such as network access control (NAC) platforms, configuration management databases (CMDBs), vulnerability scanners, and DHCP servers. Each of these maintains its own device inventory. These lists rarely align, leading to duplicates, conflicting attributes, and critical visibility gaps. Government guidance treats fixing this as foundational: CISA’s Foundations for OT Cybersecurity: Asset Inventory Guidance, published in August 2025 with U.S. and international partners, lists collecting asset attributes and managing that data among the core steps of building an inventory.

Achieving a reliable, unified asset inventory requires three key elements:

• Multi-dimensional data gathering: Using independent methods to discover and enrich what is known about connected assets.
• Extensive data integration: Correlating context across dozens of security, network, and IT systems.
• Intelligent normalization: Dynamically resolving conflicts to establish a single trusted record for every asset.

This FAQ explains how asset unification works across Internet of Things (IoT), operational technology (OT), Internet of Medical Things (IoMT), and IT environments, and how the Asimily platform delivers a unified asset inventory.

Why Unification Is Hard

What Is a Unified Asset Inventory?

Definition: A unified asset inventory is a single, continuously updated registry of every connected device across IoT, OT, IoMT, and IT environments, merging data from multiple sources into one accurate profile per asset.

Key highlights include:

• Broad coverage: Consolidates hardware, software, containers, cloud resources, identities, and network components.
• Accurate deduplication: Combines redundant references to the same device into a single record.
• Tiebreaking: Picks the correct value when multiple sources conflict.

Unification matters most for unmanaged devices. Cameras, programmable logic controllers (PLCs), infusion pumps, badge readers, and more often appear in few or none of the tools a team already owns. Many of these devices were built before today’s threats. Attacks now move faster than manual inventory reconciliation can keep up.

Asimily provides a unified inventory across IoT, OT, IoMT, and IT assets. It combines its own agentless discovery with correlation across over 150 different sources. This inventory is the foundation for Exposure Management, Threat Detection and Incident Response readiness, Segmentation Orchestration, and the rest of the platform.

[Related: Inventory and Visibility]

Why Can’t I Just Merge Data From All My Security and IT Tools?

Merging data from security and IT tools without normalization usually produces duplicates, conflicting fields, and gaps instead of an accurate inventory. Each tool describes devices in its own way. Each one sees a different slice of the network and updates on its own schedule.

For example, one tool might label a device “Windows Embedded,” another “Windows 10 IoT,” and a third just “windows.” A CMDB may still list a device that was retired last year. A scanner may never see a fragile controller that the team excluded from scans on purpose to keep it operational.

Simple merging cannot tell which of these values is right. It also cannot tell when two records describe the same device under different IP addresses or other names. Simple rules such as “use the most recent value” often pick the wrong one.

Unification typically needs three capabilities. The first is several independent ways to observe each device. The second is a reliable way to match records to one device. The third is a way to decide which value to trust for each field. Asimily was built to do all three across IoT, OT, IoMT, and IT assets, including their components, middleware, workloads, AI components, and more.

[Related: Integrations]

What Happens When Two Sources Disagree About a Device?

When two sources disagree about a device, a unified inventory has to decide which value to keep. That decision is typically made field by field, not source by source, because a source can be reliable for one attribute and unreliable for another.

Operating system is a common example. A vulnerability scanner might report Windows. Traffic on the wire might show behavior typical of an embedded Linux device. The CMDB entry might say neither. Sometimes the conflict is legitimate, because a single device can run Linux for some functions and Windows for others.

Asimily resolves these conflicts at the field level, using live network observation as the check, since it reflects what the device actually does.

Agreeing with each system owner on which source is authoritative for which field typically prevents disputes between teams later.

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

How Asimily Collects Device Data

What Does Deep Packet Inspection Add to Asset Discovery?

Deep packet inspection lets a platform identify devices agentlessly and without disruption by reading the protocol content of traffic the devices already send. That content often reveals vendor, model, firmware version, and function, not just addresses and ports.

Header-level data shows that a device exists and which ports it uses. It rarely shows what the device is. Protocol content, such as an OT controller’s Modbus or BACnet messages, carries much richer identifiers.

Asimily applies deep packet inspection to traffic from SPAN ports (or equivalent) and from sensors such as Asimily Edge. It is one of several collection methods. Mirrored traffic can be incomplete in some network designs, so deep packet inspection works best alongside flow data, active querying, and integrations.

[Related: Automated IoT Visibility and Deep Categorization]

How Does AI and ML Device Classification Work?

Artificial intelligence (AI) and machine learning (ML) classification identifies devices by comparing what a platform observes about each one with a library of known device profiles. It then assigns the closest match for type, vendor, model, and more. A larger and more varied library can typically recognize more uncommon devices.

Asimily classifies devices against a library of well over 10,000,000 observed devices and profiles. Its inputs include parameters collected from each device, communication patterns, and attributes pulled from integrations. For example, a device that speaks BACnet and is missing from the CMDB can typically be classified as a building controller and matched to its vendor and model.

In Asimily deployments, nearly 100% of connected assets are typically identified, with classification accuracy of 98% or higher (based on Asimily customer deployments, 2026). Integrations sharpen the result, and the richer the data, the better.

[Related: IoT Device Detail Enrichment]

How Does Safe Active Querying Work for IoT and OT Devices?

Safe active querying sends small, targeted requests limited to what each device type can safely handle, after passive observation has identified the device. Disruption usually comes from aggressive active scanning built for servers, not from active querying itself.

Safe active querying reverses the usual order. Passive observation first identifies the device. Only then does the platform send a small, protocol-appropriate request to fill in missing details such as firmware version.

Asimily’s network sensors keep these queries non-intrusive. When passive monitoring identifies an OT device that uses a protocol such as Profinet or DNP3, the sensor can send targeted, low-impact queries for deeper details. For many IoT devices, active querying uses manufacturer-sanctioned APIs, the same ones a technician might use when servicing equipment. Asimily does not send active requests to medical devices.

For example, a U.S. municipality used Asimily’s API-based querying integrations to safely pull granular data from remote traffic cameras. Operations teams usually want to approve any active method before it touches production equipment, and a targeted design makes that approval easier.

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

What Does Flow Data Add to Device Visibility?

Flow data, such as NetFlow and sFlow, shows which devices talk to which, and how often, across parts of the network where mirrored traffic is incomplete. It helps fill the gaps that mirror ports leave and is increasingly important for building a complete inventory.

Mirror port data is often inadequate in layer 3 environments, as not every packet may get to a monitored location. Flow records from existing switches and routers can cover those segments without new hardware. Flow data carries less detail than packet content. It shows connections, not device identity, so it works best combined with deep packet inspection and integrations.

Asimily ingests NetFlow and sFlow alongside mirrored traffic, including RSPAN and ERSPAN, and correlates them into one view. Communication patterns also feed segmentation policy, since Segmentation Orchestration builds policy from observed device behavior.

[Related: Beyond SPAN: How NetFlow and sFlow Close the Gaps in Device Visibility]

Which Data Sources Can Feed a Unified Inventory?

Almost any system that holds device data can feed a unified inventory, including identity, network, IT service, security, and endpoint tools. Each source contributes a different piece of context.

• Active Directory shows domain-managed devices.
• CMDB and CMMS platforms (e.g., ServiceNow) provide ownership and business context.
• NAC platforms (e.g., Cisco ISE, Aruba ClearPass) track network authentication.
• DHCP and IPAM platforms (e.g., Infoblox) track changing IP addresses.
• MDM and EDR tools describe managed mobile endpoints and host agent details.
• AI usage data shows which endpoints are operating AI models, which aids understanding.

Asimily correlates data from over 150 different sources with its own agentless discovery. DHCP integration is a common early step, because it improves classification speed and tracks devices as they move. New integration support is regularly added at customer request in days, due to Asimily’s experience in this area.

[Related: Integrations]

Normalizing and Validating the Data

How Does Asimily Normalize Data From Different Tools?

Asimily normalizes data from different tools by mapping each source’s names, formats, and values into one consistent structure, field by field. Attributes such as device type, operating system, vendor, and firmware level then mean the same thing regardless of where they came from.

Normalization fixes problems that merging cannot. One tool may record a vendor’s full legal name. Another may abbreviate it. A third may record only a product family. Without normalization, reports can undercount a vendor, policies can miss devices, and vulnerability matching can fail.

Asimily selectively includes vendor data down to the field level, so only the most reliable sources shape each attribute.

This normalization runs continuously. Reporting, policy rules, and risk assessments then rest on the same consistent data across the tech stack. The method draws on years of experience classifying IoT and other non-IT assets.

[Related: Operational Efficiency]

How Does Asimily Decide Which Source Is Right?

Asimily decides which source is right by weighing each source’s reliability for the specific field and checking it against what it observes directly on the network. No single source is treated as always correct.

Tools are built for different jobs. A scanner may be precise about open ports but guess at the operating system of an embedded device. A CMDB may be authoritative for ownership but out of date on IP addresses. Network traffic shows how a device actually behaves today.

Asimily sees devices on the wire, so it has a large body of first-hand evidence to test other sources against. When a source contradicts that evidence, Asimily can wait for consistent results across repeated observations before it changes a classification. Every vendor, product, and field has a “reputation” that determines if, when, and how quickly that field-level information ever reaches a customer. Reputation is built from the millions of devices, signals, and data points Asimily has seen, which together form a predictive model.

When evidence stays mixed, Asimily applies its experience with each product’s data to make the call.

For example, if a scanner reports Windows on a device whose traffic matches a known Linux-based controller model, Asimily would typically keep the classification its traffic analysis supports. Administrators stay in control and can edit device records individually or in bulk.

[Related: Best Unified Asset Inventory and Visibility Platforms 2026]

Seeing What Runs on Each Asset

Can I See What Runs on a Device, Not Just the Device?

Yes. A unified inventory can record the services, applications, and software versions running on each asset, not only the asset itself. That layer often decides whether a device is actually exposed.

Two devices of the same model can carry very different risk. One may run an outdated application with a known vulnerability. Another may have that service disabled. Vulnerability matching, configuration review, and segmentation policy all depend on knowing what runs on each device.

Asimily discovers what runs on assets, not just the assets themselves, including services, applications, middleware, AI chatbots, and more. Each device record lists the ports and services it uses and the applications and versions installed on it. Endpoint configuration management integrations, such as Microsoft Configuration Manager, add installed software lists for managed endpoints.

For example, knowing the exact application version on a device helps Asimily filter out CVEs that do not apply to it.

[Related: Continuous IoT Vulnerability Detection]

Keeping the Inventory Unified

How Long Does It Take to Build a Unified Inventory?

Most devices typically appear within days of deployment, and full correlation can take up to several weeks. If the only data source is passive network traffic analysis, it depends on how often each device talks. Busy devices are typically identified quickly. Quiet devices take longer, because the platform needs enough traffic or integration data to classify them with confidence.

Initial recognition often happens through a device’s first-seen communications or through active methods such as SNMP walks. Full correlation of every data point can take from several minutes to several weeks.

With Asimily, users can start seeing value within 48 hours of deployment and see most of their devices within 14 days (Asimily customer deployments, 2026). That window allows even assets with minimal network traffic to be classified. Integrations shorten the timeline. Asimily typically recommends DHCP integration first, followed by SNMP walks and NetFlow or sFlow.

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

Choosing a Platform

What Capabilities Should I Look for in a Unified Asset Inventory Platform?

A unified asset inventory platform should collect device data in several independent ways, correlate many sources, and normalize conflicting data at the field level. It should cover IoT, OT, IoMT, and IT assets in one inventory and connect that inventory to action.

When comparing platforms, test classification on your own less common devices. Ask how the platform resolves a conflict between two sources at the field level, without rigid rules or manual tiebreaking. Ask which active methods it uses, how they are deployed safely, and which device types it avoids. Check its integrations with your NAC, CMDB, scanners, and EDR. Ask what happens after discovery: whether enforcement stops at quarantine or extends to segmentation policy. For a scored comparison of six platforms, see Best Unified Asset Inventory and Visibility Platforms 2026.

Asimily combines deep packet inspection, AI and ML classification, active querying, flow data, and correlation with over 150 sources, then normalizes the result. The inventory feeds ATT&CK Analysis, Risk Simulator, Configuration Control, IoT Patching, and Segmentation Orchestration. An inventory that is wrong about a device can produce the wrong policy, so accuracy typically matters more than raw device counts.

[Related: Platform Overview]