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 over the lookback window.
- 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.
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 30 to 365 days.
Running the Analysis
Open the Policy Matrix (Policies > Matrix) for the policy set you want to evaluate — the MIAMI policy set in the examples below. In the matrix toolbar, click Policy Insights to open the Elisity Assistant.
The Assistant opens beside the matrix and offers to help analyze and optimize your policy coverage. Select the Identify Overly Permissive Policies prompt to start the analysis. You can also type the request in plain English.
When you start the analysis, the Assistant asks which timeframe you want to evaluate. Respond in plain language — for example, 365 days or 6 months. If you do not specify a timeframe, the Assistant uses the default lookback of the last 30 days. You can change the window at any time by asking a follow-up, such as now show the last 90 days; the analysis re-runs and the matrix banner updates to reflect the new window.
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 — for example, the share of Allow policies that are never-matched, how many remain active, any that are dormant, and any that are still running in monitor-only (simulation) mode. 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 and breaks the count down by policy set, listing each policy set with its unused-policy totals calculated with and without the Traffic Exclusion Filter applied.
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 policy set and offers follow-up prompts for reviewing, comparing, and planning cleanup of the flagged policies, along with controls to switch to a table view or end the analysis.
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 blue-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 banner at the top of the matrix reports the scope of the overlay — for example, Showing 28 of 46 cells • unused policies • last 30 days.
Hover over any blue cell to open the Unused Policy details popover. It identifies the source and destination groups, the policy Status (for example, 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 inspect flagged cells — including the total count of unused Allow policies and the per-policy-set breakdown with its risk levels — so you can prioritize which policy sets to work through first.
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. 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 90 days.
- Policy set — a window that applies to a single policy set.
- Security Level — a window that applies to all policy sets at a given Effective Security Level.
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). 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 MIAMI policy set. Valid values range from 30 to 365 days; a value outside that range is rejected with an explanation. 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.
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.