# Asset Inventory coverage best practices {% hint style="info" %} **Please Note:** Asset Inventory functionality is currently in Private Preview for RUX deployments only. Please contact your Vectra account team if you are interested in participating. Asset Inventory is planned to be available in QUX deployments later in the year. {% endhint %} ## Overview Asset inventory delivers a complete and trusted view of all assets on the network, enabling teams to identify unmanaged devices, detect gaps in EDR coverage, and quickly spot new or unexpected systems. This continuous visibility helps reduce risk, support compliance and insurance requirements, and strengthen overall security posture. Vectra uses passive, network-derived signals to accurately identify assets—including IoT and unmanaged systems—and enrich them with attributes such as name, type, OS, and other characteristics. These attributes power HostID, detection models, investigation workflows, and other downstream use cases. In some deployments, visibility gaps can occur: * Sensors may not see all DHCP traffic. * Local-only communication (for example, mDNS and NetBIOS) may never reach monitored segments. * Lack of visibility to other protocols can also impact coverage. When key attributes are missing, assets may appear as Unattributed IP Sessions (IP-#.#.#.#). While this can result in a lower reported asset count, Vectra still tracks the activity and maintains effective threat detection. This article provides guidance for improving coverage for Asset Inventory, HostID, Detection, and Investigation metadata. ## Benefits High coverage of network derived signals such as DHCP, mDNS, and NetBIOS allows Vectra to: **Improve Asset Inventory** * Capture IP, MAC address, hostname, and DHCP options * Build more detailed and enriched asset records (including make, model, OS, and version) * Support stronger confidence in advanced fingerprinting (for example, DHCP-based identification) **Strengthen HostID** * Improve correlation between IP addresses and hostnames * Reduce ambiguity in environments with dynamic addressing **Enhance Detection** * Provide additional context that detection models rely on * Improve visibility into hosts that may otherwise be partially observed **Enrich Investigations** * Increase available metadata for pivoting and analysis * Provide better historical context for device behavior ## Identifying Low Coverage
{% hint style="info" %} **Please Note:** Asset Inventory will be available in Respond UX (RUX) deployments initially. Support for QUX deployments is planned for a future release. {% endhint %} Under *Exposure → Inventory*, a yellow warning box about **Traffic Visibility Limiting Asset Recognition** indicates low coverage and Vectra recommends that steps be taken to help improve coverage. Vectra Customer Success teams may also proactively reach out to customers when telemetry indicates issues. Please work through this guide and try to increase coverage. Use [Traffic Validation (ENTV)](/deployment/traffic-engineering-and-validation/traffic-validation-entv.md) to baseline DHCP, mDNS, and NetBIOS percentages on an aggregate and per sensor or subnet basis to gather baselines that you can use for later comparison after making changes. ## Signals Needed for Good Coverage While all of the signals below help, the bolded entries below are of critical importance for high quality Asset Inventory coverage. * **MAC address** observed through **DHCP** traffic * **NetBIOS** traffic * **mDNS** traffic * SSH traffic * User Agent observed through HTTP traffic ## Methods to Increase Coverage ### Extend Network Sensor Coverage Asset Inventory benefits from L2 network visibility of assets. While threat detection deployments have historically focused on monitoring Internet traffic and internal datacenters, Asset Inventory requires broader coverage—including internal networks and edge locations where assets reside. The following resources are helpful to better understand what traffic should be observed by your Sensors and what traffic is being observed. * [NDR / Network Identity Architecture](/deployment/getting-started/ndr-network-identity-architecture.md) - overall architecture advice * [Network Traffic Recommendations](/deployment/traffic-engineering-and-validation/network-traffic-recommendations.md) - specifics on what to capture, what can be ignored * [Traffic Validation (ENTV)](/deployment/traffic-engineering-and-validation/traffic-validation-entv.md) - how to validate the quality of the traffic being observed * Both aggregate and per Sensor data is provided to help zero in on problem areas * [Traffic Validation (ENTV) alerting](/deployment/traffic-engineering-and-validation/entv-syscheck-descriptions.md) - alerting options for traffic quality ### Asset Visibility Forwarding Please see [Asset Visibility Forwarding](/deployment/traffic-engineering-and-validation/asset-visibility-forwarding.md) for full details including sample configurations for a variety of networking equipment vendors. **Asset Visibility Forwarding** is a deployment technique that allows Vectra to observe network asset identity-related artifacts even when your current Sensor placement does not provide full visibility. It uses standard network capabilities (such as ERSPAN or GRE) to forward selected traffic from switches or network devices to a Vectra Sensor. By forwarding selected network traffic (such as DHCP, mDNS, and NetBIOS) from remote parts of your network, you can significantly improve: * Asset Inventory coverage * Host-ID accuracy * Detection fidelity * Metadata available for investigations Asset Visibility Forwarding is most useful when: * Your sensors do not see DHCP, mDNS, or NetBIOS traffic. * It is critical when you are not seeing all DHCP traffic. * You have limited Layer 2 visibility. * Devices communicate locally within access networks. * You observe gaps in Asset Inventory or Host-ID coverage. ### **Forwarding DHCP Logs to Vectra** [SIEM (Vectra Brain ingesting logs)](/configuration/setup/external-connectors/siem-vectra-brain-ingesting-logs.md) aka SIEM Event Forwarding is another option that can provide DHCP log data to your Vectra Brain. DHCP will help with Host-ID name resolution, and may enhance Asset Inventory, but is not as comprehensive as configuring Asset Visibility Forwarding. Observing DHCP packets is a much better sources than logs as Vectra can parse all required information for Asset Inventory and any future associated use cases. Issues with DHCP logs as a source: * There is no official standard format and not all can be parsed successfully. * Vectra supports the ISC format which includes Infoblox and DHCPD. * Some do not include hostname and only provide IP and MAC. ## Evaluating the Impacts of Changes To see the impact of changes made to help increase coverage: * Use [Traffic Validation (ENTV)](/deployment/traffic-engineering-and-validation/traffic-validation-entv.md) * Examine DHCP, mDNS, and NetBIOS traffic levels and look for an increase on a per subnet and aggregate basis from baseline values. * See that Warnings on Asset Inventory are no longer being present. * It may take some time for changes to be fully realized. * It is recommended to wait up to a day or two to gather new data that would alter the metrics used to determine if the warning should be shown. * You may need to alter the timeframe for the report to not look at data for hosts that were observed before the changes were made. --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.vectra.ai/configuration/coverage/asset-inventory-coverage-best-practices.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.