Overview
Over time, a policy set accumulates Allow policies that grant access no device ever uses. These overly permissive policies are Allow — or simulated Allow — rules that carry no observed traffic over time: open vectors of communication that do not need to be open. They widen the attack surface without serving any live traffic. The Identify Overly Permissive Policies capability in the Elisity Assistant analyzes a policy set against observed traffic, flags the Allow policies that have gone unused over a configurable lookback window, and turns the result into actionable next steps so you can refine, consolidate, or remove them with confidence.
The same detection also runs continuously in the background and surfaces as a recurring Overly Permissive Policy Insight — one per policy set — in the Insights module, so unused Allow policies come to your attention even when the Assistant is closed. See Policy and Device Insights for how to work with these Insights.
The analysis runs directly against the Policy Matrix. It evaluates Allow All and custom Allow policies at the policy level and classifies each one as:
- Never-Matched (Overly Permissive) — the policy grants access but has never carried traffic since it was created.
- Active (Traffic Observed) — the policy is in use and currently carrying traffic.
- Dormant (Previously Used) — the policy carried traffic in the past but not within the current window.
The analysis flags both Never-Matched and Dormant policies as unused; Active policies are not flagged. A policy that has carried no traffic but was created more recently than the lookback window is not flagged, because it is too new to evaluate. Traffic observed before a policy was created does not count toward that policy.
Prerequisites
- Access to Elisity Cloud Control Center (CCC) with permission to view the Policy Matrix and Insights.
- The Elisity Assistant enabled for your tenant (enabled by default).
- A policy set with enough traffic history to evaluate. The default lookback window for an on-demand analysis is the last 30 days, and the analysis window is configurable from 1 to 365 days, unless your deployment uses a narrower range.
Running the Analysis
Open the Policy Matrix (Policy > Matrix) for the policy set you want to evaluate — the MIAMI policy set in the examples below. In the Policy Matrix header, click Policy Insights to open the Elisity Assistant.
The Assistant opens beside the matrix and offers to help analyze and optimize your policy coverage with three suggested prompts: Establish Policy Coverage, Identify Activation Suggestion Policies, and Identify Overly Permissive Policies. Select Identify Overly Permissive Policies to start the analysis. You can also type the request in plain English.
From the Policy Matrix, the analysis runs immediately against the selected policy set using the default lookback of the last 30 days. To evaluate a different timeframe, include it in your request or ask a follow-up in plain language — for example, now show the last 90 days or use the last 365 days. The analysis re-runs and the matrix banner updates to reflect the new window.
A longer period is useful for policy sets whose workloads communicate on weekly, monthly, or seasonal cycles, where a short lookback can leave a policy that carries real traffic looking unused.
This timeframe applies to the current analysis view only and does not change the persistent window that drives the recurring evaluation — see Configuring the Analysis Window to set that. As the analysis runs, the Policy Matrix switches to Policy Insights mode and highlights the affected cells while the Assistant reports the results.
You can also open this same workflow from the Insights module: on an Overly Permissive Policy Insight, click Review or the Insight name to open the Policy Matrix with the policy set already selected and the configured analysis window pre-loaded. See Policy and Device Insights for how these Insights are surfaced and managed.
Reviewing the Initial Findings
When the analysis completes, the Assistant returns an Overly Permissive Policies Identified summary with the key findings for the policy set. The flagged policies are highlighted directly on the Policy Matrix at the same time.
After getting your initial policy insight analysis in the Elisity Assistant, you can expand it and view it full screen to review the initial findings. Click the expand icon in the upper-right corner of the Assistant panel.
The summary reports the total number of unused Allow policies the analysis identified in the policy set and breaks that count down by enforcement — for example, how many of the unused policies have traffic enforcement enabled and how many have it disabled. An Analysis Details section follows, stating the lookback window the scan used and how each policy is classified, such as never matched or dormant.
Reviewing the Full-Screen Findings
The full-screen view presents the analysis in detail. The Allow Policy Status Distribution chart breaks the policy set into Never-Matched (Overly Permissive), Active (Traffic Observed), and Dormant (Previously Used) counts, so you can see at a glance how much of the policy set is over-provisioned. The Policy Enforcement Status chart shows how many policies are actively enforced versus running in monitor-only (simulation) mode.
A highlighted box at the bottom of the view presents recommended follow-up actions you can take directly from the findings — such as Review Never-Matched Policies, Analyze Verified PCs Group, Compare To Actual Traffic, and Plan Policy Cleanup. You can also click Switch To Table View to list the flagged policies, or End Analysis to return the matrix to its normal view.
The Assistant also charts the unused Allow policies by enforcement status and confirms how many unused policies are highlighted on the Policy Matrix. Below the chart, it offers follow-up prompts for reviewing and acting on the flagged policies — such as Review Unused Policy Details, Analyze 90-Day Window, Compare Policy Sets, and Policy Consolidation Plan — along with the End Analysis and Switch To Table View controls.
Planning Policy Cleanup
The recommended actions are interactive — they do more than restate the findings. Selecting one, such as Plan Policy Cleanup, returns a strategic, ready-to-execute plan for acting on the flagged policies. The Assistant produces a Policy Removal and Consolidation Validation Checklist that lays out each validation step — such as historical traffic analysis, policy group verification, stakeholder review, simulation-mode testing, staged deactivation, and post-removal monitoring — with its timeline, success criteria, and risk level. It pairs the checklist with a Policy Lifecycle: Removal and Consolidation Timeline so you can sequence the work safely.
Additional follow-up prompts — such as Identify Simulation-Only Policies, Analyze Consolidation Candidates, Review Compliance Dependencies, and Plan Staged Rollout — let you refine the plan further before you make any changes.
Inspecting Flagged Policies on the Matrix
The whole point of the analysis is that the findings are actionable — you can work directly with the policies it identifies. On the Policy Matrix, every highlighted cell is an overly permissive policy: an Allow or simulated Allow policy that carries no traffic across the lookback window — an open vector of communication that does not need to be open. The Policy Insights Analysis banner at the top of the matrix reports the scope of the overlay — for example, Showing 15 of 22 cells - unused policies - last 30 days. The Policy Insights button is hidden while the overlay is active.
Hover over any highlighted cell to open the Unused Policy details popover. It identifies the source and destination groups, the policy's enforcement Status (Active when enforced, or Simulation), the assigned Security profile (such as Allow All), and when traffic for that policy was first and last observed. From here the insights become operational: select an individual policy — or use multi-select and select all to work in bulk — and act on what the analysis found by creating or modifying policies, moving them to simulation, or removing them.
Alongside the matrix, the Elisity Assistant keeps the analysis summary in view as you work through the flagged cells. The summary explains why the flagged policies are candidates for consolidation or removal, lists how policies are classified — for example, never matched, dormant, or too new to evaluate — and suggests next steps, such as assessing whether each unused policy is still needed or re-running the analysis with a longer lookback window.
To remediate a flagged policy, click its cell to open the policy for editing. A common change is to convert an unused Allow All policy to Deny. When you save and return to the matrix, the analysis overlay is preserved and the policy you just changed is no longer highlighted — so you can track your progress as you work through the flagged cells. Editing a policy updates both its forward and reverse path unless the policy is unlinked.
Working with the Traffic Exclusion Filter
The Unused Policy popover reports observed-traffic timestamps two ways: With Exclusion Filter and Without Exclusion Filter. The Traffic Exclusion Filter (TEF) removes traffic that Elisity classifies as background noise — such as discovery scans — so that filtered activity does not count toward a policy being considered "used."
TEF is enabled by default. Because the filter changes what counts as a match, the First Observed and Last Observed timestamps can differ between the two views: a policy may show Never for both values With Exclusion Filter while still showing dates Without Exclusion Filter, indicating that the only traffic it ever carried was filtered noise. Comparing the two views helps you confirm whether a flagged policy is genuinely unused before you act on it.
Configuring the Analysis Window
The analysis window is the lookback period the recurring evaluation uses to decide whether an Allow policy is overly permissive. It is persistent and drives the daily evaluation, which makes it distinct from the ad-hoc timeframe you type during an on-demand analysis — that timeframe affects only the current matrix view. This window applies only to the Overly Permissive Policy evaluation and is set independently of other policy insights. Set, read, and clear the window through the Elisity Assistant in plain language.
The window can be configured at three scopes:
- Global default — the tenant-wide window applied when no more specific value is set. The global default is 30 days.
- Policy set — a window that applies to a single policy set.
- Security Level — a window that applies to policies whose source or destination policy group is at a given Effective Security Level (Level 1 Low Impact, Level 2 Medium Impact, Level 3 High Impact, or Level 4 Critical).
When the evaluation runs, the most specific scope wins: Security Level takes precedence over policy set, which takes precedence over the global default (first match wins). When a policy's source and destination groups resolve to different windows, the longer window applies. Individual policy groups are not a configurable scope. To change the window a policy group is evaluated against, change its Effective Security Level or apply a Policy Group Template.
To set a window, ask the Assistant in plain language — for example, Set the Overly Permissive Policy window to 120 days for the Default policy set. Valid values range from 1 to 365 days unless your deployment uses a narrower range, and the global default is 30 days. A value outside the allowed range is rejected, and the Assistant states the allowed range. The Assistant confirms every change before applying it, showing the requested action, the current value it will replace, and the scope it affects, with Accept and Reject controls.
To read the current configuration, ask the Assistant to show the analysis window; it returns the values set at all three scopes. To remove an override, ask it to clear the window for that scope — the scope then falls back to the next-most-specific value that applies. Changes take effect on the next daily evaluation (around 00:00 UTC).
Best Practices
- Confirm before you remove. Treat a never-matched flag as a candidate for review, not an automatic deletion. Compare the With and Without Exclusion Filter timestamps to confirm a policy is genuinely unused rather than carrying only filtered background traffic.
- Match the lookback to your traffic cadence. Some workloads communicate on weekly, monthly, or seasonal cycles. Extend the lookback window up to 365 days for policy sets that serve periodic traffic before deactivating anything.
- Stage changes through simulation. Move candidate policies to monitor-only (simulation) mode and watch for denied flows before enforcing removal, so you can catch any legitimate traffic the analysis did not capture.
- Use the recommended actions to plan. Actions such as Plan Policy Cleanup and Analyze Consolidation Candidates produce validation checklists and timelines you can use to coordinate removal with your change-management and security teams.
- Re-run periodically. Policy coverage drifts as your environment changes. Running the analysis on a regular cadence keeps Allow policies aligned with how devices actually communicate.