Policy Matrix

The Policy Matrix offers a visual representation of all Policy Groups and the policies that exist between them. It is also an interactive way to rapidly build policies between known and unknown assets and to the internet. The Policy Matrix also offers asset traffic mapping and a look into how traffic is affected by deployed and simulated policies.

Building an Elisity policy is as simple as specifying the source and destination of the traffic as well as the desired security rules. The match criterion for source and destination is very flexible and includes identity based attributes such as Active Directory group, Department, Title , device type, device vendor, device model and much more.

There are a couple of ways to select your source and destination objects: using the Policy Matrix, or manually. This article covers deploying a policy using the Policy Matrix. For manually deploying a policy, see Creating Policies. As a reminder, all access is allowed by default until a policy explicitly denies it (default allow rule).

The Policy Matrix

The Policy Matrix is used to show what policies are deployed and give a visualization of the type of traffic that is or is not allowed to flow.

If you have not yet created Policy Groups, your Policy Matrix will be empty with only the default Policy Groups. Go deploy Policy Groups before using the Matrix following this article.

The Policy Matrix

The Policy Matrix is simply a structure of cells at the intersection of each Policy Group. You can click on the cells to deploy a policy between two Policy Groups very rapidly, using pre-defined Security Profiles or creating new Security Profiles as you go. Green cells indicate an Allow All policy, Red cells indicate a Deny All policy, and Blue cells indicate a custom policy. White cells have no policy defined, and allow all traffic by default. You may also notice arrows on some cells - these arrows indicate that this is a return traffic policy. We will get into that later in the article.

Hovering over a source Policy Group, Destination Policy Group, or Policy cell will display information about the Policy Group or a high-level summary of the policy. Clicking on a Policy Group surrounding the Policy Matrix will reveal additional information about the match criteria is being used, as well as a link to view and edit the Policy Group.

Hovering over a Policy Group reveals the following:

Policy Group Name - The full length name of the Source or Destination Policy Group.
Number of Matched Assets - How many devices are associated with this Policy Group.
Group Tag Value - The numeric value used to identify the Policy Group on access infrastructure.
Policy Group Description - User-defined description of the Policy Group.

Hovering over a Policy in the Matrix reveals the following:

Name - The name of the Policy
Policy Status - Active or Simulated
Security Profile - The name of the custom or default Security Profile used in the Policy. This field is not shown for Independent Control policies.
Final Policy Action - Allow All or Deny All. This field is not shown for Independent Control policies.

Independent Control policies do not have a Security Profile or Final Policy Action — these fields display as “––” in the Table (Records) and Traffic views. Enforcement for these policies is delegated to an external device (Cisco, Palo Alto Networks, or Other), so Elisity applies no Security Profile or Final Policy Action.

Clicking an empty cell will pre-fill the source and destination Policy Groups, allowing users to select a security profile, or create a new Security Profile, choose your final policy action, choose to create a return path policy, and deploy a policy in just a few seconds. To better understand the policy creation page, view this article. The return path option does not apply when the source and the destination are both Workload Policy Groups — see Workload-to-Workload Policies.

Views

The Policy Matrix can be displayed two ways, and you switch between them with the view toggle at the top left of the page:

Matrix view displays your policies as a grid of cells at the intersection of each source and destination Policy Group. This is the fastest way to see coverage across an entire Policy Set at a glance and to create policies by clicking a cell.

Table view (also called list view) displays the same policies as rows. It exposes additional columns that are not available in matrix view — such as Policy Type, Status, Last Modified, and Created On — and gives you per-policy actions, so it is the better choice when you need to locate, inspect, or edit one specific policy.

Your view selection, along with any filters you apply, is kept separately for each view. See Custom Filters for how to narrow either view down to the policies you care about.

Custom Views have been replaced by saved filters: Earlier releases let you save a Custom View that limited the Policy Matrix to a chosen subset of Policy Groups. As of release 26.6, Custom Views have been removed from the Policy Matrix and that capability is now provided by saved filters, which can narrow the matrix by source, destination, Policy Group Label, Security Profile, and more. If you are looking for the View menu or the Create Custom View option, use the Filters control instead.

Your existing views were migrated for you: Any Custom Views you had saved are converted to saved filters automatically, the first time you sign in to release 26.6 or later. The migration runs once per user and covers every Policy Set, and a one-time message notifies you that the change has taken place. You do not need to re-create your views by hand.

One difference to be aware of: Custom Views were shared — every user in your tenant saw the same list. Saved filters belong to the individual user account that creates them, so a colleague will not automatically see a filter you save. To share one, use the export and import options described in Custom Filters. Like Custom Views before them, saved filters are scoped to a single Policy Set: a filter saved in one Policy Set does not appear in another, so if a filter you expect is missing, confirm which Policy Set is selected.

Within the table view, you can still view, edit, and set policies as active or simulation (depending on the current state.) Simply click on the three dots to the right of the policy to view what actions are available. For Return-Path Policies, you can only view the policy, which will allow you to then click through to the main policy. For Active and Simulated policies, more options are available to the user that are context dependent.

Nested Policy Groups

Policy Groups can be organized into nested hierarchies, where a parent Policy Group contains one or more lower-level Policy Groups. The Policy Matrix reflects this hierarchy on both the source and destination axes, and you can expand or collapse a parent group to control how much of the hierarchy is shown at once. For details on creating and nesting Policy Groups, see the Policy Groups article.

When a parent group is collapsed and its lower-level policies are hidden, the empty root cell for that group displays a count of the hidden policies. This keeps policy that exists deeper in the hierarchy visible at a glance, even when the underlying Policy Groups are folded away. The count appears only on the empty root cell — for example, on the cell where a parent group intersects with itself — and not on the individual child cells.

Policy can be defined at more than one level of a nested hierarchy. When a cell contains a policy that overrides an inherited policy from a higher level, hovering over the cell displays an Overwritten Policy field naming the inherited policy being overridden. This lets you quickly identify where a more specific policy takes precedence over one inherited from a parent Policy Group.

Multiselect

Create Multiple Policies

With Create Multiple Policies, you can assign different policy types (Allow All, Deny All, and Custom) across multiple cell selections in a single session — no need to complete a full workflow per policy type before moving to the next.

1. Click Create Multiple Policies.
2. Select the desired cells using any selection method: click a row or column header, Shift+click individual cells, or click and drag a range.
3. In the action panel that appears, assign a policy type to the current selection:
   • Allow All
   • Deny All
   • Custom Policy — opens a configuration drawer where you define the policy rules
   • Independent Control — opens a vendor selection popup where you choose from Cisco, Palo Alto Networks, or Other
4. Return path is selected by default. It does not apply to selected cells where both sides are Workload Policy Groups.
5. Repeat steps 1–4 to assign different policy types to additional cell selections within the same session. You do not need to save between assignments.
6. Click Save Changes. A Review/Summary drawer appears showing all pending policy changes.
7. Choose Save as Simulation or Save as Active.

Note: If another user modified any of the selected cells during your session, a conflict error message is displayed. Resolve the conflict before saving.

Custom Filters

Custom filters can be created and saved in both table view and matrix view. Both views have their own separate saved filters, offering the flexibility to have different custom filters in each view that leverage the different criteria available.

Saved Filters per Policy Set: Because each Policy Set can have its own unique subset of Policy Groups, filters are saved per Policy Set. This means that filters saved in one Policy Set will not appear in the list of saved filters for other Policy Sets.

Import and Export Functionality: Saved filters can be exported and imported, allowing filters to be shared between users in Cloud Control Center.

In Matrix view, the policy matrix can be filtered to show select sources, destinations, and even selected Security Profiles. These filters can be saved and loaded at any time with just a couple of clicks.

To create or load a custom filter in the matrix view, click All Filters in the filter bar above the Policy Matrix.

The filter panel groups the available filter attributes under Side A, Side B, and Matrix. Select an attribute, select the appropriate values, then click Apply. You can filter on a number of key values in Matrix view:

Filter	Description
Source	The Policy Group that is defined as the source in the policy, determining which entities the policy applies to.
Destination	The Policy Group that is defined as the destination in the policy, specifying the entities affected by the policy.
Policy Group Label	The higher-level categorization that groups multiple Policy Groups under a common label for easier policy management and assignment to PSETs.
Policy Group	The logical grouping of devices or users that share the same access and security policies.
Security Profile	The set of security controls defining how traffic is inspected, monitored, and enforced within the policy.
Security Level	A classification indicating the risk or sensitivity of a Policy Group, influencing policy enforcement and access permissions. See Policy Set Enforcement Scores

You can layer multiple filters to create granular, multifaceted filters to narrow down the matrix view to only the data that you need. You can also import filters shared by colleagues.

To load a filter, go to saved filters and select a previously created filter. Here is also where you can also export any saved filters to share with other Cloud Control Center users.

In table view, there are three buttons that appear giving you view customization options, refresh, and policy download functionality.

Table view offers more columns with data not available in the matrix view for filtering down to specific policies. Some of the column filter options can be seen in the screenshot below.

Filtering by Devices and Workloads (Side A and Side B)

Matrix filtering is organized around two sides of a policy: Side A and Side B. Each side has its own filter chip that shows the side label, the entity type currently selected for that side, and a count of the active selections — for example, Side A · Devices · 2.

Each side includes an entity sub-selector where you choose whether that side filters on Devices or Workloads. Choosing Workloads for a side switches that axis to Workload Policy Groups, allowing you to view and build policy in a Device-to-Workload or a Workload-to-Workload matrix. Each side is set independently, so you can select Workloads on Side A, on Side B, or on both sides at the same time.

The Workloads option is available only when the Workloads feature is enabled. When Workloads is not enabled, each side filters on Devices only. For configuring the AWS connector, enabling Workloads, and organizing workloads into Workload Policy Groups, see Configure Cloud Workloads Visibility for AWS.

Workload-to-Workload Policies

When Side A and Side B are both set to Workloads, the matrix intersects Workload Policy Groups with each other, so you can build policy directly between two workload groups. These cells behave like any other cell in the matrix: click a cell to choose a Security Profile and a final policy action of Allow All, Deny All, or a custom policy, and include the cell in a Create Multiple Policies selection.

A cell between two Workload Policy Groups does not create a return path policy, and each direction is an independent policy. Allowing traffic from one workload group to another on a given port does not allow connections to be initiated in the reverse direction; to permit connections that are initiated the other way, create a separate policy on the opposite cell. The enforcement points that carry workload policy are stateful — AWS security groups, Azure network security groups, GCP firewall rules, Cilium, Istio, and the Linux host firewall — so reply traffic on a connection you have already allowed is permitted without a return path policy. Cells that involve a device Policy Group are unchanged and still offer the return path policy.

The matrix traffic view shows both allowed and denied traffic for workload cells, so you can confirm that a policy is having the effect you intended and identify connections that are being dropped. Cells where the observed traffic was allowed are filled green, cells where traffic was denied are filled red, and a cell that has seen traffic in both states appears split between the two colors. Select the Legend tool in the toolbar for the full set of colors and icons.

Note: A workload that matches no Workload Policy Group is placed in the Unassigned Workload Policy Group, which appears on both axes like any other workload group. In AWS, workloads in this group are isolated until they are classified. See Configure Cloud Workloads Visibility for AWS.

Tool Bar and Traffic View

Toolbar Tools

Tool	Description
Refresh	Reloads the Policy Matrix to reflect any updates to policies, traffic, or configurations without leaving the view.
Show (Hide) Traffic Flow	Opens the Flow view to show where traffic has been observed in the network, whether that traffic was allowed or blocked, and whether a policy is in place. For full details about the Traffic Flow View feature in Cloud Control Center, click here.
Reveal More Characters	Expands truncated Policy Group or service names, allowing full visibility of names and details within the matrix.
Accessible View	Removes color coding from the Policy Matrix and replaces it with patterns to improve readability for users with color vision deficiencies.
Zoom Options	Resizes the matrix by zooming in, zooming out, or enabling full screen.
Legend	Opens the matrix legend, which explains color codes and icons used in the Policy Matrix. Optionally, select TAKE A TOUR for a guided walkthrough of the Policy Matrix. This is also where the Policy View and Multiselect keyboard shortcuts can be viewed.

These tools and the legend improve navigation, visibility, and understanding of policy statuses in the matrix.

Policy Set Selection

Policy Sets are distinct groups of network policies that can be assigned to different Virtual Edges and Virtual Edge Nodes, enabling differentiated policy for different sites or business units. You can easily choose which Policy Set is represented on the Policy Matrix by selecting the appropriate policy set from the menu directly above the Policy Matrix.

 

Active Policy Sets, meaning Policy Sets that have Virtual Edges assigned to them using a Site Label, are indicated by a green dot next to the Policy Set name. Active Policy Sets are always listed at the top. 

See the Policy Sets article for more information on creating Policy Sets and how they can be used.

Troubleshooting the Policy Matrix

Most questions about the Policy Matrix fall into one of three areas: how the matrix and its Policy Groups are displayed, saved filters and custom views, and policies that do not behave as expected after they are created. The table below lists the most common symptoms and the steps to resolve them. Many display-only issues are resolved simply by refreshing the matrix or your browser.

Symptom	What to check and do
The matrix is empty, or Policy Groups you expect are missing	Each Policy Set contains its own subset of Policy Groups, so the matrix only shows the groups assigned to the currently selected Policy Set. Confirm the correct Policy Set is selected in the menu directly above the matrix (active sets show a green dot and are listed first). If a Custom View is active, it may be hiding groups — switch back to the default view. If you have not yet created any Policy Groups, the matrix shows only the default groups; create Policy Groups first.
Cells, colors, counts, or names look stale or render incorrectly	Click the Refresh tool in the toolbar to reload the matrix with the latest policies, traffic, and configuration. If the display is still incorrect, hard-refresh your browser to clear its cache and reload Cloud Control Center. Use the Reveal More Characters tool to expand truncated names, and the Accessible View tool if the color coding is difficult to distinguish.
A policy you created is not taking effect	Hover over the cell (or open table view) and confirm the Policy Status is Active and not Simulated — simulated policies are evaluated but not enforced. Confirm the Policy Set containing the policy is assigned to the relevant Virtual Edges through a Site Label (active Policy Sets show a green dot). Verify the source and destination Policy Groups actually contain the assets you expect by hovering a Policy Group to see its Number of Matched Assets. Remember that Elisity is default-allow: traffic is permitted until a policy explicitly denies it.
A workload-to-workload policy has no matching return-path cell	This is expected. A policy between two Workload Policy Groups does not create a return path policy, because workload enforcement is stateful and already permits reply traffic on an allowed connection. Each direction is an independent policy, so if connections must also be initiated in the reverse direction, create a separate policy on the opposite cell. Cells that involve a device Policy Group are unaffected. See Workload-to-Workload Policies.
A saved filter will not load or returns no results	Saved filters are stored per Policy Set and per view (matrix and table each keep their own). A filter saved in one Policy Set or view does not appear in another, so confirm you are in the same Policy Set and view where the filter was created. If a filter still does not load or its criteria no longer match anything, re-create it, or re-import a previously exported copy. Filters can be exported and shared between Cloud Control Center users.
A "conflict" error appears when saving multiple policies	This means another user modified one of the cells in your selection during your Create Multiple Policies session. Dismiss the message, click Refresh to load the current state, then re-apply and save your selections.
You need to analyze a specific policy or rule	Switch to table view for additional columns and per-policy actions (the three-dot menu lets you view, edit, and toggle Active/Simulation). Click a Policy Group surrounding the matrix to inspect its match criteria, or use a Custom View to isolate a subset of Policy Groups for focused analysis.

When to contact Elisity Support: If the matrix consistently fails to render after refreshing the browser, a saved filter repeatedly fails to load after the steps above, or a policy shows as Active but is not being enforced on assets you expect, contact Elisity Support. Include the Policy Set name, the affected Policy Groups, and a screenshot of the matrix so the issue can be reproduced.