Tenant User Guide

Version: 3.0 Last Updated: 2026-09

This guide walks through Vista Platform the way you actually use it: from the left navigation rail outward, one section at a time, as a sequence of tasks. Each part tells you where to click, what you will see, and links to the feature page that carries the full detail.

It covers what a tenant user does day to day. Configuration that belongs to a Tenant Admin — members and roles, connected systems, notification channels and routing, retention, locations and prefixes, billing — lives in the Tenant Admin Guide, and this guide points there rather than repeating it.

If a term is unfamiliar — asset, endpoint, class, relationship, fact, finding — Concepts defines the vocabulary the whole product uses.

---

Table of Contents

1. Getting Started
2. Dashboard
3. Discovery
4. Inventory
5. Risk & Compliance
6. Remediation
7. Global Search and Ask
8. Notifications
9. Organization Settings at a Glance
10. My Profile
11. Troubleshooting
12. Support

---

Getting Started

First sign-in

You reach the console one of two ways:

• An invitation email from someone in your organization. Click the link, set a password, and you land on the Dashboard.
• Self-service signup, if your deployment offers it. You create the organization, verify your email address, and become its first administrator. On most installs this is only open until the first organization exists; after that, people join by invitation.

Either way, the first thing worth doing is the setup checklist — see The setup checklist below.

Signing in

The sign-in page asks for your work email first, then adapts to what your organization allows.

Password. Enter your email, then your password, and continue. Choose Forgot password? on the sign-in page, enter your email, and a reset link is sent to that address if it has an account. The page gives the same answer whether or not the address is registered, so check your inbox (and spam folder) rather than expecting an error.

Single sign-on is an Enterprise capability. On a Core deployment, email and password is the only way in and the rest of this subsection does not apply.

Finding your way around

The console has a left navigation rail with five sections, ordered as the lifecycle of an asset:

Section	What it is for
Dashboard	Where you stand right now — two heroes, a triage strip, and the lifecycle end to end
Discovery	Finding things: sensors and agents, jobs, devices, scans, the review queue, and file/cloud sources
Infrastructure	Everything the platform tracks: assets, facilities, networks, compute, catalogs, and cryptography
Risk & Compliance	Posture, findings, and the evidence documents you hand an auditor
Remediation	Fixing what was found: alerts, the ticket queue, and plans

Click a section to open it; its sub-navigation appears beneath it in the rail. Most Infrastructure sub-items are lenses — views over the same inventory. Operational catalogs and registries open focused workspace pages in the same section.

Settings and My Profile are not in the rail. Click your account chip at the bottom of the rail to open the profile menu:

• Getting Started — the setup checklist, shown while onboarding is in progress
• My Profile — your own account
• Organization Settings — everything your organization configures
• About — the running version and build
• Switch to Light Mode / Switch to Dark Mode
• Sign out

On a narrow screen the rail collapses behind a menu icon in the header; tap it to slide the same navigation in, tap a link to go, and it closes itself.

The setup checklist

Profile chip → Getting Started opens a short checklist that makes the platform useful faster. It tracks three steps:

1. Add prefixes — so discovery is scoped and results carry location and environment context.
2. Add locations — so assets can be organized by site or cloud region.
3. Add an agent — register a sensor or discovery agent so things start being found.

Each step has a button that takes you to the page that does it, and a way to mark it done by hand if you already did it elsewhere. Dismiss setup guide hides the reminders for you only; the page stays reachable from the profile menu.

The first two steps need settings permissions and the third needs permission to register a sensor, so a read-only user is never nagged about them. Full detail: Getting Started.

---

Dashboard

Dashboard is the standing answer to "how are we doing?" It has two heroes, because two different people read this page: one cares about cryptographic posture, the other about whether the inventory is any good.

The cryptographic posture hero

The top band shows a risk index out of 100 — the share of your assets sitting at high risk — with the risk level beside it, and a sentence naming how many critical findings are open across how many monitored assets. Under it, four figures: Assets, Configs, Critical, and PQC configs.

Beside it, Posture trend · 30 days plots the same risk index over time; lower is better. On the right, External Exposure counts observed third-party connections and the internal hosts making them — click it to open the 3rd Party inventory lens.

The Assets Monitored hero

Directly beneath, Assets Monitored answers the operations question. It leads with the number of assets under monitoring — whatever they are made of, not only the things that speak TLS — and two lifecycle counts you can click:

• Pending approval — discovered assets waiting for someone to accept or deny them; this links to Discovery → Approvals, the one review queue.
• Stale — assets not seen recently. Still in the inventory, still counted.

By class breaks the inventory down by asset class, with a Topology link into the map's tenant-wide view. Data Quality shows your Inventory Hygiene score with how many checks pass, fail, and were not assessed.

A count that could not be loaded shows an em dash and "Couldn't load", never a zero. A reassuring zero on a failed read is the one thing this page must not say.

Needs attention now

A strip of clickable tiles, prioritized across every section: Critical findings (all producers), High-risk assets, Certs expiring within 30 days, Not assessed (assets with crypto on record that nothing has scored yet), Not PQC-ready, Not yet assessed, and Overdue tickets. Each opens the filtered list behind it.

The lifecycle, end to end

Four stages — Discovery, Infrastructure, Risk & Compliance, Remediation — each showing its own headline number (sensors online, crypto configurations, critical findings, overdue tickets) and linking into that section.

Below that, Certificate expiry outlook and Quantum readiness give the two supporting views most people come back for.

Full reference: The Dashboard.

---

Discovery

Discovery is how things get into the inventory. Everything under it either finds assets, or decides what to do with what was found.

Command Center

Discovery → Command Center is the section's front page. Four stat cards — Fleet online, Jobs running, Failed jobs, Pending approvals — each link to the page behind them, and two panels list your Sensor fleet and Recent jobs.

Two buttons in the header start work immediately:

• Discover assets — opens the scan dialog (see below).
• Import from spreadsheet — brings in a CSV or Excel file of assets or prefixes. See Spreadsheet Import.

To run a discovery scan: click Discover assets — it finds everything that answers on a host or a network — then

1. Type Targets — one per line or comma-separated; IP addresses, CIDR ranges, a-b ranges, hostnames or URLs, up to 1000. A single CIDR or range can cover at most 4,096 addresses (a /20) and one scan 16,384 in all; a larger network is refused with the count, so split it into smaller blocks. For IPv6, list individual addresses: an IPv6 network is too large to sweep.
2. Choose a Scan depth. You do not pick protocols — services are identified from what answers.
3. Quick — crypto and infrastructure ports only; the fastest look.
4. Standard (the default) — about 1,400 common TCP ports plus common UDP services.
5. Thorough — all 65,535 TCP ports plus common UDP services. It can take a long time.
6. Custom — you choose the ports, under Advanced.
7. Choose where it Runs from: Auto (one of your sensors when that sensor serves every target, otherwise the platform sensor), the Platform sensor, or one of your sensors by name. A sensor that has stopped checking in is listed but cannot be chosen, and one whose software cannot run a scan by depth is refused in the preview with Run from the platform sensor instead (Auto never picks such a sensor, and says what it chose). The platform sensor reaches only what the platform can route to; to scan a private network from the inside, run from a sensor on it.
8. Advanced (closed until you open it) holds:
9. TCP ports and UDP ports for Custom: ports and ranges such as 22,443,8000-8100. A mistake is pointed out as you type, in the same words the platform would use. For the other depths these show the ports the depth covers, read-only. UDP is probed per service: a UDP port with no known probe reports no answer, never closed.
10. Pace — Polite for fragile or closely monitored networks, Normal, or Fast for a well-provisioned LAN (it may report slow ports as filtered).
11. Probe industrial (OT/ICS) devices — off unless you tick it and choose Modbus, OPC UA, EtherNet/IP or BACnet, and never part of a depth. It sends only each chosen protocol's documented, read-only identification request, to its standard port, one connection at a time per device. Industrial controllers can be fragile: probe them only with their owner's agreement. The box is not shown if your administrator has turned OT probing off.
12. Read the Preview, which appears once the form is complete: how many addresses and ports, a rough duration as a range (an estimate, not a promise — checking which addresses are alive usually removes many from a sparse range), where the scan will run and why, and any target that will be scanned at less depth than you chose. A target outside your registered networks is scanned at Standard at most; if the range is yours, register it under Infrastructure → Networks & IPAM and it is scanned at the depth you choose. A scan too large for one job is refused here, with the numbers. If the preview cannot be worked out, you can still start.
13. Click Start discovery. Targets outside your registered networks ask you to confirm first. The dialog then says what started and where, with View in Discovery Jobs, which opens that scan's detail. Close it whenever you like — the scan does not depend on it. Discovery → Discovery Jobs shows its progress, lets you stop it, and shows what it found.

What it finds flows into your inventory automatically: hosts on a prefix marked auto-approve are monitored straight away, everything else waits in Approvals.

An address that sends nothing back is reported as no answer, not as empty: it may be switched off, filtered by a firewall, or out of reach of where the scan ran from. If a whole network gives no answer from the platform sensor, run the scan from a sensor on that network.

Sensors & Agents

Discovery → Sensors & Agents is where the fleet lives. Two tables, because they are two different things:

Sensors — the passive capture binaries deployed on your network. Columns: Sensor, Type, Network, Assets found, Version, Status. A coloured dot shows online/offline based on the last heartbeat.

Discovery agents — the command-driven binaries that log in to network devices (F5, Palo Alto, Cisco, Fortinet and so on) and read their configuration. The table is hidden entirely if you have none. Columns: Agent, Host, Interrogates, Jobs, Version, Status. Host is the address the agent reaches the platform from, plus a count of the other addresses its host holds — hover for the full list with network prefixes, which answers which prefixes the agent can actually reach. Jobs shows when it last ran work and how many it has run; one that never has reads "Never run".

An agent that has stopped sending heartbeats shows as offline even when its stored status still reads active. The heartbeat is the truth.

To register a sensor or agent: click Register sensor or agent, fill in the name and expected address, and generate a registration key. The installation instructions that follow are platform-specific (Linux, Windows, macOS) and include the key. Keys expire, so install before the countdown runs out or generate a new one.

Platform-managed sensors appear in the list with a lock rather than a delete button. They are shared platform resources — the in-cluster sensor and the platform interrogation agent — and the discovery counts you see beside them are your organization's alone. Deleting one is not offered, and would be refused.

To remove a sensor or agent: click the ✕ on its row and confirm. Removing an agent revokes its certificate, returns its queued jobs to the pool for another agent, and marks any job it was mid-way through as failed. It does not uninstall the binary — stop and remove that on its host separately, or it will keep trying to check in and logging rejections.

The sensor drawer

Click any sensor or discovery agent row to open its drawer. Sensors and agents share one layout — Overview · Discoveries · Health · Jobs · Logs · Settings — and each shows the tabs it supports: an agent has no Discoveries tab, and a platform-managed sensor shows the first two only.

• Overview — status, last heartbeat, reporting interval, version, address, deployment (connected or air-gapped), uptime, monitored interfaces, and the sensor's certificate with its serial, issue and expiry dates.
• Discoveries — what this sensor has found: protocol, destination, port, confidence, timestamp.
• Health — opens with a Connection block on both: online or offline, last heartbeat, version, and whether the device has taken its settings. A sensor then shows current metrics plus a History chart over a range you choose. If the sensor reports them, a Host observations block shows Hosts seen, Shed, and Accumulating now: devices seen on the wire without connecting to them, each of which becomes a pending asset in Approvals. A non-zero Shed count means the network is busier than the sensor is sized for — that is actionable, not cosmetic. An agent shows its recent job outcomes and its last host inventory instead.
• Jobs — the last 10 jobs, one line each with a status. Click one to see its timing, payload and reply. A sensor can also Send a command here.
• Logs — Fetch logs asks the device for its recent log lines and shows them as text once it checks in, with credentials masked.
• Settings — the managed settings, their change history and Restart. A sensor's also holds its network interfaces, description, tags and reporting interval.

Full reference: Sensor Registration & Management.

Discovery Jobs

Discovery → Discovery Jobs (under Activity in the rail) lists every job: id, type, target, source, how many assets it found, duration and status. Under the status, an interrogation's row says what the run produced — "12 instances, 3 network prefixes", "412 packages, 18 listeners", "5 awaiting approval" — and a failed run shows its own error message. A failed or cancelled interrogation can be retried from its row; a running job can be cancelled. If a cancel is refused — the job finished in the meantime, say — the page says why. Click a row for the run detail.

A scan started with a scan depth reads in plain words — Queued, Waiting for sensor, Running, Finished, Failed — stopped responding, Cancelled — and while it runs its row shows a progress bar and a live line such as "112 of 254 hosts · 31 responded · 9 open ports", with where it runs and its depth. The page refreshes itself while anything is still running.

Resume scan (the play button on a failed or queued scan's row) puts the scan back in the queue: only the hosts it had not finished are scanned again; hosts already finished, and what they found, are kept. A scan that stopped responding (no heartbeat from the scanner) is the usual reason to resume. It needs the discovery.create permission, and the scanner also checks discovery.update; if either is missing, or the scan is no longer failed or queued, the dialog shows the reason.

The detail of a scan started with a scan depth refreshes every few seconds until it ends, and shows, top to bottom:

• What this scan does — depth, pace, ports, targets, where it ran and why (Auto says what it chose), and every target scanned less deeply than you asked, with the reason (for example, a target outside your registered networks is scanned at Standard at most — register the range if it is yours).
• Coverage — "254 addresses · 31 responded · 223 no answer", and the ports open, closed and filtered. No answer is not "down": a firewall that drops everything looks exactly like an address with nothing on it. If nothing answered at all, the detail says the scanner may not be able to reach that network and suggests running the scan from a sensor on it. A scan that ended early says where it stopped and why (cancelled, stopped responding, sensor offline).
• Results by host — every host that responded, a page at a time, so the count matches Coverage. Click a host for its ports: the service on each, or open, unidentified when nothing could name it (with a hint such as "looks like smtp" when the service greeted us), and the certificate and cipher detail for TLS. A host that answers on every port — usually a firewall or proxy — is one line with a few sample ports instead of thousands of rows. A host that answered with nothing open is one quieter line, such as "answered, nothing open (78 ports scanned: all refused)" — refused means it is there and nothing is listening.
• Findings — Open ports found ("15 open ports on 10 hosts"; a finding is an open port, not an asset), and where they went: how many were auto-approved and how many wait in Approvals. Findings that could not be tied to an asset yet — for example an address on a network that uses DHCP, where an address alone does not identify a device — are kept as observations; the detail says how many and links to Discovery → Observations, where you confirm, link or dismiss them.

Devices

Discovery → Sensors & Scanning → Managed Devices lists the assets you have given the platform credentials for, so it can log in and read their cryptographic configuration directly. Every device here is also an asset in Inventory — this page is where its management settings live.

Columns: Asset, Management address, Class, Interrogator, Firmware, Last interrogated, Connection. Per row you can open the asset's page, interrogate it now, test the connection, edit its management settings, or stop managing it.

Add device adds to the list: give the device type, management address, username and password, and the platform connects and fills in the rest. If it can't connect, the form says why and lets you add the device by hand.

Stop managing is not delete. It removes the management configuration and its credentials. The asset stays in Inventory with everything ever discovered about it. An asset discovered through a cloud integration has no management credentials, so interrogate and test are unavailable on it.

See Device Interrogation and the Device Interrogation Guide.

Active Scan

Scanning assets you already have is done from Infrastructure. Infrastructure → All assets → Views → Never scanned lists assets that have never been actively scanned — typically ones that arrived by import, by SBOM, or from a CMDB. Tick them (or Select all matching) and choose Scan in the bar above the list; pick where the scan runs with Run from. The results flow back through the normal discovery pipeline.

While an asset's scan runs its row shows Scanning…; it leaves the Never scanned view once the scan has finished, even when nothing answered on the host. One whose scan could not reach the host stays, marked Last scan failed, so you can try again. The former Discovery → Active Scan page is now this view. See Working with many assets at once.

Scheduled Scans

Discovery → Scheduled Scans turns interrogation into a recurring job. Click New schedule and give it:

• a Name and optional Description,
• when it runs — every few hours, daily, weekly on chosen days, or monthly, at a time of day in a time zone you pick (your browser's by default); or Custom for a five-field cron expression,
• a Target type and target: a specific device, or a cloud integration.

From the list you can run a schedule now, edit it, toggle it on and off, or delete it. The target is fixed once a schedule is created — to point at something else, create a new one.

Observations

Discovery → Observations holds evidence the platform kept but could not turn into an asset by itself — most often a host on a network that uses DHCP, where an address alone does not identify a device. An observation is not necessarily a distinct device, and it is not in your inventory.

The page opens on Ready to confirm. Chips across the top show the other groups, each with a count: Matches an asset, Several match, Needs a network, Needs a sensor, Likely noise and All. Under All, a State control also shows observations already linked, dismissed, expired or in an identity conflict. The page remembers the chip and the rows-per-page you last used, in this browser.

Each row is one line: the host (its name, or its address) with the services it answered on, the network it was seen on, the sensor or source that saw it, when it was last seen (hover for the exact time), and what it needs. Search by address, name, network or sensor; click Host, Network, Last seen or Needs to sort.

What each Needs means:

• Ready to confirm — a real device answered at this address, but the network uses DHCP, so the platform will not decide on the address alone, and none of your assets owns the address or anything else seen with it. Confirming says you recognise it; the asset is then created and follows its network's approval rules.
• Matches an asset — the address (or another identifier, such as a hardware address) already belongs to one asset you have, so confirming would only create a second record of the same device. The row says Link to that asset's name; linking attaches the observation to it and keeps its approval and history. This answer comes first: a row that matches an asset is offered as a link even when its network is not set up or no sensor can reach it, because linking needs neither.
• Several match — its identifiers belong to more than one existing asset (or to one that is archived or denied), so the platform cannot tell which it is. There is no one-click action: compare those assets (merge them if they are the same device), link the observation to the right one yourself, or dismiss it.
• Needs a network — the address is not inside any network you have set up. Add network opens Infrastructure → Networks & IPAM; one prefix covering the range resolves every host in it. (A row with only a hardware address and no network address is not asked for a network — no prefix could cover it — and shows as Likely noise instead.)
• Needs a sensor — another device advertised this name, or no sensor can reach the network it was seen on. See options explains: install a sensor on that network (from Sensors & Agents) and the platform confirms it without you, or link it to an asset or dismiss it.
• Likely noise — only a name was seen, only a hardware address with no network address, nothing answered, or nothing has seen it for 30 days. Dismiss is suggested.

Click a row to open it. On the left is all of its evidence: its identifiers, every endpoint, first and last seen with the number of sightings, enrichment status and which sensor can reach its network. On the right, What this needs says why the platform did not create an asset itself, what will fix it, and the alternatives: Link to an asset, Dismiss, and — for a DHCP host — Treat this network as stable…, a shortcut to Networks: if addresses on that network do not move, set its DHCP to off, and future scans can create and approve assets there directly.

Deciding many at once. With asset-edit permission, tick rows (or the header box for the whole page). A bar shows how many are selected and the actions that fit the selection: Confirm only when every selected row is Ready to confirm, Link to existing only when every selected row Matches an asset (each is linked to the asset that already owns it — you never choose one in bulk), and Dismiss for any selection. Linking to an asset you choose yourself is one row at a time. Confirm opens "Create 14 assets — each then follows its network's approval rules"; Dismiss is a plain confirmation. Both carry one reason for the batch, already filled in from what was seen — edit it as you need; it is recorded with every decision. The result is reported per row ("14 confirmed, 2 need another look"): a row that could not be decided — the asset allowance is reached, or it changed since you looked — stays in the table with the reason on it.

A single row's Confirm… and Dismiss… open the row with the same proposed reason filled in. Without asset-edit permission the page is read-only.

Approvals

Discovery → Approvals is the hinge between Discovery and Inventory, and it is the one queue for every proposal. Nothing waits for review anywhere else.

A Source facet across the top says where each item came from, which is the first thing worth knowing because it decides how much scrutiny is owed: Discovered (a sensor or scan saw it), Imported (spreadsheet), Declared from SBOM upload, Pulled from CMDB, Proposed by matcher, Proposed by classifier, Proposed by assistant. Click a chip to filter; Clear removes the filter.

Five kinds of row can be waiting:

Discovered assets. A table of things found but not yet admitted: name, address, class, prefix, source, confidence, when it was found. Accept admits it — and materializes its deferred certificates and crypto configurations into Inventory. Reject denies it and suppresses rediscovery. Accept all (or "Accept these n" when a source filter is on) decides the whole visible set at once.

Merge proposals. "This looks like something you already have." The matcher thinks a new sighting and an existing asset are the same thing, and shows you the candidates with a match percentage and the identifiers they share. Merge as is applies the recommended merge — the highest-scoring record survives and the rest fold into it — and the survivor's History records what was merged in. Review merge opens that recommendation so you can change the survivor, leave a record out or resolve a conflicting field before merging. Keep separate says they are different things; the matcher will not propose it again, and the discovery goes back to waiting for ordinary approval. A reason is optional on every merge; who decided is recorded regardless.

Relationship proposals. A claim that two assets are connected in a particular way, read left to right: this → relationship → that, with a confidence bar and how many times it was observed. Accept confirms it, and it starts counting in impact analysis. Reject records the decision so the same claim is not proposed again. See Relationships.

Class proposals. A claim about what an asset is: current class → proposed class. Where the evidence was ambiguous you get Candidates to choose between before accepting. Accepting sets the class and records which rule — or which model — decided it. Rejecting stops that class being proposed again.

Proposed cables. When a device reports an LLDP or CDP neighbour, the platform proposes the cable between the two ports — read left to right, near end to far end. Approve makes it an active cable and computes its paths; Reject keeps it as rejected so the same pairing is not proposed again. See Cabling.

Merged automatically. Lists the merges that already happened inside the recent window without a person deciding — each marked Auto-accepted by the matcher (with its score and reasons; only if your organization has raised the auto-accept threshold above zero) or Merged by rule (two records fixed rules were sure are one device, with the evidence and a link to the asset they were merged into; on unless your organization turned it off). It is deliberately not a queue: there is nothing to decide, no buttons, and no way to reverse one from here. A Change these settings link goes to the settings that allowed it. When nothing has been merged the section says so.

If one of these reads fails, the page tells you so instead of showing an empty section. "Nothing awaiting review" is a claim about the whole queue, and it is only made when every read succeeded.

Full detail: Asset Approval.

Sources

Sources is a group in the rail, not a page. Three ways to bring data in that are not a sensor:

Cloud

Discovery → Cloud connects AWS, Azure and GCP accounts and discovers the cryptographic assets in them. Add an integration, then from its row: run discovery now, test connection, edit, or remove.

Each provider asks for its own credentials — for AWS, a role to assume or an access key; for Azure, its tenant and client details; for GCP, a project and service-account key. See AWS, Azure and GCP.

PCAP Upload

Discovery → PCAP Upload takes a packet capture and extracts cryptographic configurations from the handshakes in it. Drop a .pcap or .pcapng file on the zone, or click Choose file. Recent uploads underneath shows each file with its size, packet count, how many discoveries it produced, and when.

This is the route for a prefix no sensor covers — a capture taken elsewhere becomes inventory. See PCAP Ingestion.

SBOM Upload

Discovery → SBOM Upload takes a bill of materials — CycloneDX JSON 1.4–1.7 or SPDX JSON 2.2/2.3, up to 32 MB — and turns its components into software inventory. The format is read from inside the document, not from the filename.

First say where the document belongs:

• An existing asset — the host, container or application this software runs on. Search for it by name and pick it.
• Create an application asset from the document — the artefact the document is about becomes an application asset, waiting for approval. Uploading the same artefact again lands on the same asset rather than making a second one.

Then drop the file or click Choose a document. When it finishes you get a summary, a link to the asset's Software tab, and — if the upload created an asset — a link to Approvals. Anything skipped is listed with the reason.

See SBOM Upload.

---

Inventory

Infrastructure is one list of everything, reshaped by lenses. The lenses are grouped in the rail exactly as they are here.

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 cross-link to Discovery → Approvals)

The infrastructure lenses each have a guide: Networks, Sites, Racks, Cabling, Circuits, Clusters, Tunnels and Changes.

Pending carries an arrow because it leaves the section: pending assets are reviewed in Approvals, and a second queue here would be a second inbox.

Reference: Inventory & Lenses.

All assets

The default lens, and the one that answers "what is out there". It has three controls above the table and a facet rail beside it.

The filter rail (left) builds the query for you. Facets: Class, Status, Environment, Site, Prefix, Owner, Business unit, Tag, Risk, Provenance, and a findings toggle. Each value carries its own count.

• Class is a tree. Picking Hardware selects everything beneath it; drill down to Server to narrow. Only one class at a time — the taxonomy is a hierarchy, and a multi-select over it reads as nonsense.
• Status is Monitoring / Pending approval / Denied / Archived.
• Risk bands are Critical, High, Medium, Low, Informational and Not assessed — a separate band, because "we have not scored this" is not the same claim as "this is fine".
• Provenance is how the class was decided: Discovered (something measured it), Declared, Imported, Proposed.

Values within one facet are OR-ed; different facets are AND-ed.

The query box (top) holds the same thing the rail writes, in one readable line. You can type in it directly: it autocompletes fields, operators and values, and a query it cannot parse tells you where it is wrong and what to write instead, rather than just "invalid". The rail and the box are never two different filters — the query is the state, and the rail is a way of writing it.

Query applied. Under the box, the predicate the server actually ran. It is often not identical to what you typed, because the read path adds its own default scope — status:monitoring, which steps aside as soon as your query names a status itself. When the two differ you get a not what you typed marker explaining why. This is how you find out that the asset you expected is missing because it is still pending approval.

Saved views (the Views button) name a query so you can come back to it, or share it. Build a filter, open the menu, and choose Save current query… — give it a name and decide whether to share it with your organization. Shared views carry a marker; only the owner can delete one. Only a query that parses can be saved: a saved view is a predicate other people will run.

The language is documented in full at Query.

Other controls. New asset (top right) creates one by hand. The header strip shows the running count, and a warning band appears above the table whenever items are awaiting review, with a Review button into Approvals.

The empty state differs on purpose: a filtered no-match offers to clear the query, while a genuinely empty inventory offers the three ways to get some — run a discovery, import a spreadsheet, or add one by hand.

The asset page

Click any row to open the asset. Overview lives at the bare URL and each other tab deep-links, so the link you copy off the first tab is the short one. The tabs:

1. Overview — Identity (what this thing is called), Identifiers (every way it is known, each with its kind, value, source, confidence and when it was last seen; an address marked static is pinned, and still identifies this asset on a network flagged DHCP), the class attributes for its class, Risk, Context (environment, business unit, owner, support group, location, prefix — with via its gateway when the prefix's router has been interrogated), Status, and Tags. A router or firewall also shows Networks routed: each network it is the gateway of, its address there, the VLAN, DHCP, how many assets are on it (click for the list) and whether a sensor covers it.
2. Services & Endpoints — every network face it has: address, port, transport, service, exposure, status and last seen. An asset with no network face simply has none, rather than a fabricated port.
3. Interfaces — its physical and virtual interfaces, addresses and VLAN modes (Interfaces).
4. Ports — the faceplate, with Connect, Trace and the cryptography overlay (Cabling).
5. Hardware — device type, modules, inventory items and virtual chassis.
6. Relationships — what it is attached to, where each edge came from, and what is affected if it changes.
7. Cryptography — its cryptographic configurations, each drilling through to the protocol, cipher suite and certificate behind it.
8. Findings — what is open against it, and what was not assessed.
9. Software — what is installed, from a host agent or an uploaded SBOM.
10. History — reclassification, context edits, merges and approvals, recorded as they happen.
11. Changes — who changed each field, from where, with a diff, plus the journal (Changes and journal).
12. Config Context — the merged JSON that applies to the asset (Config contexts).

An asset placed in a rack also shows its Placement, and an asset with a device type, contacts or custom fields shows those on the page too.

The drawer

Clicking a row in a cryptography lens opens a drawer — the peek, rather than the whole record — and the drawers stack: configuration → asset → certificate, so you can drill in and close back out one layer at a time.

The asset drawer shows a risk gauge, the asset's identity and primary address, its cryptographic configurations, and its details. Open full page is the way out of the peek and into the asset page.

Acting on an asset

From the asset drawer:

• Active Scan — probe this asset now and catalogue its TLS cryptography. Results arrive once the probe completes.
• Edit — open the asset form.
• Delete — soft-delete. It leaves active inventory and can be restored.
• Restore — brings a deleted or archived asset back.

These need the matching permission; without it the button is simply not there.

Adding an asset by hand

New asset opens a form whose shape is decided by the class you pick, so pick that first.

1. Class — an indented list of the whole taxonomy. What you choose decides which attributes the asset has.
2. Display name — what a person calls it. Usually optional, because the platform derives one from the identifiers. For a service class it is required: a service identifies by its name, having no address or serial to be known by.
3. Identifiers — the ways this thing can be recognised later, so a future sighting updates it rather than creating a second copy. You can enter hostnames, FQDNs, IP addresses, MAC addresses, serial numbers, CMDB sys ids, SSH host key fingerprints and names. Two kinds are collector-minted — agent id and cloud resource id — and cannot be typed: they are identities the platform assigns, and being able to type one would let two real assets be merged into one by hand with nothing to review. An IP address you type is pinned: it keeps identifying this asset even on a network flagged DHCP. An address a sensor recorded shows a Pin box; tick it to pin that address too (for example a router's own LAN address inside the range it hands out).
4. Class attributes — the fields that class declares.
5. Context — Environment, Support group, Business unit, Owner email.
6. Description, Tags, and optional Metadata (JSON) for anything the class schema does not cover.

Click Create asset. If you ask to remove an identifier the platform must keep, it is kept and you are told which and why, rather than the removal quietly failing.

Editing an existing asset uses the same form, and the class is changeable — reclassifying something that was wrongly classed is an ordinary correction, and the History tab records it.

Uploading a certificate

Add certificate (in the header of the Certificates lens) adds an X.509 certificate by PEM — useful when no sensor covers the thing that presents it. Its Declare tab adds one you know exists from just its common name and expiry date, so you are alerted before it expires (see Certificate monitoring). On the Upload PEM tab, switch between Upload file and Paste PEM, drop or paste the certificate (a chain, leaf first, is accepted; 1 MiB maximum), set its ownership, and upload. The certificate is authoritative: its cryptographic details are extracted from it server-side rather than typed.

An uploaded certificate shows as Unassigned in the Certificates lens until it is linked to an asset. See Certificate Chain Management.

The cryptography lenses

Each has its own shape, a search box, and an Export button for the current view.

• Certificates — every certificate, including ones uploaded by hand, with an Ownership filter (3rd-party / Internal / Unknown).
• Keys — the key inventory: key, algorithm, state, expiry, and Used by, which counts the assets using it ("Unlinked" when none). The drawer drills through to the using asset. See Cryptographic Keys.
• Configuration — negotiated cryptographic configurations, grouped by the numeric risk bands Critical, High, Medium, Low and Informational, with Not assessed as its own group when no numeric evidence establishes a score. Filters for Environment and Risk band. The catalogue's qualitative strength is separate evidence and is not derived from the numeric score.
• TLS and SSH — the same configuration lens, narrowed to one protocol.
• Data Protection — at-rest posture across the resources that store data, with Resource type, Assessment and Risk filters. Each row names the key-custody rung it sits on.
• 3rd Party — outbound connections your assets make to SaaS, partners and APIs. A connection you decide to track like an internal asset can be promoted: click the promote control, confirm Elevate to managed?, and it joins managed inventory. See Third-Party & External Connections.

Map and Software

Map has two views, switched at the top of the page:

• Neighbourhood — an interactive graph around one focus asset, up to three hops, with the impact overlay and a GraphML/Cytoscape export. It also opens full screen, which returns you to the lens carrying your depth and selection rather than resetting.
• Topology — the tenant-wide "where is everything", as a site → prefix → class tree with counts.

Software is anchored on the product, not the asset: it answers "who runs this version of this thing?" Columns for product, vendor, version, end of life, vulnerabilities, identifier, licence, last checked, and the number of assets. Sort by any of them, search across name, vendor, Package URL and CPE, and click through to the assets. An Upload SBOM link sits in its header.

See The Map and SBOM Upload.

Stale

Infrastructure → Stale lists assets not observed for more than 30 days. That number is the product's one definition of stale: the lens, the hygiene finding and the compliance control all mean the same thing by the word.

Tick the rows to act on — or the header, then Select all matching — and use the bar above the list: Scan, Archive, Restore, Delete, Edit or Export. Archiving asks first and says what it does: archived assets drop out of active inventory and reporting, discovery can resurface them, and you can restore them.

Thresholds and auto-archive behaviour are set by a Tenant Admin under Settings → Policies → Asset Lifecycle. See Asset Lifecycle Management.

Exporting what you are looking at

Every lens has an Export button that writes the rows currently on screen to CSV, built in your browser from what is already loaded — no round trip, no template.

A page export is convenience, not evidence. For audit-grade output with provenance, a content hash and a fixed scope, generate a bill of materials instead (see below). Detail: Page-Local Exports.

---

Risk & Compliance

Posture

Risk & Compliance → Posture carries three views, switched from the rail: Overview, Frameworks and Algorithm Reference. The last two exist so a verdict is never a black box — you can always read why the platform rates something the way it does.

Overview

A gauge for the share of assets at high risk, Posture trend · 30 days, per-framework standing for each framework you have activated, a Control posture grid, and Highest-priority exposures ranked for you.

Reading a control result

On the control grid — and on each group under Findings → By Control — every control shows one of three results:

• PASS — the control was checked and nothing in scope violated it.
• FAIL — the control was checked and something violated it. One violation is enough, whatever its severity.
• Not assessed — the control was not checked, so no claim is made either way. Hover it to see why: no measurement rule configured, nothing in scope to check, or the check itself failed.

Severity (Critical / High / Medium / Low) rates how much a failure matters — it labels each finding and weights the score — but it never decides pass or fail. Scores cover assessed controls only and are shown with a coverage line such as "8 of 11 controls assessed". A framework with nothing assessed shows —, never 100%. Controls that could not be evaluated are left out of the score entirely: they neither reward nor punish you.

Frameworks

Browse compliance frameworks and, crucially, what each one actually measures. The view opens on My frameworks — the ones you have activated, which drive your compliance score — and an All published toggle reveals the full catalogue, each with a preview score showing what you would score against it today. Open a framework to see its controls; expand a control to read its measurement in plain language (for example, "Passes when RSA key size is at least 2,048 bits"). Nothing is marked failing without a rule you can read here.

Activating and deactivating frameworks is a Tenant Admin job, under Settings → Policies → Compliance Frameworks.

Algorithm Reference

A read-only catalogue of every cryptographic algorithm the platform knows about, with our assessment of each. Search or filter by strength (recommended / strong / acceptable / weak), status (current / deprecated / obsolete), or quantum (post-quantum vs classical). Click an algorithm for its strength, deprecation and post-quantum status, risk score, migration guidance, and the specific alternatives to move to. This is the same rating used to flag risk across your inventory — so when something is marked "weak", this is where you see why.

See Algorithm Reference and Framework Transparency.

Findings

Risk & Compliance → Findings is every open problem, from every producer.

Lenses

The rail groups the lenses by what they read:

Platform findings — the one findings table, every producer:

• By Producer (the default) — the only lens that shows every producer's findings without a framework in the way, and therefore the home of end-of-life and vulnerability findings. The producers are Compliance, Cryptography, End of life, Vulnerability, Configuration, Inventory hygiene and Drift.
• By Framework — grouped by the frameworks you have activated.
• By Control — grouped by control, with each control's pass/fail/not-assessed result.

Crypto findings — the cryptographic-risk stream, a different data set:

• By Severity, By Asset, By Category (protocol / algorithm / key size / certificate), By Date Observed.

The two scopes are counted separately and labelled, because switching between them changes the number on screen. That is not a counting bug: they are different sets.

Filtering

Above the list: a filter box, and filter chips for Open, Critical + High, Mine and Unassigned. A producer facet gives one chip per registered producer with its count under the current filters — a producer with no findings shows a zero rather than disappearing, because zero is an answer. Export writes the current view to CSV.

Arriving from a link that narrows to one subject or severity shows a banner saying so, with a way to clear it — a page that is filtered always says it is filtered.

The inspector

Click a finding to open the inspector. It carries the finding's evidence and, for some kinds, the same issue found elsewhere on your network, with a way to raise tickets for the set at once. Advisories and, for drift findings, a Baseline / Observed comparison appear where they apply.

The Workflow block is where you act:

• Status — New, Notified, Resolved or Suppressed. Choosing Suppressed asks for a suppression reason before it is applied.
• Assignee — assign the finding to a member of your organization, or leave it unassigned.
• Create ticket — opens a remediation ticket pre-filled from the finding. It lands in Remediation → Queue.
• Add to plan — attach it to an existing remediation plan, or create a plan and add it in one step.
• Override control (justified exception) — for compliance findings only. Disregards that control in future evaluations. A rationale is required and is audited.

The Remediation block above it always shows the standard guidance for that kind of finding — in every edition, with no model involved.

Full reference: Findings.

Bills of Materials

Risk & Compliance → Bills of Materials produces the documents you hand an auditor: immutable, dated, content-hashed snapshots of what matched a scope at the moment of generation.

The four kinds

Kind	What it contains
Cryptographic (CBOM)	Certificates, algorithms, protocols, keys and crypto libraries
Software (SBOM)	Every distinct software product installed, and the assets it was found on
Hardware (HBOM)	Every hardware asset, with vendor, model, serial and firmware
Full inventory	Every asset with its endpoints, relationships, facts and open vulnerabilities

All four share one pipeline: the same scope, the same content hash, the same comparison.

Generating one

Click Generate and choose:

• Kind — one of the four above.
• Scope — the boundary the artifact attests to. Scopes are named, versioned asset definitions managed under Risk & Compliance → Scopes; see Scopes.
• Name — optional. For an audit submission, name it after the engagement.

The artifact captures the scope's exact version, so it stays reproducible even after the scope is later edited.

The list

Each row shows name, scope, kind, when it was generated, entry count and size. Filters for kind and scope sit above. Click a row for the artifact drawer.

Downloading

Download offers the formats that kind supports:

• CycloneDX 1.7 — the canonical bytes, and what the content hash covers. Available for every kind.
• OCSF 1.9 events — JSON Lines for a SIEM: one Device Inventory Info per asset, one Vulnerability Finding per CVE. Offered for the full inventory kind only, because it is the only one with devices and CVEs to project.

Verifying

Verify in the artifact drawer recomputes the content hash (and the signature, where there is one) and reports the verdict. This is how you prove an artifact you were handed is the one that was generated.

Deleting

Delete soft-deletes an artifact. The row stays, so a comparison that referenced it shows "deleted" rather than a dead end.

Reference: Bills of Materials and CBOM Artifacts.

---

Remediation

Alerts

Remediation → Alerts is the inbox. Summary cards count Acknowledged, Snoozed and the rest; a severity filter and status filters narrow the list.

Each row names the alert, its type, its severity, and its subject — the thing the alert is about. Where the subject has a page of its own, it is a link: an asset goes to the asset page; a software install or a crypto configuration goes to Findings narrowed to exactly that subject; a control goes to the control lens; a certificate goes to the Certificates lens. Where there is no honest destination the subject is plain text, because a link that lands on an empty page reads as "nothing is wrong here" — the one thing it must never say.

Working an alert. Per row:

• Acknowledge — you have seen it.
• Snooze — put it aside until a time you choose, with a reason.
• Unsnooze — bring it back now.
• Resolve — close it, with a resolution note.
• Create ticket — turn it into remediation work in the Queue. A row whose ticket already exists links straight to it.

Click a row for the detail panel: the full message, the subject, and who acknowledged, snoozed or resolved it and when.

What raises an alert. These are the types that can open against your organization:

Alert	Raised when
Certificate expiring	A certificate is approaching, or past, expiry. One alert per certificate, escalating as expiry nears. Activated compliance policies can add earlier rungs.
Control noncompliant	A control in an activated framework went noncompliant. One alert per control, with the affected-asset count — not one per asset.
Compliance score drop	A framework's score fell more than 10 points in 24 hours.
Hygiene score drop	Your Inventory Hygiene score fell more than 10 points in 24 hours. Split out from the above because data quality is worth routing — and silencing — separately from security posture.
Known vulnerability	An installed software product matched the vulnerability catalogue.
End of life	Something on an asset passed, or is approaching, the date its vendor stops shipping fixes — its operating system, its hardware, or an installed package.
Drift detected	Something about a subject changed relative to its recent baseline: a new device class on its prefix, a protocol it has not spoken before, a different set of listening ports, a certificate from an unfamiliar issuer. Drift is not automatically bad — most are planned changes, and resolving the finding is how you tell the baseline so.
Sensor offline	A sensor stopped reporting, or registered and never reported at all (after a 15-minute dwell — measured from the last heartbeat, or from registration if there has never been one, so a sensor whose install silently failed is not invisible). Sensors marked air-gapped, pending or inactive are not expected to check in and do not raise this.
Discovery agent offline	A discovery agent stopped reporting, or registered and never reported at all (same dwell, measured the same way). Agents switched to inactive do not raise this.
Discovery job failed	A discovery job failed.
Failed login burst	Multiple failed sign-in attempts in a short window.
Asset limit approaching	Asset usage is nearing your plan limit.

Most resolve themselves when the condition clears — a renewed certificate is observed, a heartbeat arrives, the next run succeeds, the finding stops being detected.

Which alert types are enabled, and where they are delivered, is configured by a Tenant Admin under Settings → Notifications & Alerts.

Queue

Remediation → Queue is the single ticket queue: every remediation ticket in your organization, whatever raised it.

Five cards across the top double as filters: Open work, Overdue, Due soon, Resolved, and Keeping pace — the share of open work still on track. Click a card to filter to it, click again to clear.

The table lists ticket, category, external reference, SLA state and due date. Click a ticket for its drawer: description, due date, assignee, what it is linked to, and a threaded Comments section (⌘/Ctrl + Enter posts). Status changes are made from the drawer.

Categories are compliance, certificate, remediation, vulnerability, operational and general — each able to link back to the asset, certificate, configuration or finding it came from.

Plans

Remediation → Plans groups related work into one initiative — a post-quantum migration, a protocol deprecation, a certificate replacement programme — and tracks it as a whole. Click New plan, give it a title, and add findings to it from the findings inspector (Add to plan). A plan's detail view shows its steps and its progress.

See Remediation.

---

Global Search and Ask

Press ⌘K (Mac) or Ctrl+K (Windows/Linux) anywhere, or click the search icon in the header, to open the command palette.

Search is the default. Type two or more characters to search assets, certificates, devices and sensors at once; results are grouped by type. With the box empty it lists the pages you can jump to. Navigate with ↑↓, open with Enter, close with Esc, and ⌘K toggles it.

Full reference: Global search.

---

Notifications

The bell

The bell in the header carries a count of unread notifications. Open it for the recent list, mark one read by clicking it, or Mark all read. Two links at the bottom go to View alerts and View delivery history.

Your own preferences

My Profile → Notifications controls what reaches you, within what your organization has configured.

What you're notified about — per-category switches: Security findings & alerts, Sensors & discovery, Billing & subscription, System & maintenance, CBOM & compliance evidence, Members & access changes.

How it reaches you — In-app and Email switches, plus a Frequency: Immediate, Hourly digest, or Daily digest.

Click Save changes to apply.

You choose what and how often. The channels themselves — Slack, email, PagerDuty, a webhook — are configured for the whole organization, as are the routing rules that decide which events reach which channel and the alert rules that decide what raises an alert in the first place. Those live under Settings → Integrations and Settings → Notifications & Alerts, and are covered in the Tenant Admin Guide.

---

Organization Settings at a Glance

Reached from the profile chip → Organization Settings. What you see depends on your permissions and your edition; the detail for each is in the Tenant Admin Guide.

Group	Pages	In one line
Organization	Overview, Branding	Organization metadata, and white-labelling the console
Plan & Usage	Usage & Limits, Billing	Consumption against plan limits, and (on the commercial editions) the subscription itself
People & Access	Members, Roles & Permissions, Security & SSO	Who is in the organization, what each role grants, and how people sign in
Integrations	Integrations, AI assistant	Connected systems — CMDB/ITSM, messaging, storage, SIEM — and which AI capabilities are on
Notifications	Routing Rules, Alert Rules	Which events reach which channel and what raises an alert
Discovery & Reconciliation	Active Scanning, Identification rules	How the platform discovers and reconciles records
Policies & Trust	Compliance Frameworks, Custom Policies, Asset Lifecycle, Trusted CAs	The policy and trust decisions the platform applies to your data
Data & Schema	Custom Fields, Export Templates	Tenant-wide fields and export formats

Some of these belong to the commercial editions and are simply absent from the rail on a Core deployment: Billing, Security & SSO, Custom Policies, and SIEM export among the integrations. Core has local users, invitations, roles and the free frameworks, with no subscription to manage.

Three pages are worth knowing about as a user even though you may not administer them:

• Risk & Compliance → Scopes defines the asset boundaries a bill of materials attests to (Scopes).
• Infrastructure → Asset Classes browses the asset class taxonomy and the attributes each class carries — which is what the New asset form is built from.
• Policies → Identification rules shows how a new sighting is matched to an existing asset, and whether a high enough match may be accepted without you. That page's settings are what fill the Merged automatically section in Approvals.

Billing, retention, locations and prefixes are administrator work; the Tenant Admin Guide covers each.

---

My Profile

Reached from the profile chip → My Profile. Six pages.

Personal

Your identity. Edit First name, Last name and Timezone, and Save changes. Upload photo takes a JPEG, PNG, GIF or WebP up to 5 MB and applies it immediately.

Email and Role are shown but not directly editable: changing your email requires confirming a link sent to the new address, and your role is assigned by your organization's admins under Settings → Members.

Your data → Export downloads everything the platform holds about you, as a file you can keep.

Security

Password — enter your current password, a new one (8 characters minimum) and the confirmation, then Change password. You may be signed out afterwards and have to sign in again.

Multi-factor authentication — an authenticator app with backup codes is on the roadmap and will be enrolled from here. It is not available yet, and the page says so rather than offering a control that does nothing.

Account status — whether your account is active, when you joined, and your last sign-in.

Notifications

Covered under Notifications above.

Sessions & Devices

Every active session: device, IP address, last active, and when it was signed in. Your current session is marked. Revoke ends one session; Revoke other sessions ends every session except the one you are using — the right move after signing in somewhere you do not control. A revoked session stops working at once; your other devices quietly refresh their sign-in and carry on. Changing or resetting your password ends all your other sessions the same way, and you sign in again with the new password.

Connected Accounts

On a Core deployment there are no providers to link, so this page has nothing to show.

API Tokens

Personal access tokens for connecting AI assistants to the read-only MCP server. They work only with the MCP server — not with Vista Platform's other REST endpoints. New token creates one: name it, choose its scopes, and copy the value — the full value is shown only once, so put it in a secret manager immediately.

The table lists name, prefix, scopes, created, expires, last used and status. Revoke kills a token. Tokens carry a subset of read-only scopes, are owned by you, and you may hold up to 25 active at a time. See API Tokens & MCP Server.

Preferences and Accessibility appear in the design but are not in this build, so they are not listed in the profile rail. Theme is switched from the profile chip menu in the meantime.

---

Troubleshooting

"I ran a discovery and the inventory did not change." New discoveries wait in Discovery → Approvals and are invisible to every lens until accepted. Check the pending count on the Inventory header, or Pending approval on the Dashboard's Assets Monitored hero.

"An asset I know exists is not in the list." Look at the Query applied line under the query box. The default scope is status:monitoring, so anything pending, denied or archived is excluded until your query names a status itself. Add status:pending_approval (or archived, or denied) to see it.

"Two records exist for the same thing." That is what merge proposals are for — check Approvals. If no proposal was raised, the two records may share no identifier the matcher can compare; add one to each from the asset form, and the next sighting should link them. See Asset Approval.

"An asset was merged and I did not approve it." Check Approvals → Merged automatically. A row marked Auto-accepted by the matcher means your organization's auto-accept threshold is above zero; a row marked Merged by rule means the same-device rule was sure the two records were one device, and shows the evidence. The Change these settings link goes to the settings. There is no way to reverse a completed automatic merge from that page.

"A sensor shows offline but the process is running." Offline is decided by the heartbeat, not by the stored status. Check the sensor drawer's Health tab for the last heartbeat and the reporting interval, and confirm the host can reach the platform.

"Host observations show a large Shed count." The network is busier than the sensor is sized for, so observations are being dropped rather than emitted. That is a capacity signal.

"A compliance control says Not assessed." Nothing was claimed either way. Hover the result for the reason: no measurement rule configured, nothing in scope to check, or the check failed. Not-assessed controls are excluded from the score entirely.

"My compliance score has not moved after fixing something." Evaluation is continuous but not instantaneous, and catalogue rule changes take a few minutes to propagate. Check Findings for whether the finding cleared before assuming the score is wrong.

"A risk score reads 0." Zero means not assessed — nothing resolved against the algorithm catalogue and no size or lifecycle rule fired. It is not a claim that the thing is safe. The Not assessed tile on the Dashboard lists these.

"The Dashboard says some assets have no crypto observed." They are assets with nothing cryptographic on record: no crypto configuration, no encrypted store, no TLS, SSH or IPsec endpoint, and not a key or secret store. A phone or smart plug that a sensor saw only on the local network is the usual case. There was nothing to assess, so the Cryptographic Posture ring shows them as their own grey slice, apart from Not assessed. If you expected crypto on one, it usually means no sensor could see its traffic and no scan reached an open port on it.

"My saved views will not load." The menu says so and offers a retry; your views have not been deleted. If the query box shows an error, a view can only be saved when the query parses — fix the query and save again.

"I cannot see a page or a button that the documentation describes." Two possibilities. It may be gated by permission — your role does not grant it, and your administrator assigns roles under Settings → Members. Or it may be gated by edition — the capability belongs to Enterprise, in which case a deep link shows an upgrade card rather than a broken page.

---

Support

• In-product — About (profile chip) reports the exact version and build you are running. Quote it in any report.
• Concepts — Concepts defines every term this guide uses.
• Feature guides — the documentation index lists a page per feature; each goes deeper than this guide does.
• Administrator tasks — Tenant Admin Guide, and your organization's administrators for access, roles, connected systems, notification channels and anything else under Organization Settings.

When reporting a problem, include what you clicked, what you expected, what you saw, and the version from the About page.