# Host ID best practices and functionality

## Overview

Vectra AI automates the naming of network hosts (devices/assets). The names are based on artifacts collected through passive observation of network traffic and other artifacts that are obtained through active queries made by the platform. This automated naming technology is called **Host ID**.

The goal of Host ID is to provide human-readable names for your hosts. Better host naming improves analyst workflows by helping teams investigate hosts by name rather than by transient IP addresses.

## Host ID Introduction

Host devices/assets in your environment can always be manually named by users if desired. If a host is manually named, Host ID will not update the name of the device.

IP sessions track the activity from an IP as long as that IP remains active on the network. IP sessions close after 2 hours of inactivity. Host ID processes all the host artifacts collected during an IP session (also known as host session) and will curate a host name to display in the Vectra UI. That UI host name is associated to an underlying host container in the Vectra AI Platform that stores algorithm learnings and detections.

A host artifact is metadata that helps associate observed network activity with a real-world host, such as a physical device, virtual machine, cloud workload, endpoint, etc. Example artifacts include DNS names, reverse DNS (rDNS) names, Kerberos machine names, DHCP hostnames, MAC addresses, vCenter metadata, EDR metadata, SASE identifiers, and more. HostID can also name hosts by the user associated with them for SASE vendors such as for Zscaler ZPA and Netskope.

Artifacts will typically be added to a host record over time as more host activity is seen and better associations are made. Host artifacts will expire over time, and will be removed from the host when they have not been observed for an extended amount of time, typically 6 months.

<figure><img src="/files/0UGy4jW4x6e6AmjXbByb" alt="" width="563"><figcaption><p>Example Host ID Artifacts for jump-station5</p></figcaption></figure>

Hosts are tracked internally in a name agnostic manner. When assessing host naming on your Vectra platform it is important to understand that host names are decided at the time of viewing the host page in your UI. It is therefore expected that displayed hostnames can change over time to reflect the most human readable name given the artifacts available at the time of page display.

When Host ID does not observe reliable host artifacts for a device, the device may appear as a **Generic Host** named **IP-x.x.x.x**, and is also referred to as an **Unattributed IP Session** in the Vectra AI Platform.

<figure><img src="/files/ZvtJ5wWwYCMJInicyAaP" alt=""><figcaption><p>Example Unattributed IP Sessions (Generic Hosts)</p></figcaption></figure>

HTTP cookies may be used for tracking, but not for human-readable host naming. Hosts that only have HTTP cookie artifacts may receive names using the **AUTO-xxxxx** convention where **xxxxx** is a unique identifier for the host. This means Host ID can uniquely identify the host but cannot attribute a human-readable name.

<figure><img src="/files/6CwfcmHTCRuCSQUkFb5N" alt="" width="563"><figcaption><p>Example AUTO-xxxx Host</p></figcaption></figure>

## Why is accurate Host ID important?

The benefits of reducing the number of unattributed IPs you have in your environment extend far beyond it just being nice to have more human-readable names. When investing time into ensuring the Vectra AI Platform has proper visibility into the needed host artifacts for Host ID, you are setting your organization up to conduct investigations more efficiently and with greater confidence. You are helping turn unattributed IPs into actionable intelligence.

**Ease Analyst Workflow**

Security analysts are able to quickly identify affected systems without needing to manually pivot between DHCP logs, CMDB records, EDR tooling, cloud inventories, or spreadsheet exports simply to determine what an IP address belongs to. This reduces investigation fatigue, and helps analysts focus on understanding attacker behavior rather than spending valuable time on basic asset attribution.

Improved host attribution also strengthens the accuracy and usefulness of detections, entity relationships, prioritization workflows, and attack-path analysis across the platform. When hosts can consistently be mapped to meaningful identities, security teams gain clearer visibility into device behavior, ownership, business context, and potential blast radius during an incident. This becomes especially important in environments with dynamic addressing, VPN usage, cloud workloads, NAT boundaries, and short-lived infrastructure where IP addresses alone are often insufficient identifiers.

**Improve Asset Inventory**

[Asset Inventory](/configuration/coverage/asset-inventory-coverage-best-practices.md) is a feature currently in private preview. It 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.

Asset Inventory uses a different underlying engine to identity assets, but many of the same artifacts that are valuable for HostID functionality, also help to enable more complete and accurate asset inventory. Please see the linked article above for additional best practices for Asset Inventory.

**Enhanced Ease-of-Use for Host Lockdown and Traffic Lockdown**

When you have good Host ID coverage, analysts can more easily identify the hosts/assets by name rather than IP address. This makes decisions around Lockdown easier with less pivoting to other tools for validation.

* [Host Lockdown](/configuration/response/lockdown/host-lockdown-edr.md) article
* [Traffic Lockdown](/configuration/response/lockdown/traffic-lockdown.md) article

**Improve Cross-Team Collaboration**

Organizations that invest in strong asset visibility and host naming practices also improve cross-team collaboration between Security Operations, IT Operations, Asset Management, and Incident Response teams. Analysts can communicate findings more clearly using recognizable hostnames instead of raw IP addresses, reducing ambiguity during escalations and accelerating coordinated response efforts.

**Improve Long-Term Operational Maturity**

Maintaining high-quality host attribution helps improve long-term operational maturity within the Vectra AI Platform. Historical investigations become easier to interpret, threat hunting workflows become more reliable, and reporting becomes more actionable because entities can be consistently tracked over time rather than appearing as disconnected unattributed IP addresses.

**Summary**

Ultimately, reducing unattributed IPs improves both the effectiveness of the platform and the efficiency of the analysts using it, enabling faster investigations, clearer operational visibility, and more confident security decision-making.

## Best Practices for Improved Host ID

{% stepper %}
{% step %}

### Ensure protocols with artifacts are observed

DHCP, DNS/rDNS/mDNS, Kerberos, and NetBIOS, protocols are of paramount importance to observe for Host ID functionality and help enable higher-fidelity [Asset Inventory](/configuration/coverage/asset-inventory-coverage-best-practices.md).

{% hint style="info" %}
**DHCP**

DHCP provides strong host identity evidence, including computer name and MAC address. DHCP visibility also helps Vectra AI identify when an IP address changes ownership.

**Recommended Actions**

* Monitor DHCP traffic between clients, relays, and DHCP servers.
* Include user, server, wireless, VPN, remote office, and OT/IoT networks where applicable.
* Validate that DHCP traffic is visible from subnets with many IP-xxx.xxx.xxx.xxx (unattributed IP) devices.
* When DHCP is in an isolated L2 broadcast domain without Vectra Sensor coverage, consider using [Asset Visibility Forwarding](/deployment/traffic-engineering-and-validation/asset-visibility-forwarding.md) for the best quality DHCP data.
* Forward DHCP server logs when available using [SIEM event forwarding.](/configuration/setup/external-connectors/siem-vectra-brain-ingesting-logs.md)
  {% endhint %}

{% hint style="info" %}
**DNS/rDNS/mDNS**

When **rDNS** is accurate, it can provide readable names for servers, infrastructure, static IP ranges, and devices that do not regularly emit DHCP or Kerberos metadata. rDNS is an active query from the Vectra Brain appliance.

**DNS** is a passively observed artifact source. While less valuable than rDNS it can still provide useful host names when Vectra AI observes DNS traffic.

**mDNS** is a passively observed artifact source that can provide hostnames for devices advertising services on local networks, especially user endpoints, printers, IoT devices, and other unmanaged or lightly managed assets. Because mDNS is link-local multicast traffic, visibility depends on where sensors are positioned and whether that traffic is present in monitored segments.

**Recommended Actions**

* **rDNS**
  * Configure rDNS zones for internal IP ranges.
  * Maintain accurate pointer (PTR) records for static assets.
  * Remove stale PTR records for retired or readdressed systems.
  * Prioritize hygiene for server, infrastructure, OT/IoT, and static address ranges.
* **DNS**
  * Monitor DNS queries and responses involving internal resolvers.
  * Maintain consistent DNS naming standards.
  * Remove stale records.
  * Align DNS and rDNS records where possible.
  * Prioritize DNS hygiene for subnets with large amounts of unattributed IP sessions.
* **mDNS**
  * Monitor where endpoint, wireless, IoT, printer, and lab networks are in scope.
  * Validate Sensor placement if expected mDNS names are not appearing, since mDNS traffic usually does not cross routed boundaries and typically stays within the local subnet or VLAN.
  * [Asset Visibility Forwarding](/deployment/traffic-engineering-and-validation/asset-visibility-forwarding.md) is a technique that can be used to forward mDNS traffic to your Vectra Sensors if direct observation by a Sensor is not possible.
    {% endhint %}

{% hint style="info" %}
**Kerberos**

Kerberos machine names are strong Host ID artifacts. In Active Directory environments, Kerberos visibility can significantly improve host naming and host continuity across IP changes.

**Recommended Actions**

* Monitor traffic to and from domain controllers.
* Confirm visibility into Kerberos traffic for endpoint and server networks.
* Include remote office, wireless, VPN, and data center authentication paths.
* Use [Windows Event Log Ingestion](/configuration/coverage/network-identities-weli.md) (WELI) to forward Microsoft Windows security event logs to your Vectra Brain when it is not possible to observe all the Kerberos traffic in your environment.
  * WELI can even result in hosts, accounts, and detections being created in your Vectra AI Platform without even directly observing the associated network traffic.
    {% endhint %}

{% hint style="info" %}
**NetBIOS**

NetBIOS is a passively observed artifact source that can provide hostnames for Windows systems and legacy environments where NetBIOS Name Service traffic is still present. Because NetBIOS traffic is commonly limited to the local subnet or VLAN and may be disabled in modern environments, visibility depends on Sensor placement and whether that traffic is present in monitored segments.

**Recommended Actions**

* Ensure your Sensors can observe NETBIOS when Windows endpoint, legacy, OT/IoT, or unmanaged networks are in scope.
* Validate Sensor placement if expected NetBIOS names are not appearing, since NetBIOS traffic is commonly limited to the local subnet or VLAN.
* Prioritize DHCP, DNS/rDNS, and Kerberos where available, as these generally provide stronger or more centrally managed identity evidence.
* [Asset Visibility Forwarding](/deployment/traffic-engineering-and-validation/asset-visibility-forwarding.md) is a technique that can be used to forward NetBIOS traffic to your Vectra Sensors if direct observation by a Sensor is not possible.
  {% endhint %}
  {% endstep %}

{% step %}

### Enable EDR integrations

EDR integrations can provide host identifiers, endpoint names, OS details, MAC addresses, and agent metadata. These artifacts help Vectra AI identify hosts even when passive network-derived artifacts are incomplete. It is a best practice to enable EDR integration for any supported EDR present in your environment.

EDR integration also makes it possible to use [host lockdown](/configuration/response/lockdown/host-lockdown-edr.md) but this is not required to be enabled. EDR Process Context is also being added to some EDRs. Please see the [Crowdstrike EDR process context correlation](/operations/analyst-guidance/crowdstrike-edr-process-correlation-user-guide.md) user guide as an example.

**Recommended Actions**

* Configure supported EDR connectors in *Configuration → SETUP → EDR Integrations*.
* Validate connector health after setup.
* Confirm that endpoint names and stable endpoint identifiers are being provided. It can take up to 48 hours for all hosts to have EDR context after the integration is configured.
* Review EDR coverage for subnets with large amounts of generic IP-named devices.
  {% endstep %}

{% step %}

### Enable VMware vCenter integration

vCenter/vSphere artifacts have high host naming priority. This is especially important in virtualized environments where IPs may change, workloads may move, and passive network artifacts may be incomplete. It is a best practice to enable this integration if using VMware vSphere in your environment.

In addition to the artifacts it brings, enabling this integration gives security team members visibility into visibility gaps inside the vSphere environment and exposes configuration erros that could impact packet capture.

**Recommended Actions**

* Configure vCenter integration in *Configuration → SETUP → External Connectors*. See [vCenter integration (VMware)](/configuration/setup/external-connectors/vcenter-integration-vmware.md) for details.
* Use read-only credentials with sufficient visibility into VM inventory.
* Confirm that VM names and VM UUIDs are available. It can take up to 48 hours for all hosts to have vCenter context after the integration is configured.
* Review vCenter coverage after virtualization changes, migrations, or new cluster deployments.
  {% endstep %}

{% step %}

### Enable IaaS Host ID connectors

To enable efficient investigation of cloud hosts, Vectra AI can be configured to periodically query the APIs offered by cloud providers to gather additional information about hosts running in them. This information contributes to Vectra’s automated Host identification (Host ID) and adds information to the Host entity details screen.

It is a best practice is to enable these integrations for every supported IaaS cloud vendor that you have hosts deployed in when their traffic will be seen by a Vectra Sensor. Sensors do not necessarily have to be deployed in the IaaS cloud to provide value. As long as the Sensor sees traffic from hosts deployed in those IaaS clouds, that Sensor could be in your on-prem network that has private connectivity to cloud deployed hosts.

**Recommended Actions**

* Ensure that traffic from hosts deployed in supported clouds is observed by a Vectra Sensor whether that is directly in the cloud or in an on-premises location with private or VPN connectivity to the cloud provider.
* Enable [AWS Host ID integration](/configuration/setup/external-connectors/aws-hostid-integration.md) when you have hosts in AWS.
* Enable [Azure Host ID integration](/configuration/setup/external-connectors/azure-hostid-integration.md) when you have hosts in Azure.
* Enable [GCP Host ID integration](/configuration/setup/external-connectors/gcp-hostid-integration.md) when you have hosts in GCP.
  {% endstep %}

{% step %}

### Enable SASE/SSE integrations

Integration with SASE/SSE vendors, such as Zscaler and Netskope, contributes to Host ID and tracking users/hosts that may not be directly observed by Vectra Sensors. When a supported SASE/SSE vendor is in use in your environment, it is a best practice to configure integration with that vendor. Please see [Remote users (SASE/SSE)](/configuration/coverage/remote-users/remote-users-sase-sse.md) for links to articles for specific vendors.

**Recommended Actions**

* Enabling [ZPA LSS log ingestion](/configuration/coverage/remote-users/zscaler-zpa.md) enables hosts to be tracked by `ZPA-user` name in your Vectra UI. This integration also enables app connector traffic from remote users to be associated with the remote user instead of the ZPA app connector that proxied that traffic to your apps.
* Enabling [ZIA integration](/configuration/coverage/remote-users/zscaler-zia.md) enables hosts to be tracked by `ZIA-device ID` in your Vectra UI. This integration also allows internet bound traffic from remote users to be retrieved from an AWS S3 bucket and ingested into a Vectra Sensor so that it can be analyzed as if that user was on the corporate network.
* Enabling [Netskope Cloud Tap integration](/configuration/coverage/remote-users/netskope-cloud-tap.md) enables hosts to be tracked by `NET-user` in your Vectra UI. This integration also allows a Vectra Sensor to accept traffic from the Netskope Stitcher app that pulls remote user internet traffic from a cloud object store where Netskope stores the user traffic.
  {% endstep %}

{% step %}

### Review static IP configuration carefully

Vectra Brain [IP Address Classification](/configuration/coverage/brain-setup/ip-address-classfication.md) settings allow configuration of static IPs/ranges. When a IP or range of IPs is defined as static, it provides a stable host anchor for learnings and detections. This is beneficial because unattributed IP sessions expire over time and not all algorithm learnings can be stored on these generic hosts. It provides predictability for analysts because once an IP or range is marked as static, Host ID treats it differently and does not learn from artifacts observed on that IP.

IPs/ranges that are marked as static will show in the UI as `STATIC-x.x.x.x` for the name. This name can be edited in your UI to be anything you like but it will never change based on artifacts seen through any other means.

**Recommended Actions**

* Mark individual IPs/ranges as static only when there is no reliable source of artifacts and Host ID isn't able to consistently name these hosts.
* Use static IP naming for stable infrastructure, not dynamic endpoint ranges.
* Avoid marking DHCP-managed client ranges as static.
* Periodically review static IP definitions for accuracy.
* Remove or update static IP entries when infrastructure changes.
  {% endstep %}

{% step %}

### Avoid excessive artifact conflicts

Some hosts may remain unnamed, or may transition from named to unnamed, when the system observes conflicting artifacts, too many new artifacts, or behavior that suggests the host is a proxy. It is a best practice to reduce noisy or conflicting identity signals for hosts/devices/assets where possible. The expected result is that your Vectra AI platform receives cleaner artifacts and is less likely to suppress or avoid naming due to conflicting identity evidence.

**Recommended Actions**

* Avoid duplicate generic hostnames such as localhost, my-computer, or repeated image-default names.
* Correct DHCP or DNS records that assign the same name to many distinct devices.
* Investigate subnets where many devices share names such as My iPhone or localhost.
* Review proxy, NAT, load balancer, and shared infrastructure behavior separately from endpoint behavior.
* Ensure server images and gold images use unique names before deployment.
  {% endstep %}

{% step %}

### Contact Vectra Support

If you've tried all of the above best practices and still are having issues with Host ID, please contact Vectra Support for assistance.

Support can be reached at [https://support.vectra.ai](https://support.vectra.ai/).

Keep in mind that it can take some time for all of the changes to have an impact on the number of unattributed IP sessions you are seeing in your deployment. It is always normal to have some IP-x.x.x.x hosts because new IP sessions need to observe artifacts over time until a stable existing host can be identified to merge the IP session into, or a new host can be created.
{% endstep %}
{% endstepper %}

## Terminology Explained

<table><thead><tr><th width="191.20703125">Term</th><th width="121.703125">Alias(es)</th><th width="441.60546875">Meaning</th></tr></thead><tbody><tr><td>Host ID</td><td></td><td>Vectra AI's automated host naming system that uses artifacts as input.</td></tr><tr><td>Host</td><td>Device, Asset, Host Container</td><td>A representation of a real-world device, which can be a physical device, a virtual machine or even a group of them. When device-based information is not available, user-based information can be used to define the host. Hosts can not be observed directly and are instead built from network observations.</td></tr><tr><td>IP Session</td><td>Host Session</td><td>A window of time for a given IP, where Host ID believes the IP is owned by one device (one Host). These close after 2 hours of inactivity.</td></tr><tr><td>Artifact</td><td>Host Artifact</td><td>Metadata consumed from network traffic and external providers. The metadata is associated with an IP session, and may or may not contain unique identifying information</td></tr><tr><td>Host Name</td><td></td><td>A generated name of the host that is available to the customer. It is generated from the host artifacts and can be superseded by the user with custom names.</td></tr><tr><td>Passive Observation</td><td></td><td>Network traffic observed by your Sensors is parsed into metadata that contains artifacts that Host ID parses.</td></tr><tr><td>Active Query</td><td></td><td>A query the Brain appliance makes to a data source that can provide artifacts or other functionality.</td></tr><tr><td>Unattributed IP Session</td><td>Generic Host</td><td>A container within the Vectra system that acts as a host, but is not identified by the Host ID system. If a IP session does provide any useable artifacts , it is stays an unattributed IP session (generic host) and is named based on the IP observed during the IP session.</td></tr><tr><td>Curation/Recuration</td><td></td><td>Curation is when Host ID initially evaluates the artifacts in a IP session and assigns the session to a host which could be new or existing. Re-curation happens periodically, is similar to curation, and re-evaluates long running IP sessions</td></tr><tr><td>Split</td><td></td><td>Host ID will sometimes split an IP session between two different hosts when artifacts conflict and it becomes apparent that a new host is using the same IP that the previous host was using.</td></tr><tr><td>Merge</td><td></td><td>Merges occur when Host ID believes that two host containers in the system are actually describing the same real-world host. Host ID will merge the two hosts into a new merged Host.</td></tr></tbody></table>

## Artifact Priority for Naming

If one single artifact is known, that artifact will be used for the name. For example, if only the MAC address is known then the name of the host will be the MAC of that host. Similarly, if only the DNS name is known, then that will be the name of the host.

When multiple artifacts are known, the naming priority is based on the type of the artifacts known.

The list below reflects the current priority order of the host naming artifacts. Artifacts higher up the list (towards the top) will supersede artifacts later in the list. Mulitple entries on the same line mean those artifacts are treated with the same priority ranking.

<table><thead><tr><th width="214.203125">Artifact Source/Type</th><th width="201.4375">How Acquired</th><th width="315.23046875">Detail</th></tr></thead><tbody><tr><td><strong>User Defined</strong></td><td>Customer Input</td><td>If you choose to override the artifact driven naming, your chosen name will always be used.</td></tr><tr><td><strong>vCenter</strong><br><strong>IaaS Host ID Connectors</strong></td><td>Active Query</td><td>Host name from vCenter integration and artifacts provided by the Host ID connectors for public clouds like AWS, Azure, and GCP.</td></tr><tr><td><strong>Reverse DNS</strong></td><td>Active Query</td><td>Host name (Fully Qualified Domain Name) returned by a reverse DNS query</td></tr><tr><td><strong>Static IP</strong></td><td>Customer Input</td><td>The IP/range that has been user-defined as static. This hostname will also contain a prefix <code>STATIC-</code>, followed by the static IP or can be renamed as desired.</td></tr><tr><td><strong>ZPA user</strong></td><td>LSS Logs</td><td>The username of a user session obtained from the Zscaler system. This hostname will also contain a prefix <code>ZPA-</code>, followed by the ZPA username.</td></tr><tr><td><strong>DNS</strong></td><td>Passive Observation</td><td>The host name (FQDN) observed in DNS traffic for that host.</td></tr><tr><td><strong>Kerberos</strong></td><td>Passive Observation<br>WELI</td><td>Any observed Kerberos machine names learned from successful Kerberos authentications.</td></tr><tr><td><strong>DHCP</strong></td><td>Passive Observation<br>SIEM Event Forwarding</td><td>The host name observed from a DHCP query.</td></tr><tr><td><strong>NetBIOS</strong></td><td>Passive Observation</td><td>The host name observed from NetBIOS traffic.</td></tr><tr><td><strong>Carbon Black Response</strong><br><strong>Carbon Black Cloud</strong></td><td>Active Query</td><td>The integration-specific name or serial identifier.</td></tr><tr><td><strong>Crowdstrike</strong></td><td>Active Query</td><td>The integration-specific name or serial identifier.</td></tr><tr><td><strong>MAC</strong></td><td>Passive Observation</td><td>The MAC address observed in the DHCP response.</td></tr><tr><td><strong>mDNS</strong></td><td>Passive Observation</td><td>The host name from the mDNS traffic.</td></tr><tr><td><strong>Windows Defender for Endpoint</strong></td><td>Active Query</td><td>The integration-specific name or serial identifier.</td></tr><tr><td><strong>ZIA Device ID</strong><br><strong>Netskope User</strong></td><td>Passive Observation<br>Passive Observation</td><td>The identification number of a device obtained from the Zscaler system. This will be <code>ZIA-device ID</code>.<br>The username of a Netskope user obtained frome the Netskope traffic. This will be <code>NET-user</code>.</td></tr><tr><td><strong>Other EDRs</strong></td><td>Active Query</td><td>Host names from any other supported EDR that isn't listed above.</td></tr></tbody></table>

Host names can change over time as Vectra aggregates additional artifacts, or prunes stale artifacts on a host record. Host splits and merges can also occur.

Devices may be initially assigned to a unattributed IP session and then subsequently re-attributed to dedicated host records once proper artifacts are observed. If Detections are observed while the host is attached to the generic host container, they will be migrated to the new host identifier at the same time.

## Additional Important Host ID Details

#### Some hosts may have an incorrect name

Host ID attributes names to IP addresses by matching artifacts to IP session traffic seen for a given IP. If Host ID learns a confident name for an IP and that IP later changes owner without inactivity, DHCP release, or new conflicting artifacts, Vectra AI may maintain the earlier name.

When this occurs, the user may manually edit the hostname to match the known-good hostname.

#### Some hosts may have the same name

Two distinct hosts may have duplicate names. Examples include:

* Many wireless devices named My iPhone.
* Multiple servers named localhost.
* Systems deployed from an image without unique hostnames.

Duplicate names do not necessarily indicate a Host ID defect. They may reflect legitimate duplicate names present in the environment.

These duplicate name hosts are still unique in the system. They will all have a unique internal ID for each host as you can see in the URL when looking at a host entity.

<figure><img src="/files/dkTviiEzDIVcYragweZD" alt="" width="375"><figcaption></figcaption></figure>

#### Host names change over time

Host names can change as Vectra AI observes new Host ID Artifacts, receives new connector data, or removes stale Host ID Artifacts. Hostname changes do not affect the underlying detections, campaigns, threat score, or certainty score for the host.

#### Some hosts may have no human-readable name

A host may remain unnamed when:

* No naming artifact has been observed
* Only HTTP cookie tracking artifacts are available
* Artifacts conflict
* Too many artifacts are observed
* The host is a known proxy
* The host is represented only by a unattributed IP session (generic host)

#### A host may go from named to unnamed

If Vectra AI later observes conflicting artifacts, too many new artifacts, or proxy-like behavior, a host may transition from named to unnamed.

### Remediation Guidance

When you have too many unattributed IP sessions, consider the below guidance.

<table><thead><tr><th width="238.59375">Environment</th><th width="487.234375">Highest-value Artifact Sources</th></tr></thead><tbody><tr><td>Domain-joined workstations</td><td>Kerberos, DHCP, DNS, EDR</td></tr><tr><td>Servers</td><td>rDNS, DNS, Kerberos, EDR, vCenter</td></tr><tr><td>Virtual machines</td><td>vCenter, VM metadata, DNS, EDR</td></tr><tr><td>Cloud workloads</td><td>IaaS host connectors, DNS, EDR</td></tr><tr><td>Wireless clients</td><td>DHCP, DNS, Kerberos, SASE/SSE where applicable</td></tr><tr><td>VPN users</td><td>DHCP/logs, Kerberos, EDR, SASE/SSE where applicable</td></tr><tr><td>OT/IoT devices</td><td>DHCP, MAC, DNS/rDNS, static naming hygiene</td></tr><tr><td>Network infrastructure</td><td>rDNS, static IP naming, DNS</td></tr></tbody></table>

Start by correcting the highest-impact gaps

| Finding                  | Recommended Remediation                                   |
| ------------------------ | --------------------------------------------------------- |
| DHCP not visible         | Add DHCP visibility or forward DHCP logs.                 |
| Kerberos not visible     | Add visibility to domain controller authentication paths. |
| rDNS missing or stale    | Configure or correct PTR records.                         |
| DNS traffic not visible  | Monitor internal resolver traffic.                        |
| vCenter metadata missing | Enable or repair vCenter integration.                     |
| EDR metadata missing     | Enable or repair EDR connector.                           |
| Static IPs unnamed       | Add accurate reverse DNS or static IP names.              |
| Many duplicate names     | Correct naming standards or source system records.        |

### What Not To Do

Avoid these approaches:

* Do not treat manual renaming as the primary remediation for widespread `IP-x.x.x.x` (unattributed IP session) naming.
* Do not assume `IP-x.x.x.x` hosts are unmonitored; they may be monitored but unnamed.
* Do not rely solely only on north-south internet traffic for host naming artifacts.
* Do not ignore DHCP, Kerberos, DNS, and rDNS visibility.
* Do not mark dynamic endpoint ranges as static IP ranges.
* Do not expect every host to have a stable name if the environment emits duplicate or conflicting artifacts.

### Success Criteria

After improving visibility and integrations, customers should observe:

* Fewer `IP-x.x.x.x` (unattributed IP sessions or generic hosts).
* More hosts named by DNS, rDNS, Kerberos, DHCP, vCenter, cloud, or EDR artifacts.
* Better host continuity across IP changes.
* Fewer duplicate or misleadig host names.
* Better analyst confidence when investigating detections.
* Better asset inventory fidelity across managed endpoints, servers, virtual machines, and cloud workloads.


---

# 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/reference/understanding-vectra-host-naming.md?ask=<question>
```

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.