Verification Gates

Verification Gates are logical, multi-layered filters that are part of the Verification Engine. Those filters refine your device inventory: only devices that meet all the requirements defined by the gates are marked as Verified, ensuring your inventory reflects only reliable, active, and identified assets.

The Verification Engine runs against the All Devices list in your environment. It evaluates each device sequentially using AND and AND NOT logic. To be marked as verified (Axonius Verified = Yes), a device must pass through all active gates.

You have the option to disable or enable any gate, as well as all gates. If all gates are disabled, all devices in the system are marked as Verified - except for devices that match a Force Unverified query, which remain Unverified. See Custom Overrides. To stop all verification tagging, you must also clear your Force Unverified query.

Devices that have a manual override, or that match a Custom Exceptions query, are not evaluated by the gates.

After you change a gate, the change is applied at the end of the next discovery cycle.

Reverting a Gate to Its Default

You can customize the values of each predefined gate. To restore a gate's default values:

1. Hover over the gate and click Revert to default, which is refresh icon that appears at the right corner of the gate card.
2. The Revert to to default button is displayed only when the gate's configuration differs from the default. When the gate is at its default, this button is missing from the gate card.
   Your changes apply after you save them.
3. Updated by shows the user who reverted the gate to its default.

[New screenshot required] - the Revert to default action

Asset-Including Gates (AND)

Recency Gate

This gate ensures that only devices with recent network activity, defined by a set number of days, are included in the Devices view. The default is to include devices seen within the last 30 days, but you can set any other number.

You have the option to bypass this gate for devices without a "Last Seen" date. However, enabling this might increase the chances for false positives - for example, a device that was last seen 100 days ago, but since it doesn't have a "Last Seen" date, it automatically passes the gate even though it doesn't meet the criteria of "seen within the last 30 days".

Key IDs Gate

This gate ensures that only devices that are sufficiently identified are included in the Devices view. A device must have:

• A name - Host Name or Asset Name, and
• At least one of the following key data points:
  • IP Address
  • MAC Address
  • Serial Number
  • Cloud ID
  • An ID provided by the Microsoft Active Directory (AD) or Microsoft Entra ID (Azure AD) and Microsoft Intune adapters

This eliminates "anonymous" or partial records.

The gate first checks the preferred values of Host Name, Asset Name, IP Address, and MAC Address. For a device that doesn't pass this check, the gate then checks the same fields on each adapter, and a value from any adapter counts. A device fails this gate only if no source reports a name, or no source reports an identifier.

• Bypass gate for assets reported from these adapters - An optional setting. Use this to bypass this gate for assets reported by adapters that typically don't record any of the abovementioned fields (such as MAC Address) to avoid false positives.
  • If Microsoft Active Directory (AD) or Microsoft Entra ID (Azure AD) and Microsoft Intune are configured in your environment - they will appear on this list by default. This is because these adapters don't typically provide network identifiers, but they are still considered reliable sources for device data. If neither of these adapters are configured, the list will be empty.
  • You can add or remove any other adapter(s) configured in your environment.

Asset-Excluding Gates (AND NOT)

Instability Gate

This gate filters out short-lived, "ghost" records that lack cross-adapter correlation. This logic removes devices seen only briefly within a narrow window, thus preventing temporary or transient data from cluttering your inventory.

A device fails this gate when it is reported by only one adapter and its First Seen, First Fetch Time, and Last Seen values are all within the last 2 days. The default is 2 days, but you can set any other number.

A device passes this gate if any of its Last Seen or First Seen values is older than the defined number of days, or if no source reports a Last Seen value.

Low Confidence Source Exclusion Gate (Integrity & Reliance)

This gate filters out records that lack cross-adapter correlation (single-sourced adapters). A device fails this gate when it is reported by only one adapter and that adapter has at least one of the selected normalization reasons (e.g., "Bad Hostname By Serial") - Select the relevant normalization reason(s) from the dropdown. Devices reported by two or more adapters always pass this gate.

By default, the following normalization reasons are selected:

• Bad Hostname By Serial
• Bad Hostnames By Cloud ID
• Bad IMEI By Serial
• Bad Name By Entra Object ID
• Bad Asset Names By Cloud ID
• Bad Phone Numbers By IMEI

Viewing Verification Logic

The verification logic of each verification gate is transparent to you. To view the query defining each verification gate, hover over a verification card and click the View query button at the right corner.

The saved queries are named Recency Gate, Key IDs Gate, Instability Gate, and Low-Confidence Source Exclusion Gate.

You cannot edit these queries - they update automatically according to settings changes you perform on the verification gates. You can copy a query and edit the copy - but it will not affect the gate’s logic.

Example Use Cases

Example 1 - Pass Scenario

In this scenario, a standard corporate laptop is evaluated by the engine and successfully marked as verified.

• Device Profile: A corporate laptop last seen yesterday. It has a recorded MAC address and serial number. It has been active for 6 months and its data is correlated across both an EDR tool and an MDM solution.

Evaluation Steps:

1. Recency Gate (AND): The laptop was seen 1 day ago, which falls well within the required 30-day window → PASSED.
2. Key IDs Gate (AND): The laptop has a host name, as well as a valid MAC address and serial number, fulfilling the requirement for a name and at least one key identifier → PASSED.
3. Instability Gate (AND NOT): The laptop has been seen consistently over the last 6 months, so it does not match the exclusion criteria of being seen "only once within the last 2 days" → PASSED.
4. Low Confidence Source Exclusion Gate (AND NOT): The laptop does not have any system-flagged normalization reasons, and its data comes from reliable sources → PASSED.

Final Result: The device meets all verification criteria. The Axonius Verified field is set to Yes.

Example 2 - Fail Scenario

In this scenario, a transient network artifact is evaluated by the engine and fails to be verified.

• Device Profile: A rogue IP address or "ghost" record picked up briefly by a network scanner 24 hours ago. It has an IP address but lacks a host name, asset name, MAC address, serial number, and cloud ID. It has only been detected once, and its only data source is an uncorrelated IPAM adapter.

Evaluation Steps:

1. Recency Gate (AND): The record was seen yesterday, which is within the 30-day window → PASSED.
2. Key IDs Gate (AND): The device has an IP address, but no source reports a Host Name or Asset Name for it → FAILED.
3. Instability Gate (AND NOT): The record matches the exclusion criteria because it was reported by only one adapter, and its First Seen, First Fetch Time, and Last Seen values are all within the last 2 days. The engine drops it here as a "ghost" record → FAILED.
4. Low Confidence Source Exclusion Gate (AND NOT): The data originated solely from an IPAM adapter, and that adapter flagged one of the normalization reasons selected for this gate (for example, "Bad Hostname By Serial") → FAILED.

Final Result: The device failed to meet the verification criteria. The Axonius Verified field is set to No.