Device Interrogation User Guide

This guide covers how to use the Device Interrogation features in the Vista Platform to discover and monitor cryptographic assets across your network devices and cloud infrastructure.

Overview

The Device Interrogation service enables you to:

• Discover cryptographic configurations from network devices (F5, Fortinet, Cisco, Palo Alto, UniFi)
• Integrate with cloud providers (AWS, Azure, GCP) to discover cloud-based cryptographic resources
• Schedule automated interrogations to maintain an up-to-date inventory
• Track discovered assets through the approval workflow

Getting Started

Prerequisites

• Active tenant account with appropriate permissions
• Network connectivity to target devices (for on-premises)
• Cloud credentials with read access (for cloud discovery)

Cloud

Connecting a cloud account

1. Go to Discovery → Cloud.
2. Click Connect integration.
3. Pick the provider (AWS, Azure or GCP) and give the connection a name, and optionally an account id, a default region, an environment and a description.
4. Enter the credentials:

AWS

• Name: A descriptive name for this integration
• Access Key ID: Your AWS access key
• Secret Access Key: Your AWS secret key
• Region: Default region for discovery

Azure

• Name: A descriptive name for this integration
• Tenant ID: Your Azure AD tenant ID
• Client ID: Application (client) ID
• Client Secret: The client secret value
• Subscription ID: Azure subscription to scan

GCP

• Name: A descriptive name for this integration
• Project ID: GCP project ID

• Service Account JSON: The service account key JSON file

• Click Connect.

• Use the row's Test connection action to check the credentials work.

Editing a connection later leaves the stored secrets alone unless you type new ones.

Running a cloud discovery

1. On Discovery → Cloud, use the connection's Run discovery now action.
2. Choose the resource types. They start all selected; clear the ones you do not want:
3. AWS: ALB / NLB / Classic ELB, API Gateway, CloudFront, KMS keys, S3 encryption, RDS encryption
4. Azure: Application Gateway, Load Balancer, Key Vault keys, Storage account encryption, SQL Database (TDE)
5. GCP: HTTPS Load Balancer, SSL Proxy, Cloud KMS keys, Cloud Storage encryption, Cloud SQL encryption
6. Choose the regions, where the selected types are regional at all. Some — S3 buckets and CloudFront distributions, for instance — are listed account-wide, and the modal marks those rather than offering a region filter that would do nothing.
7. Start the run, and watch it on Discovery → Discovery Jobs.

Cloud Discovery Results

After a cloud discovery job completes, discovered cloud resources are automatically processed through the unified discovery pipeline:

1. Automatic processing: cloud discoveries go through exactly the same pipeline as sensor discoveries. There is nothing to import.

2. Certificate Extraction: For publicly accessible cloud resources (e.g., internet-facing load balancers, CloudFront distributions, API Gateways), the platform performs a TLS handshake to extract the full certificate chain. This means cloud-discovered assets include the same certificate detail as sensor-discovered assets:

3. Full certificate chain (leaf + intermediates)
4. Certificate PEM data and fingerprints
5. Subject DN, Issuer DN, SANs, validity period
6. Key algorithm, key size, and signature algorithm
7. For AWS resources, certificates are enriched with ACM metadata (ARN, renewal eligibility)

Note: Private/internal endpoints that are not publicly reachable will still have their devices and crypto configurations created with API-only metadata, but without a full certificate record.

1. Approvals: what was discovered waits on Discovery → Approvals, unless its prefix auto-approves it. Approvals is a page of its own — the queue is shared by every source, and the source facet is how you narrow it to what came from the cloud.

2. Processing time: expect the assets to appear within a few minutes of the run finishing, depending on how much was discovered.

Viewing Cloud-Discovered Certificates

After cloud-discovered assets are approved into inventory:

• Certificate list: Inventory → Certificates. Cloud-discovered certificates carry a Cloud API badge.
• Certificate Details: Click a cloud certificate to see standard details plus a Cloud Provider Details section showing ACM ARN, renewal eligibility, and validation status (AWS) when available.
• Asset detail: open the asset to see its certificates with expiry status.
• Crypto configuration details: the asset's Cryptography tab shows the full certificate detail and whether it was verified by a real TLS handshake or taken from API metadata alone.

Network Devices

Devices live on Discovery → Sensors & Scanning → Managed Devices. The page lists the assets you have given the platform credentials for, with the management address, the asset's class, which interrogator handles it, its firmware, when it was last interrogated, and its connection status.

Adding a device

Give the platform four things and it asks the device for the rest.

1. Go to Discovery → Sensors & Scanning → Managed Devices and click Add device.
2. Fill in the device type (F5, Palo Alto, Cisco, Fortinet or UniFi), the management address, and a username and password. For a web-API device the address is its management URL (https://10.0.0.1). A Cisco device is reached over SSH, so give its host, host:port or ssh://host:port.
3. Tick Skip TLS verification if the management interface uses a self-signed certificate. It is not offered for Cisco devices, which are reached over SSH: their host key is checked instead, and the key seen when the device is added is pinned to it.
4. Click Add device.

The platform connects, logs in, and asks the device what it is, using the same calls an interrogation makes:

Device	What it reads
FortiGate	System status
Palo Alto	show system info
F5 BIG-IP	Software version and hardware
Cisco	show version and show inventory, over SSH
UniFi	The controller's device list

It then creates the device with the vendor, model, serial number, firmware version, host name and addresses it learned. Only that identity is read — not the device's VPN keys, certificates or other configuration. Your credentials are encrypted at rest.

If it can't connect, nothing is created. The form says why and shows the remaining fields so you can still add the device by hand:

Reason shown	What to check
Couldn't reach the device	The address and port, and that the device is reachable from the platform. If only one of your device agents can reach it, add it through that agent (below).
The device's certificate isn't trusted	Tick Skip TLS verification and click Try connecting again.
The device rejected the credentials	The username and password, and that the account may read system information.
That address isn't allowed	Loopback and link-local addresses (including cloud metadata) are never probed.
That management address isn't valid	Use https://host[:port] with no user name, query or fragment.
Something else answered at that address	The device type, and that the address is the device's management interface.

If your organization enforces identity admission, a device added this way is created because the platform read its serial number itself. A device whose serial could not be read is kept for review in Discovery → Observations, like a device added by hand.

Adding and testing devices is recorded in the audit log, and an organization can run 20 of these connections a minute.

Adding a device only an agent can reach

The platform can only connect to devices it can route to. A device on a prefix that only one of your deployed device agents can see is identified by that agent instead.

1. Click Add device and fill in the same four fields.
2. Under Reach it from, choose the agent. (The choice appears only when your organization has device agents; Vista platform — connect now is the default.)
3. Click Add device. The form closes straight away: nothing is dialled from the platform. The agent connects, logs in and reads the same identity the platform would — the same calls, the same rules about what is read.

Until the agent answers, the attempt is a row at the top of the devices list:

Row shows	What it means
Discovering…	Waiting for the agent, or the agent is identifying the device now. The agent checks for work every 30 seconds by default, so usually within a minute.
Discovery failed	The agent tried and could not identify the device. Hover over it for the reason — the same reasons as above, except that Couldn't reach the device means the agent could not reach it. Fix the cause and click Retry.
Not picked up	The agent did not take the job within 15 minutes. This says nothing about the device: check that the agent is running and up to date, then click Retry.
Held for review	Identified, but your organization enforces identity admission and the serial number could not be read. Review it in Discovery → Observations.

When the agent has identified the device the row is replaced by the device, filled in with what it learned, exactly as if the platform had connected itself. Dismiss removes an attempt and the credentials it was queued with.

Only that agent runs the identification — never the platform or another agent — and only an agent new enough to support it. If the agent has not checked in recently, or is older than your platform, Add device says so and queues nothing. Your credentials are encrypted until the agent picks the job up, are then sealed so only that agent can read them, and are dropped from the job once the device is created. Attempts count toward the same 20 connections a minute and are recorded in the audit log.

Click Add without connecting to save what you entered, or Enter the details by hand instead to skip the connection altogether. For Other device types, which can't be identified automatically, the form shows every field from the start. Anything you leave blank an interrogation can fill in later.

When you add a device by hand you can also give the MAC address and the Interface its IP address is on (port1, mgmt). The device's Interfaces tab then shows that interface holding the MAC and the address. Leave the interface name blank and the platform names it (observed-1).

Interrogating

Each row carries its own actions:

Action	What it does
Interrogate	Queues a run against that device
Test connection	Opens a dialog; click Test to log in with the stored credentials and read the device's identity. Reports how long that took, or why it failed, using the same reasons as Add device. A device can be tested once every 10 seconds, because repeated logins with a wrong stored password can lock the device's account. Needs the same permission as Interrogate.
Edit management settings	Changes the address, credentials, TLS option or automatic re-checks (below)
Open this asset's page	Goes to the asset in Inventory
Stop managing this asset	Removes the management configuration and its credentials. The asset stays.

There is no bulk interrogate — interrogation is queued one device at a time. For repeating work, use a schedule (below).

An asset discovered through a cloud API has no management credentials and is not interrogable; its row says so rather than offering a button that would fail.

Automatic re-checks. When identity enrichment needs fresh evidence from a device, it can run that device's interrogation again — but for a device the platform interrogates (not an agent), only if you have allowed it. Turn on Allow the platform to re-check this device automatically when adding the device or under Edit management settings; it is off by default, and you can turn it off again at any time. Turning it on lets observations that were waiting for this permission continue on the next enrichment cycle. The setting is not shown for a device an agent interrogates, which enrichment asks through that agent, or for a cloud resource.

Connection status

Status	Meaning
Connected	Reachable and responding
Error	The last attempt failed — hover the status for the reason
Testing	A connection test is in flight
Unknown	Nothing has tried yet

There is no per-device detail panel: a device is an asset, so its history, endpoints, certificates and findings are on the asset's own page, which the row links to. Run history is on Discovery → Discovery Jobs.

Scheduled Interrogations

Creating a schedule

1. Go to Discovery → Scheduled Scans and click New schedule.
2. Give it a name and an optional description.
3. Pick the target — a device, or a cloud integration. The target is fixed once the schedule exists; to point at something else, make a new schedule.
4. Choose when it runs:
5. Every few hours — every 1, 2, 3, 4, 6, 8 or 12 hours, at a chosen number of minutes past the hour.
6. Daily — at a time of day.
7. Weekly — on the days you tick, at a time of day.
8. Monthly — on a day of the month (1st–28th, so it never skips a short month), at a time of day.
9. Custom (cron expression) — a standard five-field cron, for anything the options above don't cover (for example */15 9-17 * * 1-5, every 15 minutes during working hours on weekdays).

Times are in the time zone shown beside them, which defaults to your browser's; daylight-saving changes are handled. A sentence under the fields ("Runs every weekday at 2:00 AM (America/Chicago).") confirms what you picked. 5. Save.

A custom cron runs in UTC unless you prefix it with a zone, for example CRON_TZ=Europe/London 0 2 * * *. Schedules created before the picker existed keep running in UTC; editing one shows its zone as UTC (server time) and leaves it unchanged unless you pick another.

Managing schedules

A schedule can be enabled or disabled (it runs on its cadence only while enabled), edited, triggered immediately, and deleted. Its runs appear with everything else on Discovery → Discovery Jobs.

Jobs

Monitoring jobs

Discovery → Discovery Jobs lists every run with its status, and offers Retry and Cancel on the rows where those apply:

Status	Description
Pending	Job is queued and waiting to run
Running	Job is currently executing
Completed	Job finished successfully
Failed	Job encountered an error
Cancelled	Job was manually cancelled

Job Details

Click any row on Discovery → Discovery Jobs to open that run's detail.

Execution — target device or integration, status, created / started / completed times, duration, and the error message if it failed.

Outcome — three counts that are deliberately separate:

Count	Meaning
Discovered	Assets the interrogation returned
Crypto measured	Assets whose TLS posture was actually observed
Into inventory	Assets that became a discovery finding

"Discovered" and "Into inventory" are different questions. A job can finish successfully and still fail to materialize what it found — the device answered, but something downstream rejected the results. When those two numbers disagree the panel says so, and the reason appears under Processing errors.

Pipeline — per-stage counts for the run: assets received, findings created, records queued for classification, and anything skipped.

Discovered assets — each asset with its negotiated TLS version, cipher suite, key exchange and key size, plus every certificate found (subject, issuer, key algorithm and size, signature algorithm, expiry, SHA-256 fingerprint, and a self-signed marker). Certificate validation failures are shown against the asset that produced them.

An asset marked not probed was listed by the device's management API but never had its own handshake measured — so its cryptographic posture is unknown, not clean. Interrogating a controller commonly returns both kinds: the controller itself is measured, the devices it manages are inventoried.

Where an interrogated configuration lands

Everything an interrogation reports is read from the device's own configuration, so it belongs to that device unless it clearly describes something else on your network:

The configuration names…	It lands on
The device's own address as the platform has measured it (its management SSH or HTTPS service) — the address you typed in the device form does not count	The interrogated device, with an endpoint at that address and port
Any other address in one of your private or registered networks (an F5 private VIP)	That address's own asset, found or proposed the usual way
A public address (a public VIP, a gateway's WAN VPN)	The interrogated device, with an endpoint at that address and port
No address (a PAN-OS decryption rule, a profile)	The interrogated device, with no endpoint
Only a tunnel's far end (a FortiGate or Cisco IPsec peer)	The interrogated device, with no endpoint; the peer is kept as the tunnel's peer, not made into an asset or an external connection

A name the device reports without an address — a rule, a virtual server, a tunnel — is kept as the configuration's label. It is never looked up in DNS, and an interrogated address is never given a name by reverse DNS either.

If a finding cannot be attributed to any device, the job's Pipeline counts it as skipped, with the reason, rather than dropping it silently.

What interrogating a UniFi controller records

A UniFi controller describes every device it manages and every client it sees, and an interrogation records that on each one's own asset — not on the controller's:

• Each switch's ports on its Interfaces tab, named Port 1 … Port 24 (SFP+ 1 where the controller names it so; a label you gave a port in UniFi, such as "Printer", is not its name), with the port's type (1000base-t, 10gbase-x-sfpp, …), negotiated speed, up/down and enabled/disabled state, and its VLANs: an access port's VLAN, or a trunk's native VLAN and the VLANs it carries (a port that carries every network is recorded as tagged-all). Ports aggregated into a link aggregation are members of a LAG <n> interface that carries the aggregate's VLANs.
• Each access point's radios: one wireless interface per SSID a radio broadcasts (ra0, rai0, …), typed by band (2.4 GHz as 802.11n, 5 GHz as 802.11ac, 6 GHz as 802.11ax), with its BSSID. SSID passphrases are never kept.
• The gateway's interfaces: one bridge interface per network it serves (br0, br20, …) holding the gateway's own address on that network, and its WAN address on the port the WAN is.
• The site's networks as prefixes and VLANs (Inventory → Networks and VLANs), each prefix with its VLAN, whether it hands out addresses by DHCP, and its purpose (corporate or guest). WAN and VPN networks are not prefixes; a VPN becomes a VPN gateway with its crypto configuration.
• Each client's MAC and address on the client's own asset, on an interface named observed-1 until something that knows the client's own name for it — its agent — reports it.

Each device's management address — the address the controller lists it at — becomes its primary IP.

What interrogating a gateway records

A router or firewall knows which networks it serves: on each one it holds an address of its own, the address hosts there use as their gateway. UniFi gateways, FortiGates and F5 devices report it together with each network's prefix. Cisco devices report their VLANs without a prefix, so nothing below applies to them yet. There is nothing to enter by hand — interrogating the device is the whole step.

From each network the device reports, an interrogation records:

• The device's own address on that network, as one of its identifiers. A router with four networks is one asset holding four addresses, not four assets. If a sensor had already filed one of those addresses as a separate asset known by nothing but addresses, the address moves to the router, and both assets' history says so. If the address belongs to an asset known by something stronger — a MAC address, a serial number, an agent, or an address you declared — the router does not take it; a merge proposal opens for you to decide instead.
• That the device is the network's gateway. Every prefix where the device holds that address — one you created or one learned from the device — records it as its gateway. The next interrogation keeps this current: a network the device no longer reports loses it, and another device's gateway is never removed. When two devices report the same network (a high-availability pair), the most recent report is shown.
• Its WAN address (UniFi gateways), from the device's own record, as an identifier with no network attached — your provider's network is not one of your prefixes. Only the address is kept, never WAN credentials or connection settings.

A UniFi controller is treated as the site's gateway only when it may be one. When you add a controller by its IP address and that address is none of the site's UniFi gateway's own addresses — a Cloud Key, or the Network application on a server, in front of a UDM, USG or UXG — the gateway's addresses stay on the gateway (see below) and the controller is not made the networks' gateway.

The device's own network is the one its management address — the address the platform interrogates it at — falls in, and its location follows that network. A router that answers on many networks therefore stays in one place, rather than moving each time a sensor sees it on another of them.

Where you see it:

• The router's asset page → Overview → Networks routed: every network it is the gateway of, with the network's prefix, the router's address on it, the VLAN tag (Untagged when the device reported none), DHCP, how many assets are on the network (click the number for the list, the router included) and whether a sensor covers it. The card is not shown for an asset that routes nothing. If it says Couldn't load routed networks, the rest of the page is still correct; reload to try again.
• A host's asset page → Overview → Prefix: for example Office LAN · via edge-router (192.0.2.1), linking to the router. A network with no recorded gateway shows just its name.
• Inventory → Networks: the Gateway and Coverage columns — see Gateway and coverage, which also explains No sensor on this network.
• Inventory → Map: each network names its gateway beside its prefix, or says gateway not recorded.

Routing tables and firewall rules are not collected: they are a map of how to move through your network, and nothing in the inventory needs them.

Cancelling a job

Use the row's Cancel action on a running job. Some operations are not interruptible and will finish anyway.

The approval queue

Discovered assets wait on Discovery → Approvals — a page, not a button on some other page — unless the prefix they landed in auto-approves them, or they are the host a device agent of yours is installed on (its first host inventory admits it).

The queue is shared by everything that proposes something: discovered assets, imported rows, assets declared by an uploaded SBOM, records pulled from a CMDB, merge proposals from the identification engine, class proposals from a classifier, and anything the AI assistant suggested. The source facet is how you narrow it, and every source states plainly what kind of claim it is making — a serial read off a device is not the same claim as a classifier's guess.

Approving accepts the asset into your inventory. Rejecting suppresses it from being proposed again. Full detail: Asset Approval.

Practices worth adopting

Security

• Least Privilege: Use credentials with minimum required permissions
• Credential Rotation: Regularly rotate cloud credentials
• Network Segmentation: Run agents behind firewalls when possible

What the platform records from your devices

Interrogation collects cryptographic posture — algorithms, key sizes, protocol versions, cipher suites, certificate identity and validity. It does not collect key material.

Vendor management APIs frequently return secrets next to the configuration we want: a FortiGate's IPsec phase-1 object carries the tunnel pre-shared key, its certificate store carries private keys, a UniFi controller's settings carry the mesh PSK and SMTP relay password. Each collector projects the vendor's response onto an explicit list of fields the platform actually uses, so those values are discarded at the point of collection rather than stored and filtered later. A second, name-based check runs over everything a collector emits as a backstop.

Three consequences worth knowing:

• Past the collector, only a fixed set of posture fields travels on to inventory: a VPN's peer address and IKE version, an SSH server's banner, host-key type and fingerprint, a managed device's MAC address, and the names of profiles, certificates and configuration objects. Each is checked again when it arrives. The device's own identity (vendor, model, serial) is recorded against the device only, never copied onto what it reports.
• Where a device's configuration can be read without retrieving secrets, the platform asks narrowly. Cisco interrogation requests only the ssl cipher configuration lines rather than the whole crypto section, so pre-shared keys are never transmitted off the device at all.
• Cloud key discovery reads key metadata only — state, algorithm, protection level, rotation policy. AWS KMS keys are non-exportable by design; Azure Key Vault is read through the management plane, which exposes key properties and never secret values.

The credentials you give the platform to reach a device are a separate matter: those are encrypted at rest and are never returned by any API.

Performance

• Stagger schedules so every interrogation does not fire at the same minute
• Narrow a cloud run to the resource types and regions you care about — a full sweep of everything costs API calls on the provider's side too

Maintenance

• Review Failed Jobs: Check job errors and fix connectivity issues
• Update Credentials: Replace expired credentials promptly
• Clean Up: Remove devices and integrations that are no longer needed

Troubleshooting

Common Issues

"Connection refused"

• Verify the device IP address and port
• Check firewall rules allow access
• Ensure the management interface is enabled

"Authentication failed"

• Verify credentials are correct
• Check if credentials have expired
• Ensure the user has required permissions

"Timeout"

• Increase timeout settings if devices are slow
• Check network connectivity
• Verify the device is not overloaded

"Timed out" or "below the auto-accept threshold"

See Device auto-discovery troubleshooting, which covers the failures that look like nothing happened.

Getting help

If you hit something this page does not cover:

1. Open the run on Discovery → Discovery Jobs and read its Outcome and Processing errors — a job that "completed" can still have materialized nothing, and that is where it says so.
2. Check Discovery → Approvals before concluding an asset is missing.
3. Contact your platform administrator with the job's id and the error it recorded.