Finding and cleaning up unused Zscaler rules (stale rules)

Policy sets grow over years, but they rarely shrink. How to make orphaned, conflicting, and shadowed rules in your Zscaler environment visible and clean them up in a controlled way, without handing over control of the policy set.

Every Zscaler environment tells a story. An exception for a project that has long been completed. An approval for a site that was migrated. A test rule that was never rolled back. Viewed individually, each of these rules makes sense. In sum, over months and years, this produces a policy set that hardly anyone still fully oversees. This is not a weakness of Zscaler, but a property of every living policy set: it grows with every change, but it does not clean itself up.

This is exactly where policy hygiene comes in. Anyone who wants to find and clean up unused Zscaler rules needs two things: reliable visibility into the actual state of the policy set and a process that keeps changes controlled and auditable. Both can be cleanly separated, and it is precisely this separation that makes the cleanup safe.

Why policy sets go wild

Rules are added when there is an acute need: a user needs access, an application should be reachable, an incident demands a quick response. The reverse case almost never occurs. No one gets a ticket titled "Please remove this rule, it is no longer needed." Removing rules feels risky, because it is unclear who or what still depends on them. So they remain. This imbalance between adding and removing is the real engine of the wildgrowth.

In practice, three categories of problematic rules accumulate:

• Orphaned (stale) rules: rules that no longer produce hits over a long period, because the associated application, site, or user group no longer exists.
• Conflicting rules: rules that contradict each other, such as an approval and a block for the same combination of source and destination. Which one wins depends solely on the order, which becomes hard to trace.
• Shadowed rules: rules that are never evaluated because a broader rule higher up already catches the traffic. They suggest a control that in fact never takes effect.

What overgrown policy sets really cost

An overloaded policy set is more than a cosmetic problem. It has concrete effects on security, operations, and compliance.

Attack surface. Every open approval that no longer serves a purpose is a potential path that stays open even though it should be closed. Orphaned exceptions are particularly treacherous, because they were once set deliberately and are therefore easily waved through as "intended" during reviews.

Misconfiguration. Conflicting and shadowed rules cause the actual behavior of the policy set to deviate from the expected. An administrator adds a block that never takes effect because an older approval shadows it. Such silent deviations are the cause of many hard-to-diagnose incidents.

Traceability and audit. In NIS2- or DORA-relevant audits, it must be provable why a rule exists and who is responsible for it. A policy set full of legacy burdens makes this evidence laborious and lengthens every audit.

Operations and overview. The larger the policy set, the harder every change becomes. New colleagues take longer to understand it, and every adjustment carries the risk of unintentionally touching one of the legacy burdens.

Visibility first: Policy Hygiene Desk and Policy Conflict Review

CentaurNexus is a sovereign single pane of glass for Zscaler, with production operation for EU customers entirely on STACKIT in the EU and built on the official Zscaler OneAPI. For policy hygiene, it brings two interacting functions.

The Policy Hygiene Desk analyzes the policy set for orphaned and shadowed rules. It shows which rules no longer take effect over the observed period and which are in fact never evaluated because of broader rules above them. This produces a reliable candidate list for leaner policy sets, without an analyst having to comb through the entire set manually.

The Policy Conflict Review uncovers contradictions: rule pairs that cancel or overlap each other, and points where the order decides the actual behavior. Instead of a long, flat list, the team gets a prioritized view of where the policy set does not do what it appears to prescribe.

Both functions work read-only. They read the configuration, evaluate it, and present findings. They change nothing. This strict separation of analysis and intervention is deliberately chosen and the core of the safe approach.

From finding to traceable implementation

CentaurNexus connects the analyzed policy inventory with usage, conflicts and dependencies. Teams can see the purpose and affected scope of each proposed change.

Each cleanup follows a clearly scoped sequence:

Individual approved changes remain traceable and can be rolled back selectively when needed.

A practical cleanup rhythm

Policy hygiene is not a one-time major project, but a recurring routine. In practice, a simple cadence works well:

• Analyze regularly. Run the Policy Hygiene Desk and Policy Conflict Review at a fixed interval and treat the findings as a candidate list, not a work order.
• Prioritize by impact. Address first the findings that concern the largest attack surface or the clearest contradictions.
• Decide individually. Evaluate each candidate in context. Some seemingly orphaned rule is a deliberate emergency approval and stays.
• Approve and document. Send every change through the approval under the tenant policy and record the reason. The log is at the same time the basis for the next review.

Over several rounds, this produces a leaner, more understandable policy set, without control being surrendered anywhere. How much a policy set can be slimmed down depends entirely on its history. An illustrative example: if the analysis finds a double-digit number of orphaned exceptions in a grown set, those are just as many candidates you can review in a controlled way and remove if appropriate. Concrete percentages always depend on the individual case.

Sovereign, without spreading admin rights widely

Not every analyst needs full access to Zscaler administration to review rules. CentaurNexus reads the configuration through the official OneAPI and presents findings by role. Help desk and operations receive the scope authorized for their task. For EU customers, production operation runs entirely on STACKIT in the EU; further privacy and data paths are documented in the privacy notice.

Interpret usage history correctly

A rule with no observed hits is not automatically unnecessary. The period, feed coverage and domain purpose determine the strength of the finding. NSS firewall data can show rule activity within the available history. Seasonal processes, emergency access or infrequent maintenance windows also require operational knowledge.

CentaurNexus therefore presents the result as a reviewable finding. An administrator assesses dependencies and selects the concrete individual change. After implementation, target-system effect and read-back confirm the new state. Clean-up remains controlled without turning missing activity into an automatic deletion decision.