Asset Deduplication in Tenable Exposure Management

Tenable Exposure Management consolidates asset and vulnerability data from both Tenable-native products and third-party integrations to provide a unified, accurate asset inventory. When duplicate assets are ingested from different sources, Tenable automatically applies deduplication logic to merge records into a single asset view.

Deduplication works differently depending on the data source:

• Tenable-native assets — Assets from Tenable Vulnerability Management and Tenable Security Center are deduplicated using the Tenable UUID as the primary merge key. This is separate from the attribute-based logic used for third-party data.

• Third-party connector assets — Assets ingested from third-party connectors are deduplicated using attribute-based merge criteria (such as hostname, IP address, or MAC address) defined per asset class.

Why Deduplication Matters

Merging duplicate assets improves clarity, reduces noise, and enables more accurate risk assessment. In Tenable Exposure Management, deduplication happens automatically across sources, giving you:

• A single source of truth for each asset.

• Complete visibility into merged properties from all integrated platforms.

Tenable-Native Asset Deduplication

Assets from Tenable Vulnerability Management and Tenable Security Center use internal deduplication logic that is separate from the attribute-based merge criteria applied to third-party connector data. Tenable-native deduplication is UUID-based: two records must share the same Tenable UUID to be merged.

If Tenable Vulnerability Management and Tenable Security Center both report the same physical host but assign it different UUIDs, those records will not merge — even if the hostname and IP address match. Different UUIDs can occur when:

• Scan credentials differ between platforms.

• Agent enrollment is inconsistent (for example, an agent enrolled in one platform but not the other).

• The host was scanned in different network contexts.

To reduce duplicate Tenable-native assets:

• Ensure agent-based scans use a consistent enrolled agent UUID across both platforms.

• Verify that authenticated scan credentials are consistent so the same host receives the same UUID from each source.

• If duplicates persist, contact Tenable Support with the asset UUIDs in question. Forced merging is not available in the UI.

Third-Party Connector Asset Deduplication

Assets ingested through third-party connectors are deduplicated using attribute-based merge criteria. Tenable Exposure Management matches records across connectors by comparing key properties — such as hostname, IP address, and MAC address — using a predefined merge strategy per asset class.

The merging mechanism is designed to avoid disassembling and reassembling Tenable Exposure Management assets. If the merging criteria are met, new data is added to the existing structure.

Note: At this stage, Tenable Exposure Management uses a predefined merge strategy and property matching logic. Customization of merge rules is not currently available, but enhancements are planned for future releases.

Assets that are deduplicated and merged are considered Multi Source Assets. For more information, see View License Information in the Tenable Vulnerability Management User Guide.

Deduplication Criteria by Asset Class

Tenable applies a default merge strategy per asset class, using key properties to match and merge assets. The deduplication logic is case-insensitive and includes parsing of common formats (e.g., MAC addresses, hostnames).

Important! Assets with different Tenable UUIDs will never be merged, even if all other third-party matching criteria are met. This safeguards the integrity of Tenable-managed assets and prevents unintended merges.

Property Merge Order

When multiple sources provide different values for the same property (for example, conflicting IP addresses or operating systems), Tenable uses a fixed priority order to determine which value appears in the unified view.

Default Merge Priority

1. Tenable-native sources (such as Tenable Vulnerability Management) take precedence.

2. Third-party Connectors are prioritized by the order they were connected. The first connected source is used unless its value is missing, in which case the next available source is used.
   

   Note: The order of connectors influences the merging process. The first connector that completes processing within Tenable Exposure Management determines the identifying criteria.

Example

An asset is discovered by:

• Tenable Vulnerability Management

• CrowdStrike (connected second)

• Microsoft Defender for Endpoint (connected third)

Each source reports different values for IP address and operating system:

Property	Tenable Vulnerability Management	CrowdStrike	Microsoft TVM
IP Address	10.0.0.1	172.16.5.10	192.168.1.100
Operating System	Windows 10 Pro	Windows 11	Windows 10 Enterprise

Result:

• The IP address and OS from Tenable Vulnerability Management are selected and displayed in the UI.

• The values from CrowdStrike and Microsoft TVM are still stored and viewable in the Asset Details tab but are not shown by default.

Deduplication Limitations

• Tenable-native asset deduplication is UUID-based, not attribute-based. Assets from Tenable Vulnerability Management and Tenable Security Center will only merge if they share the same Tenable UUID. Matching hostnames and IP addresses alone are not sufficient.

• Assets must belong to the same class to be merged. For example, two assets from different connectors won't merge if one is an Account and the other is a Role.

• For cloud assets, provider IDs may differ by vendor. For example:

  • AWS via one connector might use full ARN

  • Another might use a shortened ID

  • Tenable supports matching multiple keys via a list-based NATIVE_ID.

Additional Resources

• Asset Deduplication FAQ