Skip to content

Assets: support reference

Internal. The customer-facing explanation is in the screen reference and Organising the inventory.

Assets is the largest module in the product and the one every other module depends on. An asset problem usually presents as a problem somewhere else — a finding with no owner, a dashboard missing a business unit, a report that omits a system.

Six asset types, one module

Web, Mobile, API, Network, Thick Client and Container Image are separate inventories with separate columns, separate limits and separate onboarding. A caller saying "the asset isn't there" needs the type established first; the screens look similar enough that people search the wrong one.

Licensed limits

Each client has a ceiling per asset type. Reaching it during a bulk import produces a partial inventory — some rows land, the rest do not — and the reconciliation afterwards is manual.

Check the limits before any large onboarding. This is the one asset problem that is much cheaper to prevent than to unpick.

Ownership is visibility

An owner sees their assets and the findings on them. Two consequences:

  • A departed user still owning assets means nobody is receiving those notifications.
  • Reassignment is done from the user, not asset by asset. Doing it per asset is the slow path and the one that leaves orphans.

"I can't see an asset I'm sure exists" is frequently ownership or collection scope rather than a missing record.

Asset properties feed more than the asset screen

Properties are configured per asset type and drive:

  • SLA duration — narrowed by property, so an internet-facing production system can carry a shorter deadline than the same severity internally.
  • Risk score — an estate with risk-score properties unset produces a score that is severity with extra steps, and a "top risky assets" list that ranks nothing.

A customer whose SLA dates changed with no data change has usually had a property or an SLA duration edited.

Deletion and decommissioning

Deletion hides rather than removes. A deleted asset can still be named on historical findings and on reports already generated — that is the design, and it is the answer to "I deleted it and it is still in the report".

Decommissioning is the deliberate route for an asset that is genuinely gone: it keeps the history and stops the asset counting as live coverage.

Sync configuration

Assets can arrive from integrations as well as by hand. Integration-created assets carry whatever the tool knew, which is less than a person would have entered — missing business unit, owner and criticality are the norm rather than a fault.

If an inventory fills with unfamiliar assets after an integration is connected, the control is the integration's scope.

Coverage gaps are invisible from inside the module

An asset in NxSAM that no tool scans looks identical to one that is clean. The Tenable IO comparison is the only place that shows the difference between the two inventories — see per-tool setup.

A tidy inventory with no findings is not necessarily a healthy estate.

What to collect before escalating

  1. Asset type and the exact asset name or address.
  2. The client, and the collection or group scope the caller is working in.
  3. Whether the asset was created by hand, by import or by an integration.
  4. For "missing" assets: whether it is deleted, decommissioned, or simply outside the caller's ownership.
  5. For SLA surprises: which properties and SLA durations were last edited, and when.