Inventory and Lenses¶

The Inventory page is the heart of Vista Platform. It's where every asset, certificate, cryptographic key, crypto configuration, and third-party connection your environment has discovered comes together in one place.

There is one inventory — a single dataset — and lenses reshape it. A lens doesn't take you to a different page or a different copy of the data; it re-angles the same underlying inventory so you see it the way the task in front of you needs. Auditing certificate expiry? Switch to the Certificates lens. Checking weak ciphers? Switch to Configuration. Tracking down assets that have gone quiet? Switch to Stale. Same data, different angle.

Where to find it¶

Inventory in the left navigation rail. Its lenses are grouped into three:

Group	Lenses
Assets	All assets · Map · Software · Networks · VLANs · Clusters · Circuits · Sites · Cloud · Racks · Cabling
Cryptography	Certificates · Keys · Configuration · TLS · SSH · Data Protection · 3rd Party · Tunnels
Lifecycle	Stale · Changes · Pending (a link across to Discovery → Approvals)

The active lens is in the page address (/inventory?lens=…), so a lens view is bookmarkable and shareable.

Every lens in that table is live. Map draws the neighbourhood around one asset and Software answers "who is running this product, at this version?" — both have their own pages (The Map, SBOM upload) because neither is a table with different columns. Networks and VLANs are your IP address management: the prefix tree, addresses and VLANs (Networks, VLANs and IP addresses). Sites lists the places your assets are, each opening its site page (Sites and locations). Racks lists every rack with its utilisation (Racks); Cabling lists every cable with both ends (Cabling); Circuits (Circuits), Clusters (Virtualization) and Cloud (assets grouped by cloud account) follow the same pattern. Tunnels, in the Cryptography group, lists VPN tunnels with the IKE and IPsec algorithms each offers (VPN). Changes is the change log (Changes and journal).

Pending is a link, not a second list. Everything awaiting your review — discovered assets, imports, CMDB pulls and merge proposals — lives in one queue at Discovery → Approvals, and Inventory points at it rather than keeping a copy.

All assets¶

The default view, and the general inventory. Every row is one asset — one thing, not one address or one open port. A host running five services is one row here, with its five endpoints on its own page.

Every asset has exactly one class — Server, Switch, Object storage, Web application, Business service, and so on — from a fixed taxonomy. The left rail shows that taxonomy as a tree with a count beside each class.

The tree is hierarchical, and picking a parent selects everything beneath it: click Hardware and you get servers, switches, firewalls and printers together; drill to Server and you get only servers. That is why there is one asset list rather than one page per class.

The columns follow the class you pick. Choose Server and you get operating system and model; choose Object storage and you get provider and account. Pick a parent class, or none at all, and the columns fall back to what everything shares — because a list mixing servers and switches has no common operating-system column to show.

Columns in the toolbar changes that set. It lists every column the list can show — Standard, More (support group, site, business unit, network, endpoints, risk), Lifecycle (warranty end, end of support, purchased, seller) and, with a class picked, all of that class's attributes, not only the three shown by default. Tick a column to show it, untick one to hide it, search the list by name, or Reset to default. Your choice is remembered in this browser for your account, and a column you never touched keeps following the class you pick.

To browse the taxonomy itself — every class, the attributes it carries, and what a class decides — see Asset Classes & Identification Rules.

The other filters¶

Beneath the class tree: Risk, Status, Provenance, Environment, Site, Prefix, Owner, Business unit, Tag, and Findings. Selections within one filter are combined with or; across filters with and.

Two of them deserve a note, because both are about the difference between "we looked and found nothing" and "nobody looked":

Risk → Not assessed finds assets that have something cryptographic on record — a crypto configuration, an encrypted store, a TLS, SSH or IPsec endpoint, or a key or secret store — that no producer has scored yet. That is not a low risk — it is the absence of a risk assessment, and on a fresh tenant it is usually the most useful slice on the page.
Risk → No crypto observed finds unscored assets with nothing cryptographic on record at all, such as a phone seen only on the local network or a cloud security group. There was nothing to assess. It describes what Vista Platform saw, not a guarantee that the device uses no cryptography.
Findings → No open findings finds assets that were assessed and came back clean. If you want the ones nobody has looked at, that is Risk → Not assessed, not this.

The query box¶

Every filter you click writes into the query box at the top of the page, and the query is what actually runs. This is deliberate: the box shows you, in the platform's query language, exactly what your clicks mean — so you learn the language by watching the filters produce it.

You can also type in it directly, which is how you ask for things the checkboxes cannot express:

class:server and risk >= high and environment:production
class:hardware and risk:not_assessed
endpoint:(port:443 and protocol:tls)
tag.tier:gold and last_seen < now-30d

As you type, it suggests the fields and values that exist — it will only ever offer you something the platform accepts. If a query is wrong it underlines the exact word and says what is wrong with it, often with the correction:

environment:production and hostnaem:web-1
                           ^^^^^^^^
unknown_field: no field "hostnaem" on assets. did you mean "hostname"?

The query lives in the page address, so a filtered view is shareable: send someone the link and they see the same rows.

If you type something the filters can't represent — a relationship traversal, say — the rail tells you so and keeps it. Clicking a checkbox afterwards does not throw away what you typed.

Adding something by hand¶

New asset (top right) records a thing you already know about — an appliance nothing can scan, a business service with no address at all. The form asks for the class first, because the class decides which fields it then offers you. See Adding assets manually.

On the Certificates lens the same corner also carries Add certificate: upload a PEM, or declare a certificate you know exists by its common name and expiry date (Certificate monitoring).

Saved views¶

Views (beside the query box) saves the current query under a name, for you and your team. A view is nothing more than its query, so applying one puts that query in the box where you can see it, adjust it, and save the result as another view.

The Address column, and blanks in it¶

The Address column shows the asset's primary endpoint — its address, and its port when it has one.

Some assets have no address at all, and the column is genuinely blank for them. An object store or a declared business service has nothing to connect to. A blank here means "this thing has no network endpoint", not "we failed to find one" — and it is why you will never see a made-up port beside one.

Opening an asset¶

From All assets, clicking a row opens the asset drawer, a quick look that keeps your place in the list; its Open full page button goes to the asset page. Clicking a row on Stale, or ctrl/cmd-clicking (or middle-clicking) an asset's name on All assets, opens the asset page directly. It lives at its own address (/inventory/assets/…), which you can link to, and has tabs:

Tab	What's on it
Overview	Class and how it was decided; every identifier with its kind, source, confidence and when it was last seen; the class's attributes; ownership and context, including the asset's prefix and, when that network has a recorded gateway, via the gateway; status; and risk — with who assessed it, or an explicit Not assessed. A router or firewall also gets Networks routed: every network it is the gateway of, with its address there, VLAN, DHCP, host count and sensor coverage.
Services & Endpoints	Every network face of the asset: address, port, transport, the identified service and how confidently it was identified, and when it was last seen.
Interfaces	The asset's physical and virtual interfaces, addresses and VLAN modes (Interfaces).
Ports	The faceplate: ports drawn in the device type's order, with Connect, the bulk cable editor, Trace and the cryptography overlay (Cabling).
Hardware	Device type, the Lifecycle card (purchase, warranty, support contract and end of support), modules and module bays, inventory items and virtual chassis (Device types).
Relationships	What this asset is attached to — each edge with its type, its direction, where it came from, and whether it is confirmed or still proposed — plus the impact closure: what else is affected if this goes away.
Cryptography	The crypto configurations discovered on the asset. Click one for the full configuration drawer.
Findings	Cryptographic findings on this asset, with the configuration each was found on.
Software	The products installed on this asset — name, vendor, version, end-of-life state, known vulnerabilities, identifier, source, last seen and status. A product that has been removed is shown muted rather than dropped, because "it was here and is gone" is an answer.
History	Two lists. Class history first — every class this asset has held, what moved it, and who decided — then the general change log: context edits, merges, approvals, newest first.
Changes	The new change log and the journal. The change log records each edit made through the newer infrastructure surface — who made it, from where (web UI, API, discovery or sync) and which fields moved, newest first; it starts empty and fills as those edits happen, while earlier edits stay on History. The journal is a list of dated notes anyone in your organisation can read — a repair, a move, a decision — each with its author and a kind (info, success, warning, danger). Reading needs the `dcim.read` permission and adding an entry `dcim.manage`.
Config Context	The weight-merged JSON of every config context that matches the asset (Config contexts).

Under the asset's name, the page also shows its tags: labels from your organisation's shared tag list. People with dcim.manage can click Edit tags to pick tags or create a new one; saving records the change in the change log. These tags are separate from the key/value tags shown on Overview, which they will replace in a later release.

From the cryptography lenses — where the row is a certificate, a key or a configuration rather than an asset — clicking through to an asset opens the same quick-look drawer, so you keep your place in the list you were working. The asset drawer carries an Open full page button when the peek is not enough. Both the drawer and the asset page carry Active Scan, for people who can edit assets, to probe that one asset now. It opens the same scan dialog as the bulk bar below, with its Run from choice.

Working with many assets at once¶

All assets and Stale have a checkbox on every row. Tick rows — on as many pages as you like — or tick the box in the header to select the page. When the whole page is ticked and the query matches more than one page, a banner offers Select all N matching: every asset the query matches, not only the ones on screen.

While anything is selected, a bar above the list shows how many and what you can do with them:

Action	What it does	Needs
Scan	Opens the scan dialog: choose Run from (Auto, the platform sensor, or one of your sensors) and start an active scan of the selection.	update assets
Edit	Sets owner email, environment, business unit or support group (or clears one), and adds or removes tags, on every selected asset. Other tags are kept.	update assets
Archive	Archives the selection, after a confirmation.	update assets
Restore	Returns archived assets in the selection to active inventory. One that stays unseen past your lifecycle policy is archived again.	update assets
Delete	Soft-deletes the selection, after a confirmation. Each asset can be restored from its own page.	delete assets
Export	Downloads the selection as CSV — every matching asset, not only the page. The file keeps its standard columns and adds every column you have shown that they do not already include (owner, support group, a class's attributes as `attr.<name>`…).	—

Buttons you lack the permission for are not shown. Each result says how many assets changed and how many were already in that state. Every change is recorded in each asset's History under your name, and the whole action is recorded once in your organization's audit log.

"All matching" never means more than you saw. The selection is sent as the query and the number of assets you confirmed. If discovery has added assets that match the query in the meantime, nothing is changed and you are told the new count; review the list and run the action again. A selection can hold up to 5,000 assets, and a scan up to 1,000 (one scan job's limit); above that, narrow the query.

On Stale, Select all matching is offered only when no search or filter is applied, because those narrow the page in your browser rather than in the query.

Scans you start here. Under the bar, Scans started here lists each scan with where it runs and its progress, and names every asset that was not scanned and why — for example, because the sensor that observed it is offline and no other sensor of yours covers its prefix. Each asset's name links to its page. A row whose scan is running shows Scanning…; one whose last scan did not reach it shows Last scan failed.

Assets nobody has scanned yet¶

Views → Never scanned shows every asset no active or automatic scan has reached yet — typically assets that arrived by import, by SBOM or from a CMDB. Tick them and choose Scan. An asset leaves this view once a scan has finished on it, even when nothing answered. (This view replaces the former Discovery → Active Scan page; a bookmark to that page opens it.)

Class history: was this ever something else?¶

An asset's class decides a great deal — which findings apply to it, which approval rules match it, which compliance measurements it is in scope for. So when the class changes, everything recorded before the change was recorded about a different kind of thing, and the question "was this reclassified?" is usually the first one worth asking about a surprising result.

Inventory → an asset → History answers it. The Class history panel lists every class the asset has held, newest first, and each entry says:

what moved — the class before and the class after. The oldest entry has no "before": it is the class the asset was given when it was first discovered.
how — Set at discovery (the classification rules or a collector decided it), Accepted in Approvals (a reviewer took a proposed class), Edited by a person, or Stated by an import.
who, when a person was involved. Entries with no person were made by the platform; the panel names the mechanism rather than guessing at a user.
why — the rules that argued for it, or the classifier and how confident it was.

An empty panel does not mean the class has never changed. It means nothing has been recorded — which is what you will see for assets discovered before this record existed. The panel says so rather than showing a clean timeline.

Nothing here can be edited. To change an asset's class, edit the asset, or accept a class proposal in Discovery → Approvals; either way the change turns up in this panel.

Identifiers, and why they matter¶

The Overview tab lists the asset's identifiers — its FQDN, hostname, addresses, MAC, serial number, cloud resource id, and so on. These are what make one thing one asset: when a sensor sees a host, your CMDB exports it, and someone types it in by hand, the platform matches all three on their identifiers and keeps one record rather than three.

Each identifier shows where it came from and how confident the platform is. When the evidence is ambiguous, you get a merge proposal in Discovery → Approvals rather than a silent guess. The order the platform tries identifiers in is documented, read-only, at Settings → Policies → Identification rules.

When a device's identifiers change¶

Devices change what identifies them: an administrator rotates an SSH host key, a server is moved to a new address, a machine is wiped and reinstalled, or a different machine takes over an address. When a sighting matches an asset you already have but some of its identifiers are different, the platform compares what stayed the same with what changed and decides which of these happened:

Stayed the same	Changed	What the platform concludes	What it does
Hardware (MAC) address and IP address, or a serial number, agent id or cloud resource id	SSH host key of the same type (for example, the Ed25519 key)	The key was rotated	Keeps the sighting on the asset, replaces the old key of that type, records it in History and sends a notification
Everything	A host key of a type the device has not shown before (for example, its RSA key after its Ed25519 key)	Another key of the same device: a server offers one key per type, and which one a scan sees depends on negotiation	Adds the key to the asset; nothing is replaced, recorded as a change or notified
Hardware address and keys	IP address, and the old address has not been seen for two days	The device moved	Keeps the sighting on the asset, releases the old address and records the new one
IP address	Hardware address (and host key)	A different device now answers there	Creates a merge proposal in Discovery → Approvals, as for any ambiguous evidence
Hardware address	SSH host key (same type), TLS certificate and name	The device was reimaged	Keeps the sighting on the asset, replaces the old key of that type and records the change
IP address only (no hardware address seen)	SSH host key	Decided by what else is known: the TLS certificate, the name and the set of open ports	All unchanged: rotated. All changed: a merge proposal. Nothing else known: kept on the asset and flagged for review, with both keys kept

An address you or the host's agent pinned (see pinned addresses) is never treated as having gone silent, so a sighting elsewhere does not release it. A key whose type was never reported (for example, one recorded before the platform stored key types) is never treated as rotated and never replaced; at most the change is flagged for review.

Each of these appears on the asset's History tab as a sentence that names the old and new values (for example, "SSH host key rotated", with both fingerprints), and every case but a different device sends a notification you can route under Settings → Notifications & Alerts → Routing Rules with alert source inventory-service and alert type asset_identity_drift. An address that changes inside a network that hands out addresses dynamically (DHCP) is recorded but not notified, because that is what DHCP does. None of these are compliance findings: they describe something that happened to the device, not a control that is failing.

The cryptography lenses¶

Certificates¶

Every certificate in your inventory, one per row — common name, issuer, key algorithm and size, expiry, and how many places it's deployed. This lens lists all certificates, including ones you've uploaded manually (shown as unassigned until they're linked to an asset), not just certificates discovered by a sensor. It's sorted by expiry so the certificates closest to expiring float to the top, and an Ownership filter lets you narrow to internal vs. third-party certificates.

Use it when you're managing certificate lifecycle — renewals, expiry sweeps, finding weak key sizes, or confirming an uploaded certificate landed.

Keys¶

A dedicated inventory of every cryptographic key discovered across your environment — key type and size (or curve), lifecycle state, expiry, and how many assets use each key. A key marked Unlinked is in inventory but isn't (yet) referenced by any discovered configuration — expected for imported or newly-catalogued key material, and tracked here so nothing is invisible.

Use it when you're running a key-length policy audit, reviewing lifecycle state, or tracing the blast radius of a weak or compromised key. (See the dedicated Cryptographic Keys guide for the full column reference.)

Configuration¶

Every discovered Crypto Configuration, grouped by the numeric risk bands — Critical, High, Medium, Low, Informational — plus Not assessed when no numeric evidence establishes a score. Critical opens first so the highest numeric risk is in front of you. Each row shows the host, protocol and version, cipher suite, key details, and hash. The Risk band filter uses those same groups. Catalogue strength remains separate evidence and is not inferred from the score.

Use it when you're hunting for weak or deprecated crypto — outdated TLS versions, weak ciphers, small key sizes — across everything at once.

3rd Party¶

Outbound connections your assets make to external endpoints — SaaS providers, partners, APIs. This is its own dataset (not your internal assets): each row is a destination your environment talks to over TLS, with the protocol, cipher suite, crypto strength, certificate expiry, and when it was last seen. Where you have the right permission, you can Elevate a connection to bring it into managed inventory, after which it's tracked like an internal asset and the row shows an "Elevated" badge.

Use it when you're assessing third-party crypto exposure — are the vendors and services we depend on using strong TLS? (See Third-Party and External Connections for detail.)

Data Protection¶

At-rest encryption posture across every resource that stores data — object stores, managed databases, and AWS Secrets Manager secrets. It is a property lens rather than a family of things: the question is "is this data protected, and by whose key?", and the answer is the same shape whether the resource is a bucket or a database.

Each row shows the resource, its type, its encryption state, key custody (who holds the key — the provider, or you), the origin of the answer, and whether it was verified. Encryption state has three values, not two: Encrypted, Not encrypted, and Not assessed — drawn deliberately neutral so it can never be read as either verdict. Filters for resource type, assessment and risk sit in the toolbar.

An empty lens means nothing has been inventoried, not that everything is encrypted. Object stores, databases and secrets arrive here from a cloud discovery.

The nightly risk pass reads this lens too. A resource whose data is not encrypted raises a Critical Unencrypted at rest finding on its asset. An encrypted resource raises nothing, whoever holds the key — key custody is shown here, not scored as risk. A resource whose encryption could not be read (for example, the scan was denied permission) raises nothing and its asset stays Not assessed on the Dashboard rather than being counted as clean.

Use it when you are answering "is our data encrypted at rest, and who holds the keys?" — for a questionnaire, an audit, or your own peace of mind.

Stale¶

Assets nothing has observed for more than 30 days. Each row shows the asset, its class, its prefix, its status and how many days it has been quiet, with per-row Rescan and Archive actions on the right and a bar above the table that acts on the whole page at once. The staleness cut runs across the whole inventory, so the count and pagination reflect every stale asset, not just the current page.

Staleness is a property of the asset — of when the host was last seen — and it is a claim that nothing has looked recently, not that the thing is gone. Individual endpoints go stale on the same 30-day boundary and are marked so on the asset's Services & Endpoints tab; an endpoint is only ever marked closed by something that actually looked and found nothing listening.

Use it when you're cleaning up — retiring decommissioned hosts, investigating assets that dropped off the radar, or keeping your inventory honest. See Asset lifecycle management for the actions and the thresholds behind them.

TLS and SSH¶

Two protocol sub-lenses beneath Configuration. They show the same flat Configuration view, pre-narrowed to a single protocol — TLS or SSH — so you can focus on one without setting a filter.

Use it when you want a clean, protocol-specific list — e.g. reviewing every SSH configuration in one shot.

Drilling into a row: the detail drawer¶

Click any row to slide open a detail drawer with the full record. Drawers stack — you can drill from one record into a related one without losing your place, and each drawer paints on top of the last. The top drawer closes first (press Esc or click the dimmed background), peeling back one layer at a time:

From a key, jump to the asset that uses it.
From a certificate, jump to the asset it's deployed on.
From a crypto configuration, jump to its asset or its certificate.
From an asset, expand into its configurations.

This is how you answer "what depends on this?" questions: start anywhere and follow the relationships, with every step you took stacked behind you.

Why a configuration scored what it did¶

A crypto configuration's drawer carries a Why this score section under its Assessment rows. It names the component that set the score, shows each component's catalogue assessment, marks whether the component was observed in use or only offered, not observed, and surfaces the catalogue's migration guidance for the offending one. A component whose catalogue row records remediation guidance also gets a How to fix section with the fix steps, suggested timeline, CVE references and links. When nothing resolved against the catalogue it says not assessed — which is not the same as safe. See Crypto Risks → Seeing why a configuration scored what it did.

Exporting the current view¶

The Export button in the toolbar downloads exactly what you're looking at — the current lens, with your active filters and search applied — as a CSV. Each lens exports the columns that make sense for it: certificates export issuers and expiry; keys export sizes and fingerprints; configurations export cipher suites and algorithms; Stale exports class, network, status and last seen. The file is built right in your browser from the rows already on screen, so there's no waiting.

You will find it on the Certificates, Keys, Configuration, TLS, SSH, Data Protection, 3rd Party and Stale lenses. Map has its own export — a graph, in GraphML or Cytoscape JSON, rather than a table.

Exports are convenience, not evidence. A page-local CSV is perfect for a quick spreadsheet pivot, a key-length sweep, or sharing a snapshot with a teammate. It is not an audit-grade artifact: it has no provenance, no content hash, and no fixed scope boundary. When you need something an auditor can rely on — reproducible, hashed, and tied to a defined boundary — generate a CBOM artifact instead. (See Page-Local Exports for the distinction, and CBOM Artifacts for audit-grade output.)

Where the old lenses went¶

Two lenses were absorbed by the class facet on All assets, and their bookmarks redirect there:

Was	Ask for it now
Infrastructure	All assets — it is the asset list, with a class facet on top
Network	All assets, filtered by Prefix in the rail (or `prefix_id:` in the query)