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 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 is the last 30 days; you can extend it up to 180 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, 180 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.
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.
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.
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.
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.
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 180 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.