26.8.0 - Aug 18
Released: 2026-08-18
We're happy to announce the immediate release of Forward Enterprise version 26.8.0.
What's New 🚀​
Topology​
Staged Topology Link Overrides​
Editing topology link overrides no longer forces an immediate snapshot reprocess. Previously, saving a link override inside a location invalidated the snapshot and kicked off reprocessing so the change could be reflected in the topology and path search. For customers with dozens of locations and long-running snapshots, that turned routine edits into a slow process.
Link override edits are now staged instead of applied on save. Staged overrides are picked up automatically on the next snapshot collection, the same way synthetic device changes already work. The editing experience stays familiar: added, deleted, and modified links are all still editable directly from the topology or the Manage Links drawer, and overrides are now clearly differentiated into three buckets by color: applied, staged, and unsaved changes in the current session. Deleted overrides are hidden by default so the view and edit topologies stay consistent.
Per-ESX Host Location Assignment​
VMware ESX hosts can now be assigned their own locations, so multi-site hypervisor environments are reflected accurately in the digital twin. Previously, all hosts under a vCenter were bundled together and inherited a single vCenter-level location, which meant a vCenter environment spanning two sites could not be represented correctly in the physical topology.
With this release, vSwitches, including the per-host portions of distributed virtual switches (vDS), are bundled per ESX host rather than per vCenter, and vCenters no longer appear in the topology. The location assignment step has moved from the vCenter to the ESX host: during onboarding and in edit settings, each discovered host gets its own location column, so you can assign the same or different locations per host. Newly introduced ESX host nodes also display short names for easier reading and zooming when many hosts share a location.
For existing networks, the location previously assigned to the vCenter is transferred to its ESX hosts on upgrade, so all hosts start with the vCenter's location and can then be split across sites as needed.
Collection & Platform Updates​
Device-to-Collector Assignments​
Networks are no longer limited to a single collector. Historically, one collector served an entire network, which would cause problems when no single collector could reach every part of the network; jump servers helped, but were not always sufficient.
You can now set a preferred collector per source, for devices, clouds, Cisco ACI, and other source types. A network still has a default collector used by any source that does not specify its own, and you can override it by editing an individual source and selecting one of the collectors available to the organization. Collectors work in parallel, and remote collectors are supported on-premises as well.
The collector is a preferred assignment: for complex devices with a parent and child devices, the collector specified for the parent always wins, so assignments should be made with parent devices in mind to avoid conflicts. Rate limiting currently applies per collector.
New Device Support and Collection Options​
- Check Point Quantum Spark: Forward Enterprise now supports the embedded Gaia SMB gateway (Spark). Similar to the Quantum 600 series, collection uses expert mode over SSH, plus the security manager (API or SSH) for rule bases. Unlike mainline Quantum devices, Spark does not support TACACS privilege escalation.
- Cisco ASA Escalation Login: A new privilege escalation type for ASA, an alternative to the enable command. Instead
of running the
enableescalation, the device can run theloginescalation and prompts for a second username and password that can differ from the initial login credentials. You can set it manually, in which case enable is skipped; if neither is selected, Forward Enterprise auto-discovers an enable password first and then falls back to escalation login.
Security & Compliance​
Custom Vulnerability Analysis APIs​
Custom Vulnerability Analysis now exposes a set of five APIs so customers can automate the vulnerability workflows they previously drove only through the UI. Teams with remediation SLAs that begin at detection can script the overrides they need: for example, moving all newly discovered CVEs to a Not Analyzed or Not Vulnerable status and labeling them as pending analysis, all without manual clicks.
The APIs cover reading how many custom definitions exist for a given CVE, reading the current definitions for a CVE and OS, and setting, deleting, or appending rules (append adds a new rule to the end of the existing rules). Full API documentation is published alongside the release. They are reported here for convenience:
| Endpoint | Description |
|---|---|
GET /networks/{networkId}/vulnerabilities/{cveId}/analyses | List the custom analysis definitions for a CVE |
GET /networks/{networkId}/vulnerabilities/{cveId}/analyses/{os} | Read the analysis for a CVE on a given OS |
PUT /networks/{networkId}/vulnerabilities/{cveId}/analyses/{os} | Set (replace) the analysis for a CVE and OS |
POST /networks/{networkId}/vulnerabilities/{cveId}/analyses/{os}/rules | Append a rule to the existing analysis |
DELETE /networks/{networkId}/vulnerabilities/{cveId}/analyses/{os} | Delete the analysis for a CVE and OS |
Custom vulnerability conditions also gain a new Model column, in addition to the existing device name, tags, location, and OS conditions, giving customers finer control over how definitions are scoped.
- Aruba Switch Vulnerability Analysis: Both OS and configuration vulnerability analysis are now supported for Aruba switches, which previously had no vulnerability coverage.
- DISA STIG Y26Q3 Update: This release incorporates the DISA STIG update posted in early July.
Network Setup​
Juniper Mist Onboarding Wizard​
Forward Enterprise adds a guided onboarding wizard for Juniper Mist. In this release, onboarding and network modeling cover Mist access points. Given a Mist account, Forward Enterprise discovers and adds all configured access points and models them.
Mist joins Meraki and VeloCloud under the Cloud Managed network devices tab. The wizard walks you through naming the account, selecting the region (which determines the API host used for connectivity tests and collection), and providing the account API key, with an optional cap on concurrent API requests. After the connectivity test succeeds, access point discovery runs automatically and lets you choose which devices to collect, with names and MAC addresses shown and optional locations and tags. An edit page lets you update account settings later, and a device refresh action re-runs discovery to pick up access points added to the account after onboarding.
Merge Accounts in AWS Multi-Account Onboarding​
Adding a new account to an existing AWS multi-account setup no longer replaces the accounts already configured. A new toggle in the AWS onboarding drawer switches between merge and replace: with merge on, uploading a new account JSON adds it to the existing list without disturbing the other accounts, which is what most admins want; with merge off, the previous replace-all behavior is preserved. The drawer also adds error handling for invalid or empty JSON files.
Adjacent Network Synthetic Device (Early Access)​
A new Adjacent Network synthetic device type models external networks that act as a traffic sink only. Unlike L3VPN or intranet synthetic devices, an adjacent network can originate and receive traffic but does not provide transit routing. It otherwise behaves like the existing L3 synthetic devices: it supports multi-homing across multiple uplinks, appears in every location with a connected uplink, allows manually configured owned subnets so it is addressable as a path search source or destination, and offers subnet auto-discovery via BGP routes, IP routes, and interface addresses. As with the other L3 synthetic devices, an NQE query can drive its uplink connections dynamically, keeping them in sync on each snapshot. It is intended to eventually replace the legacy edge node solution.
This feature is in early access.
Integrations​
Actionable ServiceNow CMDB Push Errors​
Push failures in the ServiceNow CMDB integration now return actionable, specific error messages. Previously the errors were not as informative, leading to support tickets and manual inspection of CIs.
Errors now identify the exact CI table, field, and expected type for a mismatch (for example an integer value pushed to a string column), and for reference fields such as company, they name the reference table the value was not found in. Each error includes a note on how to fix the issue, and similar errors are grouped with a count of affected CIs rather than repeated, so a push that fails for 25 records shows a single error noting how many CIs were affected.
NQE Analysis​
Faster NQE Library Commits​
Committing queries in large NQE Library repositories is now dramatically faster. Committing is a two-step process: the system first analyzes the impact of a change (which queries import the definitions being changed, and whether they would break) and then applies the commit. For customers with very large repositories, some with over 10,000 queries, each step took roughly 30 seconds, making commits slow.
NQE now maintains a lightweight query index holding just the query dependency graph, providing fast access to the metadata the impact analysis needs. With the index in place, commits on 10,000-query repositories drop from about 30 seconds to one or two. The index is small, expires after 14 days of disuse, and is rebuilt on the next commit, so a fresh index is generally always available; it is also rebuilt on the first commit after each major release.
User Interface​
Onboarding Flow Improvements​
The new onboarding experience gains escape hatches so users are never stuck mid-flow. Previously, a user who started an onboarding step but had no devices to add could not unlock Explore, and therefore could not complete onboarding. Two new actions now accompany the wizard's Next button: Quit and remove from onboarding, for a step started by mistake with no devices added, and Quit and mark as complete, for a step where devices were already added. Users can also now uncheck in-progress onboarding device types from the edit drawer, a restriction that previously applied only before a step started.
Modeling​
- Huawei CloudEngine S Series: Modeling support is added for Huawei CloudEngine S series devices, which previously produced output the modeler could not handle. Support is automatic under the Huawei device umbrella; no user action is required.