What are Stale Rules?
Stale Rules are outdated or unused rules in a rule set that no longer serve any clear purpose but are still evaluated. Typical examples are approvals for applications retired long ago, exceptions for employees who have left, or rules meant to be temporary that were never rolled back. Stale Rules build up gradually: projects end, systems get replaced, but the related rules stay in place out of caution. Over time, this grows into a rule set that nobody fully understands any more. That adds complexity to every troubleshooting effort, widens the attack surface through forgotten allow rules, and makes audits more work, because every rule has to be explained.
Stale Rules in detail
In practice, several types can be distinguished. Unused rules stop getting hits over a longer observation period, for example because the target application no longer exists. Orphaned rules point to objects that no longer exist: deleted groups, decommissioned sites, retired servers. Expired exceptions were meant as a stopgap but were never removed. What they all have in common: they barely change how the rule set behaves any more, but they still cost attention at every evaluation, every review and every troubleshooting effort.
In Zscaler operations, this mainly affects URL filtering and cloud firewall rules in ZIA, as well as access policies and app segments in ZPA. Whether a rule is genuinely unused can only be judged with usage data over a sufficiently long period: a rule for quarter-end closing, for instance, only gets hits four times a year. That is exactly why a solid, read-only analysis has to come before any clean-up.
Why Stale Rules matter in Zscaler operations
The larger the rule set, the more expensive every change becomes. To see how unused rules feed into a single health score as one building block among several, watch our video on the configuration score. Anyone adding a new rule needs to understand which existing rules take effect first; every Stale Rule makes that check longer and more error-prone. For the helpdesk, an overgrown rule set means longer ticket times, because every block has more candidate causes. And for security, it matters too: forgotten allow rules from old projects keep access open that nobody is watching any more.
There is also the evidence side. Anyone who has to demonstrate under NIS2 or DORA that access and filtering policies follow the least-privilege principle will struggle to explain rules with no clear purpose. A documented clean-up process with a justification for each rule is therefore also an audit argument. The order matters: first back up the finding with data, then implement every deletion or deactivation as a single, approved change, never as a blanket bulk action.
Common sources of error
- Deleting without evidence: a rule with no hits last month might cover a quarterly or annual process. The observation period has to be long enough.
- Bulk clean-up in one go: removing dozens of rules at once makes errors hard to trace. Better to change and approve them one at a time.
- Deleting directly instead of deactivating first: a deactivation phase with observation is the safer intermediate step.
- Confusing stale with shadowed: a rule with no hits can also be shadowed by an earlier rule. In that case, the cause is different.
Stale Rules in practice: what CentaurNexus contributes
CentaurNexus's Policy Hygiene Desk analyses the Zscaler rule set as a read-only evaluation through the official OneAPI, and makes unused, orphaned and conflicting rules visible, together with their exact location. By design, there is no automation that rewrites the rule set: every finding stays a suggestion, and every clean-up happens as a single, traceable change that can optionally be approved under the Four-Eyes Principle and lands in the append-only audit trail. That turns a diffuse legacy burden into a workable, documented process. For how such a rule review runs step by step, see the guide Finding and cleaning up unused Zscaler rules.
Related terms
Frequently asked questions about Stale Rules
Through usage data: rules that get no hits over a sufficiently long observation period, or that point to objects that no longer exist, are candidates. A practical approach is a tool-supported, read-only analysis through the Zscaler API that documents findings together with their exact location. The period has to cover seasonal processes such as quarter-end closing, otherwise you get false findings.
Yes, forgotten allow rules especially: they keep access open that nobody needs or monitors any more, which widens the attack surface. They also violate the least-privilege principle, which rule sets under NIS2 and DORA have to be measured against. Even seemingly harmless old rules make reviews harder and get in the way of the rules that actually matter.
Not without evidence and process. A three-step approach has proven itself: document the finding with usage data, deactivate the rule first and observe it, only delete it afterwards. Each of these changes should happen individually, approved under the Four-Eyes Principle and recorded in the audit trail. Bulk actions without approval create new faults and are barely traceable.
Stale Rules are obsolete in substance: their purpose has lapsed, so they no longer get hits. Shadowed Rules would still be relevant in substance, but they never get applied because a rule evaluated earlier fully covers their scope. Both stand out through missing hits, but call for different fixes: remove versus resolve the conflict.
As a rule of thumb, a fixed review cycle works well, for example quarterly, supplemented by ad hoc checks after migrations, acquisitions or major restructuring. More important than the exact frequency is commitment: named owners, documented findings and individually approved changes. That keeps the rule set consistently lean, instead of forcing a risky mass clean-up every few years.
- NIST SP 800-41 Rev. 1: Guidelines on Firewalls and Firewall Policy - csrc.nist.gov
- Zscaler Help Portal: official documentation on ZIA policies (URL filtering, cloud firewall) - help.zscaler.com
- BSI IT-Grundschutz, module NET.3.2 Firewall (requirements for rule set maintenance) - bsi.bund.de/.../NET_3_2_Firewall
Note: CentaurNexus is an independent product of SourcingBlox GmbH and not an offering of Zscaler, Inc. Product and brand names belong to their respective owners.