Elisity Release 26.7: Hierarchical policy, broader platform support, and deeper device context

Overview

Policy Groups have always been a flat list. Every group sits at the same level, and every group takes its own row and column in the Policy Matrix. That model carries a great deal of weight, and it scales further than most people expect.

What a flat list cannot express is relationship. Verified PCs running Windows, Linux, and macOS are all verified PCs, and most of the intent governing them is identical. Some of it is not, and those differences are exactly why the groups exist separately. Saying both things has meant saying the shared part again in every group that shares it.

Release 26.7 lets you say it once. Policy Groups can be organized into a hierarchy, so shared identity and shared intent live at the parent while finer-grained identities carry their own differentiated policy beneath it. That same structure extends to cloud workloads, the enforcement footprint reaches more of what customers are running, and Elisity IdentityGraph™ picks up new sources of device context.

Nested Policy Groups: One Policy for a Whole Family of Groups

Groups come in families. A hospital has verified PCs, and underneath them the Windows, Linux, and macOS builds that IT actually manages. A manufacturer has a device class that shows up on every production line, then a variant per site. The intent is largely shared across the family, and the differences that remain are the whole reason the child groups exist as separate identities.

Expressing that in a flat matrix means creating a separate group for every variant, repeating the same matching criteria in each one, and then setting the same policy in every cell where those groups intersect. It works. But the maintenance lands on the administrator: each change to the shared intent has to be made everywhere it appears, and copies drift apart over time.

Nested Policy Groups build the family into the model. A parent group holds the matching criteria its members share, and each child refines what it inherits rather than restating it. Verified PCs sits at the top, with Windows, Linux, and Mac beneath it, and a further level below that where the environment calls for one. Define once, narrow where needed.

Policy inherits along the same structure. In the Policy Matrix, a parent and its children render as one expandable block: collapsed, you see the family; expanded, you see every member on both Side A and Side B. Set a policy at the parent intersection and Cloud Control Center shows you which policies the change will create before you commit, then cascades it to every group beneath. Set a policy directly on a child and the child keeps it.

That combination is what makes the hierarchy usable in practice. An administrator can allow a specific path between Mac endpoints, then go to the top of the family and deny everything else across Verified PCs. The deliberate exception at the child level survives the family-wide rule. Each intersection can be set to Allow All, Deny All, or a Custom Policy, or left under Independent Control where a child should not follow its parent at all.

Reading the result matters as much as setting it. A collapsed parent carries an indicator of how many policies sit beneath it and whether any of them differ from the parent, so you can tell there is something underneath before you expand. Tooltips and cell labels distinguish an inherited policy from one that has been overwritten. The same hierarchy renders in the Policy Table view for the cases that do not fit a grid, and filtering scopes the matrix to the groups you care about so it stays navigable as the tree grows.

Administration can follow the same structure. Role-based access control applies per branch of the hierarchy, so a user can be granted management access to a single branch. The team that owns a business unit manages policy for that business unit without being handed the rest of the matrix.

One note on where this fits. Nested Policy Groups are not something every environment needs, and a program whose identities are genuinely flat should stay that way. This is built for environments where identity has real structure underneath it: device families with meaningful variation inside them, several teams sharing one matrix, and cloud workloads whose natural organization by provider, account, and environment is a hierarchy to begin with.

One Policy Model for Devices and Workloads

Elisity has supported cloud workloads for some time. Workloads are identity objects in Elisity IdentityGraph™ with their own attributes and their own place alongside the users and devices already there, and administrators have been working with them in Cloud Control Center as part of the same estate.

What this release changes is how you work with them. Workloads now carry Policy Groups of their own, in a dedicated Workload Policy Groups tab that supports creation, editing, duplication, nesting, and deletion, with the same filtering, CSV export, and role-based permissions as Device Policy Groups. They are managed in the same place, and the same way, as the groups you already run. Workload interfaces classify into those groups dynamically, the way device attributes already drive device group membership, and classification treats a workload as a distinct entity with multiple IP addresses, which is the right model for cloud instances whose addressing rarely maps one-to-one the way a switch-attached endpoint does.

Because these are ordinary Policy Groups, everything in the section above applies to them. Workload groups nest, inherit matching criteria from a parent, and cascade policy the same way device groups do. A provider, account, and environment structure is hierarchical to begin with, so the model maps directly onto how cloud environments are already organized. Workloads are enabled per policy set, so a rollout reaches only the scope you choose rather than arriving everywhere at once.

The practical effect is a single policy surface. Policy Matrix filters let each side independently target Devices or Workloads, so an administrator expresses intent that crosses the campus-to-cloud boundary in the matrix they already use: “the clinical workstations in this group should reach the application workloads in this account, and nothing else in that VPC.” There is no separate cloud policy console to keep in agreement with the campus one, and no parallel set of groups that means roughly the same thing.

Elisity has always held that policy should be written against identity rather than location, and identity is what lets one model cover everything on the network: the user, the device on the plant floor, the workload in the VPC. Each is another kind of thing to be grouped, governed, and held to least privilege. Each one you can express in the model you already run is one you don’t need a new tool to secure.

Know What a Policy Change Will Actually Touch

Asset counts on Policy Sets and in the Policy Matrix now reflect the assets affected by each policy intersection rather than a broader group total. When a reviewer approves a change, the number in front of them is the number of assets that change will hit. That’s a small edit to a label and a meaningful improvement to change control.

Filtering picked up several practical fixes at the same time. Selecting a Policy Group that’s already chosen on the opposite side of a filter now moves it to the new side instead of failing quietly. A one-click button swaps Side A and Side B, including their entity types. Policy Group options are scoped per side to the selected entity type, and switching a side’s type clears that side’s filters so you’re never looking at a stale selection.

Broader Platform Support, at the Edge and in the Cloud

Elisity enforces policy through the infrastructure customers already own, so the value of the platform is tied directly to how much of that infrastructure we support. Release 26.7 expands the footprint in two places.

Elisity has re-introduced support for HPE Aruba Networking CX platforms, and the deployment model behind it is considerably simpler. The previous approach depended on VXLAN being deployed in the network, which is not how most Aruba CX environments are actually built. That prerequisite is gone. Customers get identity-based enforcement and flow visibility on the Aruba CX switches they already run, managed from the same Cloud Control Center as the rest of the estate, with no overlay to stand up first. This continues the pattern of the last several releases, where we’ve added platform support based on what customers are actually running rather than trying to cover every switch on the market at once.

The Elisity Virtual Edge is now available as a versioned AWS AMI for deployment into a customer’s own VPC. Once launched on EC2, it registers with Cloud Control Center and integrates with standard VPC networking, including subnets, security groups, and elastic network interfaces. There’s no separate cloud construct to learn and no parallel operational model: the same Virtual Edge you run in the data center runs in the VPC, managed from the same control plane.

Day-two operations got attention too. Individual Elisity Virtual Edge Nodes can now be designated as externally managed for endpoint discovery on Cisco switches, which lets Elisity coexist with a third-party device-tracking tool rather than compete with it for the same configuration. The Virtual Edge keeps discovering and classifying endpoints from the switch’s existing device-tracking data without overwriting the other tool’s configuration, and the Endpoint Discovery tab becomes read-only on those nodes. A new Actual Status column shows the configuration running on the switch beside the expected state, so mismatched interfaces surface as a visible discrepancy instead of a support case three weeks later.

More Context in Elisity IdentityGraph™

Two connector additions expand what the platform knows about a device before policy is written.

The Palo Alto Cortex XDR connector enriches device records with endpoint security data, and it supports multiple instances per tenant. Organizations running separate Cortex XDR environments, which is common after an acquisition or across a global footprint with regional deployments, can ingest from all of them into a single IdentityGraph™.

The Tenable One connector brings a substantially richer set of OT data into the graph. Device Details shows OT criticality, risk, vendor, model, firmware, location, and tags, along with vulnerability and weakness counts by severity. Several of these attributes are available as Policy Group match criteria, which is the part that matters operationally: OT risk context stops being something you read in a dashboard and becomes something policy can act on. A device’s criticality or its vulnerability posture can place it in the group that governs it, so the exposure data your OT team already trusts starts driving segmentation directly.

Device Label Management moves labels out of ad hoc practice and into a governed library. Labels are managed centrally from Settings, organized into shared hierarchical folders, with bulk move and delete, search, filtering, and XLS import. Role-based access control governs who can create, modify, or delete them, and labels can be assigned or removed from the Devices page, from within Policy, or through the device API. Anyone who has inherited a label taxonomy built by three different teams over two years will understand why this one is on the list.

Connectors themselves are easier to operate. The Connector List shows how many devices each connector has enriched, and that count links straight to the Device List pre-filtered to that connector, which turns “is this integration doing anything” into a one-click answer. Connector settings now open in a dedicated full-page view split into primary and Advanced sections rather than a cramped side drawer. Custom Connectors support up to 30 predefined string attributes, up from 15, and 10 integer attributes, up from five, and Advanced settings now control offline device enrichment per connector instance.

A Longer View of Overly Permissive Policy, and One Place to Act on It

Tightening an overly permissive policy comes down to one question: has this Allow actually carried traffic? Answering it honestly depends on how far back you can look. A window that only covers a few weeks makes a path that runs on a monthly or quarterly cycle appear unused, and acting on that reading breaks the job the first time it runs.

Overly Permissive Policy analysis now supports a longer look-back window, so the analysis can span the cycles that matter in your environment: the backup that runs monthly, the maintenance window that comes quarterly, the reporting job that runs semiannually or once a year. When an Allow policy shows no traffic across a window that covers the full cycle, that is a finding you can act on rather than a gap in the data. It is the difference between suspecting a permit is unused and knowing it.

Policy creation and activation have also moved into the Elisity Assistant. Simulation Suggestion Policies and Activation Suggestion Policies now appear directly from the Policy Matrix alongside Overly Permissive Policy Insights, with a live overlay so suggestions are visible in the same view where you would act on them, and policies can be created or activated in bulk from there.

Policy That Grows the Way Your Environment Does

The through line in 26.7 is structure. Hierarchy and inheritance let a policy model grow with the environment without a matching increase in the number of rules a person has to hold in their head. Per-branch access control lets that structure be operated by more than one team. Policy-scoped asset counts and a longer view of overly permissive policy make each change more predictable before it is approved. And because workloads sit in the same policy model that already covers devices, campus and cloud stay one platform and one operating model rather than two products stitched together.

Release 26.7 at a Glance

Frequently Asked Questions

Does Elisity support HPE Aruba Networking CX switches?

Yes. Release 26.7 re-introduces Aruba CX support with a considerably simpler deployment model. The earlier approach depended on VXLAN being deployed in the network, which is not how most Aruba CX environments are built. That prerequisite is gone, so identity-based enforcement and flow visibility run on the Aruba CX switches you already have, managed from the same Cloud Control Center as every other supported platform. If you are running an existing Elisity deployment on Aruba CX, talk to Elisity Support before you move, as this is a change in deployment model rather than a straight upgrade.

What problem do Nested Policy Groups actually solve?

They let you give finer-grained identities their own differentiated policy without repeating the intent they share. A parent group holds the matching criteria its members have in common, and each child refines what it inherits rather than restating it. Policy cascades the same way, so a rule that should govern a whole family is set once at the parent, while a deliberate exception set on a child survives that cascade. This is not about handling a larger number of groups. A flat list already scales further than most people expect. It is about expressing structure that is genuinely there.

Do we need Nested Policy Groups?

Not necessarily. If your identities are genuinely flat, a flat set of Policy Groups remains the right model and there is no reason to move. Nesting earns its place where device families carry meaningful variation inside them, where several teams share one matrix, or where cloud workloads are organized by provider, account, and environment, which is already a hierarchy.

Can different teams manage their own policy without seeing everyone else’s?

Yes. Role-based access control applies per branch of the Nested Policy Group hierarchy, so a user can be granted management access to a single branch. The team that owns a business unit manages policy for that business unit without being handed the rest of the matrix.

How are cloud workloads handled in the policy model?

Workloads carry Policy Groups of their own, in a dedicated Workload Policy Groups tab supporting creation, editing, duplication, nesting, and deletion, with the same filtering, CSV export, and role-based permissions as Device Policy Groups. Workload interfaces classify into those groups dynamically, and a workload is modeled as a single entity with multiple IP addresses rather than as a set of unrelated hosts. Because these are ordinary Policy Groups, they nest and inherit exactly as device groups do, and either side of the Policy Matrix can target Devices or Workloads. Workloads are enabled per policy set, so the scope of a rollout is yours to choose.

Can the Elisity Virtual Edge run in AWS?

Yes. The Virtual Edge is available as a versioned AWS AMI for deployment into your own VPC. Once launched on EC2 it registers with Cloud Control Center and works with standard VPC networking, including subnets, security groups, and elastic network interfaces. It is the same Virtual Edge you run in the data center, managed from the same control plane.

Will Elisity conflict with the device-tracking tool we already run on our Cisco switches?

No. Individual Virtual Edge Nodes can be designated as externally managed for endpoint discovery. The Virtual Edge continues to discover and classify endpoints from the switch’s existing device-tracking data without overwriting the other tool’s configuration, and the Endpoint Discovery tab becomes read-only on those nodes. An Actual Status column shows the configuration running on the switch beside the expected state, so a mismatched interface is visible rather than latent.

How far back can Overly Permissive Policy analysis look?

The look-back window for Overly Permissive Policy analysis is configurable, so it can span the cycles that matter in your environment rather than a fixed default. The default is 30 days.

How does OT risk data affect policy?

The Tenable One connector brings OT criticality, risk, vendor, model, firmware, location, and tags into Elisity IdentityGraph, along with vulnerability and weakness counts by severity. Several of those attributes are available as Policy Group match criteria, so a device’s criticality or vulnerability posture can place it in the group that governs it. The exposure data your OT team already trusts drives segmentation directly rather than sitting in a separate report.

Can we ingest from more than one Cortex XDR environment?

Yes. The Palo Alto Cortex XDR connector supports multiple instances per tenant, so organizations running separate Cortex XDR environments, which is common after an acquisition or across regional deployments, can ingest from all of them into a single IdentityGraph.

Availability

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

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