Elisity Release 26.8: Policy you can prove, enhanced cloud workload capabilities, and identity you can validate

Elisity Release 26.8 adds recorded policy reviews, scheduled IEC 62443 compliance reports from live data, suggested policy for ungoverned paths, and enhancements to Elisity’s cloud workload capabilities in AWS and Microsoft Azure.

Overview

A microsegmentation program is judged twice. The first time is when policy goes live and the network keeps running. The second time is months later, when an auditor, a board, or an incident review asks a harder question: how do you know this policy is still right, and what proves it?

Most programs answer the second question badly. The policy is fine; the evidence is not. Reviews happen in meetings and leave no trace when nothing changed. Compliance mappings live in spreadsheets that were accurate on the day someone built them. And somewhere in every matrix there are paths between groups that nobody ever wrote a rule for, which means they are governed by a default rather than by a decision.

Release 26.8 is built around closing that gap. Policy reviews are recorded even when nothing changes. Compliance reports are generated from live data, on demand or on a schedule, starting with IEC 62443. Ungoverned paths are identified and given a suggested policy for an administrator to approve. Alongside that, the release delivers enhancements to Elisity’s existing cloud workload capabilities for campus-to-cloud policy, new ways to validate device identity, and a visibility-only onboarding option for Aruba switches.

Policy You Can Prove

A review that leaves a record

Periodic policy review is a familiar control for any team that answers to auditors. The awkward part has always been the review that concludes “no change needed.” The policy was examined, the decision was sound, and there is nothing in the system to show it happened.

Release 26.8 fixes that. Completing a policy review now records a timestamped event with the reviewer’s identity and any notes, whether or not anything changed. The audit trail shows that someone looked, when they looked, and what they concluded.

Compliance evidence from the live environment

Snapshot reporting now includes compliance reports that map Elisity capabilities to industry framework controls, starting with IEC 62443. Each report produces coverage scores and evidence-backed audit documentation built from live data rather than from a document someone maintains by hand.

The mapping follows the standard’s own model. In IEC 62443 terms, Policy Groups implement zones (groups of assets with common security requirements), and the policies between Policy Groups implement conduits (the permitted communication paths between zones). Because Elisity already expresses the environment in those terms, the report describes the environment as it is today, not what a diagram said last quarter.

Reports can be generated on demand, through the API, or on a recurring schedule, so audit evidence is current every time someone asks for it. They also export in Markdown, which drops directly into the version-controlled repositories and ticketing workflows where audit evidence tends to end up anyway.

Every Path Explicitly Governed

A Policy Matrix tends to be most carefully defined where someone was worried. The pairs nobody worried about are often the pairs nobody wrote a policy for.

Elisity Insights now identifies source and destination Policy Group pairs with no governing policy and recommends an explicit allow or deny policy for each. Elisity Insights evaluates each Policy Group’s configuration directly to produce a suggestion tailored to that pair. Nothing is applied automatically: an administrator reviews each suggestion and approves it before it takes effect. Agentic, not autonomous.

The result is a matrix where every communication path reflects a decision, and where the remaining gaps are visible as a list of suggestions rather than invisible as default behavior.

Policy Group suggestions have also become more trust-aware. Suggestions now account for whether the connector data behind them is verified and trusted, and they stay current as that trust changes. Administrators can create nested Policy Groups directly from a suggestion, building on the hierarchical policy model in Release 26.7.

Enhancements to Elisity’s Existing Cloud Workload Capabilities

Cloud workloads in AWS and Microsoft Azure are governed in the same identity-based policy model as devices. Workloads are identities in Elisity IdentityGraph™, organized into Workload Policy Groups, and policy is written between those groups in the same Policy Matrix used for every other part of the estate. Release 26.8 enhances that model for the use case most organizations start with: controlling which campus and plant devices can reach which cloud applications.

Clear precedence when addresses overlap. Cloud addressing does not always stay out of the way of campus addressing, and an overlapping address is exactly where a policy decision can go wrong. Elisity IdentityGraph™ now detects when a cloud workload shares an enforcement address with a campus device or with another workload, and determines which identity’s policy takes precedence, with campus devices given priority. Conflicts between workloads are surfaced for an administrator to resolve rather than settled silently.

Workload identity distributed where it is needed. Distribution Zones are how Elisity scopes identity-to-policy mappings to the parts of the network that enforce them, mapped onto the topology an organization already has. Workloads now take part in that model directly. Each AWS or Azure discovery source can be assigned to a specific Distribution Zone, and a dedicated Workload Distribution Zone keeps cloud workload mappings separate from Access and Core zones while making them available to the Core zone. The result is optimal distribution for campus-to-cloud enforcement: workload identity reaches the parts of the network that enforce campus-to-cloud policy, and the Workload Details page shows where each workload has been placed.

Validating Identity, Not Just Recording It

Visibility is the precondition for policy. An identity that is wrong produces policy that is wrong, so Release 26.8 adds new ways to check it.

DNS Analytics. A new DNS Analytics view shows DNS request trends, top domains, DNS servers, and the devices behind them. For any device, Elisity compares its Elisity IdentityGraph™ identity with a classification derived from its observed DNS activity. When a device claims to be one thing and behaves like another, the difference is visible in one place, before it becomes a policy decision.

Richer user and OT context. Users from Entra ID are now easier to recognize when building Policy Groups, and logon history shows whether each logon came from Active Directory or Entra ID, which matters to any organization running both. Claroty-sourced SSID and domain attributes can now define Policy Groups.

Discovery Only Mode for Aruba Switches

Some switches are onboarded for visibility alone. An organization may want discovery and flow data from part of its network without Elisity placing any enforcement configuration on those switches, and with no plan to change that. Discovery Only mode, now available for Aruba switches running Elisity’s Access Policy implementation, supports exactly that choice: endpoint discovery and flow telemetry run as normal, the devices behind those switches appear in Elisity IdentityGraph™ with their full context, and no enforcement configuration is placed on the switch.

Discovery Only mode is a deployment choice for visibility-only switches, not a step toward enforcement. Validating policy before it is enforced is what simulation is for.

Policy That Stands Up to Review

The through line in 26.8 is accountability. A microsegmentation program earns trust by being able to show its work: which paths are governed and by what decision, when a policy was last reviewed and by whom, and how the enforced environment maps to the framework an auditor will measure it against. Release 26.8 puts that evidence in the platform, generated from live data and refreshed on a schedule, rather than in documents that age the moment they are saved. And because cloud workloads sit in the same policy model as everything else, the same evidence covers campus and cloud.

Release 26.8 at a Glance

Frequently Asked Questions About Elisity Release 26.8

How does Elisity help with periodic policy reviews?

Completing a policy review records a timestamped event with the reviewer’s identity and optional notes, even when no change was made. Reviews that conclude “no change needed” leave an auditable record instead of disappearing.

Does Elisity produce IEC 62443 compliance reports?

Yes. Elisity generates compliance reports that map its capabilities to industry framework controls, starting with IEC 62443, with coverage scores and evidence-backed audit documentation built from live data. Reports can be generated on demand, through the API, or on a recurring schedule, and exported in Markdown.

How do Elisity Policy Groups map to IEC 62443 zones and conduits?

Policy Groups implement zones, grouping assets with common security requirements. Policies between Policy Groups implement conduits, defining the permitted communication paths between zones.

What happens to Policy Group pairs that have no policy?

Elisity identifies source and destination Policy Group pairs with no governing policy and recommends an explicit allow or deny policy for each. An administrator reviews and approves every suggestion before it is applied; nothing is enforced automatically.

How does Elisity suggest policy for ungoverned paths?

Elisity Insights evaluates the configuration of each Policy Group in an ungoverned pair and generates a tailored allow or deny suggestion. An administrator reviews and approves every suggestion before it takes effect. Agentic, not autonomous.

What happens if a cloud workload and a campus device share an IP address?

Elisity IdentityGraph™ detects the overlap and determines which identity’s policy takes precedence, with campus devices given priority. Conflicts between workloads are surfaced for an administrator to resolve.

Can Elisity onboard switches for visibility only?

Yes. Discovery Only mode for Aruba switches running Elisity’s Access Policy implementation runs endpoint discovery and flow telemetry without placing any enforcement configuration on the switch, for organizations that want visibility from those switches and nothing more.

How does Elisity validate a device’s identity using DNS?

DNS Analytics compares a device’s Elisity IdentityGraph™ identity with a classification derived from its observed DNS activity, so a mismatch between what a device is said to be and how it behaves is visible in one place.

Availability

Elisity Release 26.8 is available now. Complete details, including API updates and configuration command changes, are in the 26.8.0 release notes. (Customer Login Required)

Next step: Schedule a demo to see how Elisity delivers identity-based microsegmentation on the network infrastructure you already own.