Vista Platform 4.4.0 — full list of changes¶

Released 2026-10-05. The release summary — highlights, what to do before upgrading, what each edition includes, and how to verify the signatures — is in CHANGELOG.md. This page is the complete, per-change record behind it.

Identity: one intake for every observation¶

Every way Vista learns about a device — a sensor's scan or capture, a host agent's inventory, a device you add by hand, a firewall's neighbour table, a CMDB link, a DNS lookup — now decides which asset this is in the same place, by the same rules. Before, about ten code paths each made their own call, so the same device seen the same way could land as an existing asset on one path and a second asset on another. What you will notice:

Added¶

Static addresses can be pinned. On a network flagged DHCP, an address its asset holds pinned still identifies that asset, and only that asset, so a plain port scan of a router's own LAN address updates the router instead of waiting in Observations. An address is pinned when you add it to an asset (the asset form, or Add device / Edit device), when you tick Pin next to a recorded address, or when the host's own agent reports it as statically configured. The asset's Identifiers list shows static. The network keeps its DHCP setting. See Asset identity and discovery evidence.
Link to the asset that already owns an observation. An observation whose address (or another identifier) one existing asset already owns is no longer offered as Ready to confirm; it reads Matches an asset and suggests Link to that asset, and the bulk bar's Link to existing links a selection of such rows, each to its own owner. When several assets own identifiers of it, it reads Several match and leaves the decision to you.
A changed host key or address is explained, not just accepted. When a sighting matches an asset but its identifiers differ, the platform decides whether an SSH host key was rotated, the device moved to a new address, it was reimaged, or a different device now answers. The asset's History tab says which, with the old and new values, and a notification (asset_identity_drift) can be routed. A different device still opens a merge proposal; an address-only key change with nothing else to go on is kept and flagged for review. See When a device's identifiers change.
Host agents report every interface address. Host inventory records each real interface address under its own network segment, with whether the operating system says it is static or a DHCP lease. See Host inventory.

Changed¶

Endpoints are written where an identity decision attaches them. A sighting that only supports an asset you already have (for example a scan of an address in none of your network segments) updates its last-seen time but no longer adds endpoints, identified services or crypto configurations to it; the ports wait on the observation, and Link, Confirm or Attach endpoints… attaches them. Confirming several observations of one address gives one asset with all of their endpoints. Endpoints already on an asset are never deleted.
Add device recognises a device Vista already knows. A device added after Identify is matched by the MAC address and SSH host key the probe read, so it no longer becomes a second asset beside the one a sensor found. A hostname, address or serial typed onto a device that another asset already owns is refused with a merge proposal in Approvals rather than silently skipped.
Names and MAC addresses are filed the same way on every path. A name whose address is in no registered network reaches its domain segment; a .local name in a scan no longer matches hosts on other VLANs; randomised MAC addresses from scan findings or a controller's client list no longer become identifiers; and a network you marked static stays static for identity even when a controller reports DHCP on it.

Fixed¶

Bulk Confirm no longer fails on every row of a DHCP network. Rows offered as Ready to confirm whose address an asset already owned were all refused as "changed since you looked"; they now offer Link instead.
A scan or interrogation is no longer counted as a passive sighting. The sensor converter overwrote the source of every row, so active measurements ranked as passive observations.
Evidence that matches exactly one known asset is another sighting of it, on every path, and a sighting under a pending merge proposal is not silently linked to one side before you decide.

Discovery, scanning, inventory and everything else¶

Deprecated¶

POST /infrastructure-assets/stale/rescan, /stale/archive and /revalidate (and their v1 /assets/… forms). Inventory's bulk actions replaced them in the UI. They still work; each response now carries a Deprecation header and a Link to its successor — POST /infrastructure-assets/scan for rescan and revalidate, POST /infrastructure-assets/bulk-actions/archive for archive. (#2272)

Added¶

Select many assets in Inventory and act on them at once. All assets and Stale have a checkbox on every row; tick rows across pages, or tick the page and choose Select all N matching for every asset the query matches. A bar above the list then offers Scan (with Run from), Edit (owner email, environment, business unit, support group, add or remove tags), Archive, Restore, Delete and Export (CSV), each shown only to people with the permission it needs. A selection of all matching assets is sent as the query and the count you confirmed, and is refused without changing anything if the query now matches more. Up to 5,000 assets, or 1,000 for a scan. Every change is recorded in each asset's history under your name and once in the audit log. API: POST /infrastructure-assets/bulk-actions/ {archive,restore,update,delete}, and POST /infrastructure-assets/scan accepts the same query + expected_count selection. (#2272)
One Helm value keeps the database server's own JIT setting. The platform asks PostgreSQL for jit=off on every connection. Keeping the server's own setting used to mean a DB_JIT entry in each backend's extraEnv, one service at a time. Set appConfig.dbJit: true instead and every backend gets it; a DB_JIT under backends.<service>.extraEnv still overrides it for that service. Left empty, nothing changes. An unrecognised value is refused at install time rather than silently ignored. The behaviour behind PgBouncer or a managed database proxy is documented but not tested.
Networks show their gateway. After a router is interrogated, Inventory → Map names the gateway on each network it routes instead of "gateway not recorded", the router's asset page gains a Networks routed section (its address, VLAN, DHCP or static, host count and sensor coverage per network), a host's page shows via beside its network, and Settings → Network Segments has Gateway and Coverage columns. A network no sensor reaches says so. Nothing is entered by hand; a network whose router has not been interrogated still reads "gateway not recorded". (#2242, #2246)
Add a device that only a device agent can reach. When your organization has device agents, Discovery → Devices → Add device shows Reach it from. Choosing an agent queues the identification on that agent; the attempt appears in the table as Discovering…, then becomes the device, or shows Discovery failed with the reason and Retry, Not picked up if the agent never collected it, or Held for review. Adding from the platform is unchanged and still answers immediately. Needs a device agent from this release. (#2236)
Let the platform re-check a device on its own. Add / Edit device has a new option, Allow the platform to re-check this device automatically (off by default). With it on, identity enrichment may run that device's interrogation again when it needs fresh evidence; observations that were waiting on it are retried on the next cycle, and their explanation now names the setting. (#2232)
A gateway is recorded for each network it routes. Interrogating a router now records its own address on every network it reports and the network's gateway, with no manual entry; network and asset reads return them. An address a provisional or address-only record held moves to the gateway; anything stronger keeps it and a merge proposal opens. Devices an interrogation reports are approved automatically on networks set to auto-approve. The screens that show the gateway follow. (#2234, #2239)
A model provider can be set from the product, not only at install. Until now the AI assistant's model provider could only be named in the chart's ai.* values, which meant a Helm upgrade and a restart of every service. Two new routes, both Enterprise:
A default for every organization, in the admin console under Settings → AI assistant: choose Anthropic or an OpenAI-compatible endpoint, Test connection, Save. It takes effect on the next request and overrides the one set at install; the page shows both and says which is in effect.
An organization's own, on its Settings → AI assistant page: the Model provider row now says whose provider answers (Provided by this deployment or Connected by your organization) and, where the organization is allowed to, opens a form to connect, test and disconnect one. An organization's own provider answers for that organization only. On Enterprise every organization may; on MSP a plan decides (the new Own AI Model Provider entitlement, off in every plan by default), so a service provider can include a model in a plan or let customers bring theirs. A platform administrator can also switch organizations' own providers off entirely.

API keys are stored encrypted and never shown again (the pages show the last four characters). An organization can only use a public address unless the platform administrator allows private ones. The organization's Use the AI assistant switch still turns everything off, its own provider included. Platform features that belong to no organization (the catalogue's "Propose with AI", drafting into the shared framework catalogue) use the default and never an organization's provider. The install-time ai.* values still work unchanged. See Connecting a model provider. (#2219)

The observations API says what each observation needs, in names, and decides many at once. GET /discovery/observations now returns, on every item, the network's and the collector's names instead of only their ids, a "needs" category (ready to confirm, needs a network, needs a sensor, likely noise) with a suggested action, an explanation code and a proposed reason sentence, and the identifiers in readable form. It filters by needs, network, source and free text, sorts by last seen, host, network or needs, and reports per-category counts for the review table's chips. A new POST /discovery/observations/bulk confirms or dismisses up to 200 observations with one reason, reporting each one's outcome — an allowance reached or a changed observation fails that row only — and bulk confirm accepts only observations that are ready to confirm. Every decision is audited with a shared batch id. (#2200)
Scans by depth run from your own sensors, host by host. A discovery job with a scan depth can now run from one of your sensors — the only way to reach most private and plant networks. The sensor scans with the same engine as the platform sensor and reports each host as soon as it is done, so the job's progress, coverage and results by host fill in while it runs and each host's findings reach inventory right away; nothing is held back for the end. Such a scan has no time limit — it runs as long as the sensor keeps checking in, and is marked failed only after 15 minutes of silence, keeping every host already finished; a Retry then scans only the hosts not done. Cancel now reaches the sensor: it stops at its next report or heartbeat, and a scan still waiting on it is dropped. The sensor never contacts an address its own rules forbid — loopback, link-local, multicast, a range you excluded from probing, anything outside your networks — and reports it as not scanned, with the reason. Requires this release's sensor; older sensors keep running protocols × ports jobs and are not handed these. (#2170)
Discovery → Discovery Jobs shows a long scan as it runs. A scan described by depth shows a progress bar on its row with a live line ("112 of 254 hosts · 31 responded · 9 open ports"), where it runs and its depth, and the page refreshes itself while anything is unfinished. Its detail refreshes until the scan ends and shows what the scan does and why (depth, pace, targets, where it ran, and every target scanned less deeply than asked, with the reason); coverage that says no answer — never "down" — with reachability guidance when nothing answered and where and why a scan that ended early stopped; results grouped by host, a page at a time, with an open port nothing could name shown as open, unidentified and a host that answers on every port collapsed to one line; and where the findings went, with a link to Approvals. A failed or queued scan has Resume scan, which runs again only the hosts it had not finished and keeps the rest; a refused Resume or Cancel shows the server's reason (Cancel used to fail silently on the list). GET /discovery/jobs now carries each such scan's plan, and its progress and coverage while it has not ended; ?job=<id> on the page opens that job. (#2170)
Scans described by depth run host by host, with real progress and an honest coverage summary. A job sent with scan_depth and run from the platform sensor is split into one durable unit per address. Every address is checked against your registered networks and exclusions before anything is sent to it — even the "is anything there?" probe — so a range marked sensitive after the job was queued is never touched. Each host's results are stored and sent on to inventory as soon as that host is done; a cancel keeps what was found, and a Retry or a restart resumes only the hosts not finished, without storing anything twice. An open port nothing can name is recorded as an open, unidentified port on the host instead of being dropped, a host that seems to accept every port is reported once rather than tens of thousands of times, and a silent UDP port is never reported as found. GET /discovery/jobs/{id} now reports progress per host for such a job and a coverage summary — addresses that responded, gave no answer (never "down"), could not be scanned and why, ports open / closed / filtered / not probed — with warnings such as "0 of 254 scanned addresses responded — the platform sensor may not be able to reach this network". (#2170)
Scans by depth share the platform sensor fairly, and results can be read by host. A long scan no longer holds up every other scan on the same platform sensor replica: each replica scans at most 16 hosts at once and any one organization at most 4 (chart values discovery.maxConcurrentUnits and discovery.maxConcurrentUnitsPerTenant). UDP probes of one host now wait for replies in parallel while still sending no faster than the host's packet rate, so a wide custom UDP range takes minutes instead of hours; industrial (OT/ICS) UDP ports are still probed one at a time. GET /discovery/jobs/{id}/results?group=host returns each host with all its ports, paged by host. (#2170)
Sensors: "Additional TLS ports" is a setting in the console. A port where your organization runs TLS on a non-standard port (for example 9443) can now be listed on one sensor (Discovery → Sensors & Agents → a sensor → Control) or for every sensor (Sensor defaults), instead of only in the sensor's own configuration file. Sensors decode TLS handshakes seen on the listed ports; a port the sensor already watches is accepted and labelled with what it is already monitored as, and an entry that is not a port is refused by name. The list shapes the capture filter, so it shows Pending restart until the sensor restarts and reports it in effect. Exposed through the desired-config API as extra_tls_ports, a port_list setting carried as a comma-separated string. A sensor older than this release cannot apply it: while the list is left empty that sensor is not shown as failed (it already watches no extra ports); once ports are set, it shows Failed with "upgrade the sensor to apply it". (#2170)
Quick Start guide. A single walkthrough from first sign-in to a populated inventory: registering a sensor (with download links), adding a network device, connecting a cloud account, approving what was found, and where to look first. It is in the user docs (docsv4/core/quick-start.md) and at the root of the Core repository as QUICKSTART.md.
Discovery jobs can be described by scan depth. POST /discovery/jobs accepts a second request shape — scan_depth (quick, standard — the default —, thorough, custom with tcp_ports/udp_ports ranges such as 22,8000-8100), pace and run_from (auto, platform, sensor) in place of protocols and ports — and the server-side plan behind it: per target, whether it is private, inside a registered network segment (and which one) or external, and the depth it gets (a target outside your registered networks at Standard at most, each downgrade listed with the reason; a guardrail for unclaimed targets, which registering the range lifts); Run from Auto choosing one of your sensors only when one online sensor serves every target; and a probe budget (addresses × ports, default 25,000,000, chart value discovery.maxJobProbes, refusals 422 scan_budget_exceeded). The Discover wizard sends this shape (see Changed). The proxy now forwards ot_probe_protocols, the explicit OT opt-in it used to drop. The legacy protocols/ports request is unchanged. (#2170)
Preview a scan before starting it (API). A scan-depth request to POST /discovery/jobs with "dry_run": true answers 200 with the plan the server would store, an estimate (probes, addresses, and a duration as a range with the assumptions it rests on), whether targets outside your registered networks still need confirming, and which. It runs the same checks as a real create — validation, target authorization, the Standard cap on external targets, Run from Auto, the budget — and is refused the same way, but creates no job, sends nothing to a sensor and uses none of your scan allowance. The Discover wizard shows it before every scan (see Changed). (#2170)
Claim a public range learned from one of your devices. A firewall's public networks become segments when you interrogate it, but they are not treated as yours, because a device cannot show whether a public network is your DMZ or your internet provider's link. Settings → Infrastructure → Network Segments now offers Claim as mine on such a row (needs settings.update): after you confirm, the range is treated like a public segment you created — scannable when someone asks, never automatically, and treated as yours by sensors — still subject to the /8 (IPv4) and /16 (IPv6) limit and to sensitive or probes-disabled exclusions. The claim is your own statement, not verified; each claim and Revoke claim is audit-logged (network_segment.claimed, network_segment.claim_revoked). API: POST / DELETE /api/v2/inventory-service/network-segments/{id}/claim. A segment's learned provenance and claim can no longer be set or removed by editing its metadata; before, an edit that omitted source turned a learned segment into a declared one. (#2170)

Changed¶

The Dashboard's "Inventory Health" panel is now "Assets Monitored". The big number was never a health measure: it is the count of assets under monitoring, with assets still waiting for approval counted separately beside it. Only the heading changed; the numbers and links are as before.
Discovery → Active Scan is now a view of Inventory. Its list is Views → Never scanned on All assets, and scanning is the bulk bar's Scan; the page's entry is gone from the Discovery menu and a bookmark to it opens the view. Scans started here, under the bar, names every asset a scan did not reach and why, rather than a count and the first reason. The Active Scan button on an asset now opens the same dialog, so a single scan can also choose where it runs. On Stale, the per-row Rescan/Archive buttons and the whole-page Revalidate all/Archive all bar are replaced by the same checkboxes and bar. (#2272)
Clicking a row in Inventory → All assets now opens the asset drawer, and the asset page has an Active Scan button. The drawer is the quick look that keeps your place in the list; its Open full page button goes to the asset page. Ctrl/cmd-click or middle-click an asset's name to open the page in a new tab. The asset page now carries the same Active Scan button as the drawer, for people who can edit assets, and shows "Scanning…" until the scan finishes.
Finding the assets behind a scan's addresses no longer reads the tenant's whole asset table. Looking an asset up by its address compared a text value with the address of every live asset in the tenant, which on a large estate made adopting a completed automatic scan's job a full scan of the tenant's assets. The database now keeps an index on that address text, added by the schema on the next upgrade. The planner starts using it once PostgreSQL next analyses the assets table, which autovacuum does as the table changes.
Import-only assets in a network you registered are scanned automatically without connection consent. An asset known only from a CMDB or NetBox connection is still withheld from automatic scans until that connection allows active scanning, but only when its address is in private space you have not declared. A network segment a person registered vouches for the addresses in it; a segment learned from a device or imported by a connection does not. When two assets are merged, the result is import-only only if both were. (#2268)
Automatic scans, identity checks and Active Scan now run on the same scan engine as Discover assets. Each checks its ports first and identifies the service from what answers, so a host that drops packets finishes in seconds instead of minutes. The Protocols checkboxes are gone from Settings → Active Scanning: services are identified from what answers on the ports you list. The protocols field of the create-scan API (POST /discovery/jobs) is deprecated and ignored; a request naming protocols and ports is scanned on exactly those ports. Sensors older than this release keep working, are marked Needs upgrading to run scans on the current engine on Discovery → Sensors & Agents, and should be upgraded.
Every scan now runs on that one engine, including OT-only API requests. A create-scan request that names only ot_probe_protocols is scanned on exactly those protocols' standard ports (Modbus TCP 502, OPC UA TCP 4840, EtherNet/IP UDP 44818, BACnet UDP 47808) and probed there, with the same opt-in, operator switch and audit record as before. One naming only OT probes that the operator has switched off is now refused instead of creating a scan of nothing. The older protocols × ports scanners are removed from the platform and from the sensor. A sensor from this release refuses a protocols × ports job and asks for the platform to be upgraded; a job of that shape created for a sensor before it was upgraded fails with a reason, and running the scan again plans it. Older sensors are still sent that shape until they are upgraded.
compliance-engine now needs the deployment's encryption key. It opens the stored API key of a model provider configured in Settings (above) to draft controls and remediation plans. The chart, the compose files and the service registry pass ENCRYPTION_MASTER_KEY to it, as they already do for the other services; a hand-maintained deployment must do the same or drafting reports no provider for organizations that connected one. (#2219)
Discovery → Observations is a review table you can work through. It opens on Ready to confirm, with chips and counts for Needs a network, Needs a sensor, Likely noise and All (where the state control still reaches linked, dismissed, expired and conflict observations). Each row is one line — host and services, the network's and the sensor's names, last seen, and what it needs — and opens to its evidence beside a plain What this needs: why the platform did not create an asset itself, what will fix it (add a network, add a sensor, or — for a DHCP network whose addresses do not move — a shortcut to its DHCP setting), and the alternatives. Tick rows to confirm or dismiss many at once with one prefilled, editable reason; bulk Confirm is offered only when every selected row is ready to confirm, and a row that fails stays in the table with its reason. Single-row decisions now start with the proposed reason filled in too. (#2200)
Discover assets finds everything on a host or a network. The dialog (Discovery → Discover assets) no longer asks which protocols and ports to probe. You choose a scan depth — Quick, Standard (the default), Thorough, or Custom — and services are identified from what answers. Run from offers Auto, the platform sensor or one of your sensors by name, as Active Scan does; the old "Cloud — platform sensor" option is gone. Advanced, closed by default, holds Custom's TCP and UDP ports (a range such as 8000-8100 now means the whole range — the old Ports box quietly read it as 8000 — and a mistake is shown in the platform's own words before you start), the scan's pace, and an unchecked Probe industrial (OT/ICS) devices opt-in with its acknowledgement, shown only while OT probing is switched on for your organization. Before you start, a preview shows the size of the scan, a duration range and what it assumes, where it will run and why, which targets will be scanned at less depth (targets outside your registered networks are scanned at Standard at most), and any refusal — too large, over the installation's budget, an offline sensor, a sensor whose software cannot scan by depth (with a one-click switch to the platform sensor) — in the server's words; a preview that cannot be worked out never stops you starting. Start says what started and links straight to that scan on Discovery → Discovery Jobs, where the scan's progress, results and Cancel live: the dialog no longer follows the scan or lists findings, and can be closed at any moment. (#2170)
OT/ICS active probing is now part of Core, and on by default. It was an Enterprise capability. The ot_active_probing switch now ships enabled on every plan, and an operator can still turn it off for a whole plan (Plans & Pricing) or for one tenant (a plan exception), which keeps winning over the plan. OT probes still run only when a person asks for them on a scan, through the Discover wizard's Advanced opt-in or the discovery job API; automatic scanning never runs them. The catalogue item stays, priced at $0. On upgrade, existing plans that had it off are switched on once; a tenant that was turned off by an exception stays off, and a later choice to turn it off is never undone by a subsequent upgrade. The OT inventory lens (ot_primary_lens) is unchanged and remains Enterprise.

Fixed¶

"Scan anyway" no longer scans assets a second time. When some assets in a scan were outside your registered networks, confirming resent every asset in the request — including ones that had already been dispatched. It now sends only the assets it asked about. (#2272)
A stopped sensor no longer strands every host it has seen. When the sensor that last observed a host is offline, automatic scans and Active Scan under Auto now run that host from another of your sensors that is online and on the same network. Only when there is no such sensor is the host skipped for the pass, as before. A host your sensors have observed is still never moved to the platform sensor because its sensor went away.
Identity enrichment can probe a device through a sensor other than the one that saw it. When a sensor on one network sees evidence about a device on another network, enrichment hands the probe to a sensor that has an interface on the device's network. The dispatch check refused every such probe, logging "probe source or scope changed" and retrying, because it still required the probing sensor to be the one that observed the evidence. It now checks the two separately: the observing sensor must be a current sensor of the same tenant, and the probing sensor must be live with an interface on the device's network. What may be probed is unchanged: the target must be inside the observation's network and not excluded, the evidence must still be a sensor's own measurement, and neither sensor's own addresses are probed. Platform-managed sensors are never accepted as either.
The automatic scan no longer re-queues the whole estate on every pass. On an install whose asset timeline had grown, creating an automatic-scan job took minutes instead of seconds; the request timed out, the assets were never marked as scanned, and the next pass queued them all again. Three things change. Platform database connections now turn off PostgreSQL's JIT compiler, which was spending 20 to 40 seconds compiling a query that runs in a tenth of a second (DB_JIT=on keeps the server's own setting, which on the Helm chart is the one value appConfig.dbJit: true; a connection pooler such as PgBouncer must be told to ignore the jit start-up parameter). A job whose creation call timed out but which was created anyway is now recognised as dispatched. And the check that withholds import-only assets no longer reads the asset timeline: a whole job is authorised in a handful of queries whatever its size. (#2268)
The asset timeline no longer gets an "updated" entry every time a device is seen again. An entry is written only when an observation changes something about the asset: a new identifier or service, a better name, a moved address, or the first time a condition is noticed. Last-seen times still update on every sighting. On one 80-asset install the timeline had reached 424,000 entries in two days, 97% of them exact repeats. Existing entries are not removed. (#2268)
One interrogation of a network controller no longer identifies each device hundreds of times, and a held run is no longer replayed for ever. Each distinct device or client in a run is now identified once, not once per fact and relationship. A run held because some of its peers could not be resolved now replays only those peers, is superseded by the next run from the same device, retries with a growing delay (5 minutes up to 4 hours), and is retired 24 hours after it was observed. Retired runs stay visible as historical evidence on the observation's detail page. Relationship observation counts recorded before this release are inflated by the old replays. (#2268)
A configured device is no longer re-interrogated every few minutes. A network controller was interrogated again and again because some of the peers it reported stayed unidentified, and each new run produced more of them. Automatic enrichment never re-asks a device about evidence it produced itself, and re-checks any one configured device at most once every 6 hours. Manual interrogations and schedules are unaffected. (#2268)
Active Scan results attach to the asset you scanned. A person's scan of an asset on a DHCP network produced a finding that was held for corroboration and never reached the asset. Pressing Scan on an asset now updates that asset, unless the scan meets a different MAC address, host key or serial number than the asset holds, or an identifier another asset owns. Automatic scans are held as before. (#2268)
A TLS port that refuses the handshake is recorded as TLS, on the scan and on the asset. A server that needs a server name answers a scan of its address with a TLS alert, and the port was filed as an unidentified open port. It is now recorded as TLS with "handshake refused" in the scan's results and in the asset's endpoint list, with no crypto configuration, because nothing was negotiated. A scan of a known asset then offers up to three of the asset's known names to that port and records the configuration and the name that worked. A sensor built before this release does not retry with names. (#2268)
A server that requires a client certificate now yields a TLS finding. Under TLS 1.2 such a server ends the handshake after sending its certificate, and nothing was recorded. The version, cipher suite and certificate chain it sent are now kept, marked as an incomplete handshake. This applies to scans, the sensor's follow-up probe, device interrogation and cloud endpoints. (#2268)
When part of an Active Scan cannot be started, the assets left out are listed with the reason. If one batch of a "Scan all" was refused (a rate limit, a budget, a downstream error) while another started, the request reported success and the refused assets appeared nowhere. They are now listed as not scanned, and inventory-service logs every asset a scan request leaves alone. (#2268)
Disabling automatic scanning stops its worker again. Person-initiated Active Scans are now recorded as finished by their own worker, so setting DISCOVERY_AUTO_SCAN_WORKER_ENABLED=false stops the automatic-scan worker outright without leaving Active Scans reading "Scanning". (#2268)
Cloud endpoint TLS findings carry certificate validation and revocation status. Load balancers, API gateways and CDN endpoints found by cloud discovery were probed, and the chain validation, certificate quality flags and OCSP answer were thrown away. They are now stored and shown under Trust & revocation on the certificate. (#2268)
An Active Scan is recorded as finished, and a scanned asset leaves the unscanned list. A person's scan left its endpoints reading "scanning" for good, and an asset with no open port could never leave Discovery → Active Scan however often it was scanned. The scan is now settled when its jobs end (completed, or failed when it never reached the host), an asset whose scan completed leaves the list even when nothing answered, and the page and the asset drawer show a scan in flight instead of offering it again. Endpoints a previous version left reading "scanning" are settled from the scan that stamped them.
Passively observed TLS connections to third parties now get a strength rating. Every such connection showed as unrated: the rating is withheld while the size of an ECDHE or DHE key exchange is unknown, and passive capture never reported one. The sensor now reads the key-exchange group the server selected (and, for DHE, the length of its prime) from the part of the handshake that is sent in clear, and the active probes report the size of the group they negotiated. A connection whose handshake showed no group still stays unrated, and so does a TLS 1.2 connection whose certificate was not seen. Certificates signed with RSA were also left unrated because the signature name did not match the algorithm catalogue's spelling; that is fixed too. Sensors must be upgraded to report the group, and connections already on record are rated the next time they are observed.
"Service down: api-gateway" and "Service down: nats" no longer fire on a healthy install. Setting any backends.monitoring-service.extraEnv in your values replaced the chart's own list, which held the health monitor's probe targets; it then probed two hosts a Kubernetes install does not have and raised alerts that never cleared. The chart now sets those targets itself, whatever extraEnv holds. To change one, name it in extraEnv and your value replaces the chart's. Alerts already raised clear after the upgrade.
A plaintext-management finding is no longer cleared by a different source. A device found using SNMP v2c or telnet raised the finding, and a later SSH or HTTPS interrogation of the same device cleared it, because the most recent answer from any source won. Answers are now kept per management channel: a later SSH answer retracts telnet and HTTPS retracts HTTP, but neither says anything about SNMP. The finding names every plaintext protocol in use. Nothing can observe SNMP v2c being switched off, so resolve that finding by hand once it is. (#2243)
A device that did not report a protocol version is no longer scored as if it had one. The F5 and Cisco collectors filled in "TLS 1.2" or "SSH-2.0" when they had not read a version, which could hide a TLS 1.0 or SSH-1 device and pass a compliance control it never met. A version is now recorded only when something was read: the SSH version comes from the banner, and an F5 profile's version only when its options leave exactly one enabled. A configuration with no measured version shows Not measured and Partially assessed; a Medium or worse score from the measured parts stands, anything lower is shown as not assessed, and the TLS-version control reads not assessed. A version an earlier interrogation invented is removed the next time that device is interrogated. "Outdated SSH version" now also fires for SSH-1.99. Device agents built before this release keep sending the old value until they are upgraded. (#2237)
Deleting an organization removes all of its data. Thirteen tables were not linked to the organization, so its alerts, saved views, scopes, CBOM artifact records, invitations and plan overrides stayed behind after a purge. They are now removed with it, and the upgrade clears rows already left behind by earlier purges. Licence usage records are kept, as before. (#2235)
Terms and privacy acceptance records are removed with their organization. Deleting an organization now also deletes its people's acceptance records, and the upgrade clears any left behind by earlier purges. Erasing a single person still keeps their acceptances. The unused api_usage_logs table, which nothing ever wrote to, is dropped on upgrade.
UDP probes keep to the per-host packet rate. Under load the scanner could send datagrams to one host several times faster than the configured rate; the average held but the spacing did not. Each datagram now waits for the previous one to be written. (#2238)
A network no longer appears twice on Inventory → Map. A device another device reported (a wireless controller's client table, for example) was put in its network but given no site, so the map drew that network once under its site and again under "No site recorded". An asset in a network that has a site now takes that site whenever it records none, on every discovery path; a site you or a CMDB set is never overwritten. Existing assets correct themselves the next time they are observed. (#2220)
Passive capture records what the server negotiated. The sensor parsed only the client's half of a TLS handshake, so connections to third parties (which are never actively probed) carried no protocol version, cipher suite or certificate and could not be scored. Server replies are now captured and joined to their connection, including a certificate packed into the same record as the ServerHello. The IEC 62351 verdict is no longer computed from a ClientHello alone, and active TLS findings no longer carry an empty SSH banner. Needs the sensor from this release. (#2222)
A cloud listing that fails is reported as failed. An AWS API Gateway listing re-read its first page until it timed out and was then reported as "succeeded, 0 found"; a load balancer whose listeners could not be listed was skipped as if it had no TLS. Both now page correctly and report the resource type as failed or partial, and the run's outcome follows. (#2221)
Cloud-discovered assets no longer show a blocked enrichment. Every asset found through a cloud account ended with a source refresh "blocked — cloud source not identified" that nothing could clear. Evidence that came from the configured source itself now completes with nothing further to ask. (#2223)
Identity probes no longer flood a sensor. Several observations of one address each queued their own probe, filling the sensor's job queue and failing jobs with "sensor busy" alerts. Observations now share one probe per sensor and address, identity enrichment holds back while a sensor is busy and retries later without a tenant alert, and a job delivered more than once is no longer logged as a failed dispatch. Scans you start yourself still fail loudly when a sensor refuses them. (#2224)
A scan's "Results by host" lists every host that responded. It listed only hosts with an open port, so a /24 scan whose Coverage said "25 responded" showed "Hosts 1–10 of 10", with the other 15 reduced to a grey count — and read as broken paging. A host that answered with nothing open is now listed too, as one quieter line saying how its ports answered ("answered, nothing open (78 ports scanned: all refused)"), in address order among the others, and the list's count matches Coverage. (#2170)
A scan's findings are labelled as what they are. The job detail's Found tile counted open ports but read as new assets; it is now Open ports found with the hosts they are on ("15 open ports on 10 hosts"), and the approval tiles beside it say they count findings. (#2170)
The job detail says where findings that became no asset went. Findings identity could not tie to an asset yet — for example an address on a network that uses DHCP, which alone does not identify a device — are kept as observations; the job showed "0 pending approval" and nothing else. It now says how many findings on how many hosts were kept as observations and links to Discovery → Observations, where they are confirmed, linked or dismissed. (#2170)
A scan by address no longer records the address as the host's name. Each finding of a scan described by depth carried its IP address as its hostname, which identity rejected as a name on every finding (and logged), and which stopped the name being looked up from the certificate or reverse DNS. The hostname is now only a name the scan was given. The inventory log also says plainly when a finding was kept as an unresolved observation, instead of claiming a merge proposal with an empty id was opened. (#2170)
A scan by depth is no longer handed to a sensor that cannot run it. A discovery job with a scan depth that ran from a tenant sensor — chosen by Run from: Auto, or named — went to the sensor whatever software it ran, and a sensor that does not support scan depth read the job as "no protocols" and finished it having scanned almost nothing. Such a job is now handed only to a sensor that reports, on its heartbeat, that it can run it. Auto runs the job from the platform sensor instead and says why, naming such a sensor is refused with 409 sensor_scan_plan_unsupported ("upgrade it, or run the scan from the platform"), and a sensor replaced by older software after a job was created fails that job with the same reason rather than receiving it. Jobs that name protocols and ports (Active Scan, the automatic scan) are unchanged. (#2170)
A scan described by depth survives a crash of the platform sensor. When the replica running such a scan died (out of memory, a lost node), the job was marked failed five minutes later with "retry to resume" — and nothing on screen offered Retry. It is now put back in the queue and picked up by another replica, which carries on from the hosts not yet done, storing nothing twice. A job is resumed this way at most three times, so a scan that keeps bringing its scanner down stops; it is then failed, saying it "stopped after 3 automatic resumes". Jobs described by protocols and ports keep failing for a Retry, as before. (#2170)
Scanning industrial (OT/ICS) ports no longer waits after a port that is closed. The scanner pauses a quarter of a second between connections to a host's industrial ports so a controller can tear down the previous session. It paused after every one of them, so a host scanned at Thorough depth (19 such ports) spent about 4.5 seconds waiting even when none of them was open. It now pauses only after a port that accepted the connection; still one connection at a time. (#2170)
Approving a busy host no longer drops some of its TLS ports. While a discovered host waits in Discovery → Approvals, what it will add to the inventory on approval is parked with it, and two things lost data there: the same certificate served on several ports was parked once, so approval put the crypto configuration on one port only; and every open port nothing could name took a place in the parked list (capped at 50), pushing out the TLS ports found first. Each port is now parked separately, and ports with nothing to add — which are already on the host as endpoints — are not parked at all. (#2170)
"Cloud — platform sensor" discovery jobs now run. The Discover dialog's Cloud — platform sensor option sent execution_mode: "cloud", which the scanner read as a cloud-account discovery and handed to device interrogation, where the job failed with "no integration_id in job metadata". On POST /discovery/jobs, cloud now means "run from the platform sensor" and the job is stored and run in-cluster like any other platform scan. Cloud account discovery is unaffected. (#2170)
Discovery job Cancel and Re-run now actually reach the scan. The Cancel button on the Jobs page, the job detail and the Discover dialog answered "cancelled" and recorded a discovery.job.cancelled audit event without telling the scanner anything, and Re-run reported success while doing nothing. Both now go to the discovery service and report what it answered: cancelling a job that already ended, or re-running one that is not queued or failed, is refused with the reason (409) instead of reporting success, a job in another tenant looks like a missing one (404), and a failure is never shown as success. The audit event is written only after the cancel or re-run took effect, and the dialogs show the reason a cancel was refused. (#2170)
Sensor: WireGuard and OpenVPN are now actually detected. The sensor captured UDP 51820 and 1194 but then dropped every datagram on them before the WireGuard and OpenVPN decoders ran, so passive VPN detection never reported anything. A sensor with enableWireGuard / enableOpenVPN on (the default) now records each tunnel endpoint once, with its fixed WireGuard suite or the OpenVPN handshake fingerprint; turning a flag off still disables that decoder. (#2170)
Sensor: ports in extraPortsToMonitor are now actually decoded as TLS. The setting added the port to the capture filter, but the sensor then dropped every packet on it because it did not recognise the port, so TLS on a non-standard port (for example 9443) produced no discoveries. Listed ports are now treated as TLS, and never change what a built-in port (SSH, SMB, STARTTLS) means. Values outside 1-65535 are ignored. (#2170)
A discovery scan no longer silently scans only part of a large network. The scanner expands at most 4,096 addresses per CIDR or range and used to drop the rest without a word, so a /19 was scanned as its first /20 and the job still ended "completed". A target over that size, or targets that together name more than 16,384 addresses, are now refused when the job is created (422 scan_target_too_large, naming the target, its address count and the limit), and a standalone sensor refuses such a command instead of scanning the front of the block. Split a larger network across targets or scans.
A discovery job's protocols can no longer request industrial probes. POST /discovery/jobs accepted any protocol name in protocols and handed it to the scanner, so naming Modbus, OPC UA, EtherNet/IP or BACnet there started an OT probe without the separate ot_probe_protocols opt-in, its audit record and its one-standard-port limit. protocols now accepts only TLS, SSH, SMB and the TLS-wrapped names (HTTPS, SSL, LDAPS, SMTPS, IMAPS, POP3S, FTPS); anything else is refused with a 400 validation_error that lists the allowed values and, for an OT name, points at ot_probe_protocols. The Discover wizard, Active Scan and automatic scanning only ever sent TLS and SSH and are unaffected. The Discovery docs no longer list IPSec and VPN as scan protocols. (#2170)
A long discovery job runs once, and its progress is real. A platform-run job longer than about five minutes was handed out again by the message broker while it was still scanning, so every target was scanned twice and its findings stored twice; a late finish could also overwrite a job that had already failed or been cancelled. The processor now claims a job atomically and keeps the broker informed while it runs, so a repeat delivery does nothing, and completed, failed and cancelled are final. A job running during a restart is put back in the queue, and its next run skips the targets already completed, instead of being left running. progress on GET /discovery/jobs/{id} is now the share of the job's targets that are finished, with the counts in target_counts, instead of 0 / 50 / 100 by status; it is per target, not per host. Cancel now stops a running scan before its next host and keeps the findings already stored. A new tenant's first job no longer fails with a spurious "rate limit exceeded" when two copies of it are processed at once. (#2170)
A discovery job whose scanner crashed no longer stays running for ever. When the replica running a platform scan was killed (out of memory, a lost node), its job stayed running with nothing running it, and kept one of the tenant's concurrent-job slots, so a few such crashes stopped the tenant from starting any scan. A running job now records a heartbeat every minute; a job with no heartbeat for five minutes is marked failed ("scan stopped responding … retry to resume"), which frees the slot, and Retry resumes it without rescanning the targets it had already finished. A job put back in the queue by a restart is now picked up again even days after it was created (up to seven), not only within its first day. (#2170)
Creating a network segment for a range that is already a segment says so. It used to fail with a bare 500 "Failed to create network segment". It is now a 409 that names the segment holding the range. When that segment is a public range learned from one of your devices, the message says which device and points at Claim as mine on it instead of declaring the range again. The New segment dialog shows the message. Spreadsheet import still reports such rows as skipped duplicates. (#2170)