What are Shadowed Rules?
Shadowed Rules are rules that never get applied because an earlier rule in the evaluation order already covers their entire scope. Firewalls and web gateways process rule sets in a fixed order: the first matching rule wins. When a broad rule higher up covers every case a more specific rule further down would handle, that lower rule is effectively dead, even though it looks correct in the rule set. The case of conflicting actions is especially critical: when an allow rule shadows a block rule, an intended safeguard is silently switched off without anyone noticing. Shadowed Rules are therefore a specific case of a policy conflict.
Shadowed Rules in detail
The analysis distinguishes between full and partial shadowing. With full shadowing, the earlier rule covers every case the later one would handle, so the later rule never fires. With partial shadowing, the scopes only overlap in part, so the later rule fires less often, or differently, than intended. A related but less harmful case is redundancy: two rules with the same action overlap, behaviour stays correct, and only the rule set grows unnecessarily large.
Shadowed Rules almost always come from everyday routine: new rules get appended at the end without checking the evaluation order, or a broad allow rule meant as a temporary fix stays sitting near the top of the rule set. In Zscaler operations, this affects every policy that is evaluated in order, for example URL filtering and cloud firewall rules in ZIA, as well as access policies in ZPA. The more administrators work on the rule set in parallel, the more likely rules end up shadowing each other unnoticed.
Why Shadowed Rules matter in Zscaler operations
What makes Shadowed Rules treacherous is that they stay invisible day to day. How two overlapping rules line up side by side is shown in our roughly two-minute video on Policy Conflict Review. The rule set looks complete, the documentation seems to match, but actual behaviour diverges. For the helpdesk, this creates tickets that are hard to explain: a block does not take effect even though the rule exists, or access fails even though it was approved. Without systematic analysis, troubleshooting ends in a manual comparison of rule sets that sometimes run to hundreds of entries.
For security and evidence, the case of conflicting actions weighs heaviest: a shadowed block rule means an agreed safeguard has no effect. Anyone who needs to demonstrate consistent policy enforcement under NIS2 or DORA therefore needs a review that systematically detects shadowing and documents how it was resolved. The fix itself belongs in human hands: decided, approved and logged individually.
Common sources of error
- Appending new rules at the end unchecked: without a look at the evaluation order, shadowing can appear with the very next entry.
- Reviewing rules one at a time: shadowing only shows up when scopes are compared in pairs, not by looking at a single rule alone.
- Deleting shadowed rules on principle: the shadowed rule is often the correct one on merit, in which case the conflict needs resolving, not the rule removing.
- Mass-reordering as a shortcut: changing the order in bulk changes the behaviour of the entire rule set and creates new conflicts.
Shadowed Rules in practice: what CentaurNexus contributes
CentaurNexus's Policy Conflict Review checks the Zscaler rule set as a read-only analysis through the official OneAPI and reports shadowing findings together with both rules involved and where they sit. There is deliberately no button that reorders the rule set automatically: every fix stays a single, human decision, optionally approved under the four-eyes principle and recorded in the append-only audit trail. That makes it possible to prove at any time which findings were detected, decided on and resolved. How to clean up shadowed rules in a controlled way is shown in the article Cleaning up unused Zscaler rules.
Related terms
Frequently asked questions about Shadowed Rules
Mostly through routine: new rules get appended to the end of the rule set without checking whether an earlier, broader rule already covers the same case. Blanket allow rules inserted near the top as a stopgap also shadow later, more specific rules. With every change made by multiple editors, the likelihood of unnoticed overlaps rises.
By comparing every rule against every other rule: does the scope of an earlier rule cover a later one fully or partly? Doing this manually becomes barely feasible once you pass a few dozen rules. What works in practice is a tool-supported, read-only analysis through the Zscaler API that names both rules involved, together with where they sit, and documents the findings.
Potentially, yes. When an allow rule shadows a block rule, an agreed safeguard is effectively switched off without the rule set showing it. The other way round, intended approvals stay ineffective and generate support cases. Even harmless cases suggest a policy state that does not actually exist, which weakens any audit trail.
With redundancy, rules with the same action overlap: behaviour stays correct, and only the rule set becomes unnecessarily large. With shadowing, a rule stops being applied at all; if the two rules specify different actions, actual behaviour then diverges from what is documented. Shadowing is therefore the clearly more critical finding.
That is not advisable. The order is part of the policy logic: automatic reordering changes the behaviour of the entire rule set and risks new conflicts. What works well in practice is read-only detection combined with individual, human-reviewed fixes under four-eyes approval and an audit trail. That way, every change stays traceable and reversible.
- 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.