Working with Unverified Devices

While unverified devices have known data conflicts, not every unverified device is necessarily a bad record. This page explains how to make actionable insights from unverified devices, understand the reasons for their status, and separate records worth removing from devices worth recovering.

Learn more about the different Verification Gates.

How You Can Benefit from Triaging Unverified Device

• Report an inventory count that holds up to scrutiny, and explain exactly how you arrived at it
• Find real devices that only one tool can see, before an incident finds them for you
• Identify the specific data source behind the largest share of your data quality gaps
• Remove records that inflate your inventory without representing anything real
• Track data quality as a trend rather than as a one-time cleanup

Understanding Verification Results

The following data is available for each device in your scope:

• Axonius Verified - Yes or No.

• Axonius Verification Reasons - A multi-value field indicating which gate(s) caused a device to receive a Verified or Unverified tag. The possible values are:

  • Failure reasons - Recency Failure, Identity Failure, Instability Failure, Low Confidence Source Failure, or Manually Unverified
  • Success reasons - Manually Verified, Forced Verification, or Manually Created Asset (Such assets are automatically verified). When a device was verified due to success in all gates (without manual intervention), the Axonius Verification Reasons field is empty.

Unverified devices are not a single population. Most environments contain two distinct groups, and separating them is the first step of triage.

• Devices that should not carry weight - Duplicate entries, directory objects for hardware retired years ago, and transient artifacts picked up by a scanner. These records inflate your inventory without representing anything you own or defend. The correct outcome is to stop them at the source or remove them.
• Devices with incomplete evidence - Real devices that Axonius cannot yet prove. For example, a laptop enrolled two hours ago; a server that only your network scanner can see; a device whose hostname is shared with another device. These devices are part of your environment today - you are responsible for them, but can't currently describe them with confidence. Each device has a specific reason it did not pass, which points to a specific fix.

What Each Verification Reason Tells You

Recency

A device that doesn't pass the Recency gate is either genuinely gone, or reported by a source that has stopped supplying current data. Both are worth knowing for the following reasons:

• Large stale population usually traces back to one system - most often a directory or CMDB that retains records after the hardware is retired, or a connection that has stopped fetching successfully.
• Some sources don't report a Last Seen value at all. Devices from such sources don't pass the Recency gate even when the devices themselves are active and healthy. You have the option to bypass this gate for devices without a "Last Seen" date - see Recency Gate documentation for more information.

Therefore, before drawing conclusions about a large recency population, check whether a single source accounts for most of it, and whether that source reports Last Seen.

Identity

A device that doesn't pass the Identity gate is known to exist but cannot be described. Common causes for that are:

• Directory objects with no network data attached
• Sources that return only a device name
• Parsing that drops the identifier provided by the source

This is device group is usually highly recoverable- in most cases, the identifier does exist somewhere, it just hadn't reached Axonius yet.

You can configure devices retrieved by Microsoft Active Directory (AD) or Microsoft Entra ID (Azure AD) and Microsoft Intune to bypass this gate, since those sources don't typically provide network identifiers. If you see a large Identity population sourced from a directory, check whether that bypass is configured before treating it as a data gap.

Instability

The Instability gate is more of a "waiting period" rather than a judgment. A device seen by exactly one source for the first time within the instability window is held back so that short-lived records, such as guest Wi-Fi clients, temporary containers, or incidental scan results, do not enter your trusted inventory before they are proven to be real.

Devices in this group do not require remediation. Real devices pass this gate on their own, usually as soon as a second source reports them.

Therefore, it is better to re-check the group before acting on it. If a large share of your devices remains in this group over time, treat it as a coverage signal: those devices are only ever seen by one tool.

Low Confidence Source

Devices that fail this gate are devices that Axonius found a conflict in their identifying data, most often an identifier that turns out to be shared across several distinct devices and therefore cannot be used to match records safely. In many cases, these device are entirely real, only that they have a specific, unreliable field. The Normalization Reasons Complex Field field on the device's profile page names the exact field and the exact conflict.

Managing Unverified Devices

1. Start with the Distribution, Not the Total

From the Data Hygiene Overview Dashboard, review the breakdown of devices by verification reason. One reason almost always accounts for a disproportionate share, and that concentration shows you where a single fix can shift the largest number of devices.

Example

if you have 40,000 unverified devices and 26,000 of them did not pass the Identity gate, and 22,000 of those 26,000 come from one source, then correcting that one connection may resolve more than half of your unverified devices.

2. Separate "Junk" from Valuable Devices

   Review groups of assets and try to recognize patterns such as a specific adapter source, a specific missing field, etc. If you recognize a pattern shared by multiple assets, ask two questions:

   1. Do these records correspond to actual assets in your environment?

   2. Would you include these assets in an inventory report given to an auditor?

      If the answer to both questions is "No" - they are most likely "junk" assets, and it's better to handle them at the source level rather than individually. For example, tag then with an Enforcement Action, or apply Ingestion Rules.

3. Group the Remainder by Reason and Source

Work the remaining devices by verification reason and reporting source together. Again, you are looking for patterns: a single connection, a single parsing gap, or a single identifier collision, rather than individual devices.

4. Remediate Unverified Devices

The following actions cover the majority of recoverable cases:

• Connect additional sources: The highest-leverage action. A second source resolves Instability results outright and frequently supplies the identifier missing from Identity results. When a large group of devices is visible only to your network scanner, the question to answer is which management or security tool should be reaching those devices and is not.
• Clean up the source system: Resolve stale directory objects, retired CMDB records, and decommissioned hardware still listed as active in the system where they live. This is usually the largest single cause of Recency failures, and correcting it improves every system that consumes that source.
• Fix how a source is parsed or configured: When a source provides an identifier that does not appear in Axonius, or appears in an unusable form, the fix is in the connection configuration or parsing. Ingestion Rules can also filter out categories of records you do not want ingested at all. See Setting Adapter Ingestion Rules and Adapter Custom Parsing for more information.
• Adjust correlation: When one device appears as several records, or several devices have merged into one, it is recommended to adjust the correlation settings, including custom logic for sources with unusual identifier behavior. Review the Normalization Reasons on the affected devices first, since they name the specific field causing the conflict. See Configuring Correlation Settings for more information.
• Remove the records: For records that don't correspond to a real device, removing the device or preventing its ingestion is the best solution, as it prevents their ingestion rather than repeatedly deleting them. See Axonius - Delete Assets for more information.

Recording Decisions as Exceptions

When a group of devices should be treated differently from what the gates conclude, define a Custom Exception rather than changing the gates for your whole environment. See Custom Exceptions for more information.

Update Schedule

Verification runs after correlation during on each discovery cycle. Results are not real time. Any change you make - correcting a record in a source system, adding a connection, adjusting parsing, or saving a new exception - is reflected in the verification results after the next full fetch and correlation completes. Plan your triage in cycles rather than expecting immediate feedback.

Measuring Progress

Track the verified percentage as a trend rather than as a target to hit.

A verified percentage that rises because you loosened a gate is not the same as one that rises because you connected a missing source or cleaned a stale directory. Both move the number, but only the second improves your inventory. Changes to gate configuration are recorded in the Activity Logs, so you can tell the two apart when reviewing a trend.

Expect the first result to be lower than you assume. Environments typically start with a large unverified population, and it is normal for that number to shift substantially during the first weeks of triage.