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.
The analysis does not evaluate policies where the source or destination policy group is named Bypass, Quarantine, or Internet Only. These groups exist to exempt, contain, or restrict devices by design, so their policies are intentional and are never flagged, in either direction. The match is on the exact group name and ignores case: a group whose name only contains one of these words, such as Bypass-Lab, is evaluated normally. This applies to both the on-demand analysis and the recurring Overly Permissive Policy Insight.
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, Activate Simulated 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 states the lookback window the scan used, reports the total number of unused Allow policies the analysis identified in the policy set, and breaks that count down — for example, by whether the Traffic Exclusion Filter is enabled or disabled for each unused policy. Sections that follow suggest next steps and note how each policy is classified, such as never matched, dormant, or too new to evaluate.
Reviewing the Full-Screen Findings
The full-screen view presents the analysis in detail, with charts that summarize the findings — such as the unused Allow policies broken down by whether the Traffic Exclusion Filter is enabled. The charts vary by analysis. They can include an Allow Policy Status Distribution chart that 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, and a Policy Enforcement Status chart that shows how many policies are actively enforced versus running in monitor-only (simulation) mode.
Below the charts, the Assistant confirms how many unused policies are highlighted on the Policy Matrix and offers recommended follow-up actions you can take directly from the findings — such as Review Detailed Policy Overlay, Analyze 7-Day Window, and Compare Policy Sets. 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 same chart and controls appear when the Assistant is docked beside the matrix. The Assistant generates follow-up prompts for each analysis, so their labels vary — for example, Review Unused Policy Details, Analyze 90-Day Window, Compare Policy Sets, and Policy Consolidation Plan.
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 validation checklist, such as the Policy Cleanup Validation Checklist, that lays out each validation step — such as traffic pattern analysis, tighter rule creation, simulation deployment, denied flows review, exception handling, and enforcement transition — with its success criteria, tools or methods, and owner. It pairs the checklist with a chart that groups the work by cleanup phase so you can sequence the work safely.
Additional follow-up prompts — such as Classify MIAMI Policies, Analyze Traffic Patterns, and Create Exception Process — 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 the First Observed and Last Observed timestamps for that policy's traffic, listed both With Exclusion Filter and Without Exclusion Filter. A policy can show Never with the filter applied while still showing dates without it (see Working with the Traffic Exclusion Filter). 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. Under What This Means, the summary explains why the flagged policies are candidates for consolidation or removal. Policy Classifications lists how policies are classified — for example, never matched, dormant, or too new to evaluate — and Next Steps suggests actions, 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.