Skip to content
ZHERO Docs

Unreachable Policy Detection

Policies are evaluated in order, and anything a broader rule catches first never reaches the rules below it. ZHERO computes that evaluation order for you and marks what will never match: whole rules, and individual criteria inside rules that still match on everything else.

It is for anyone who has inherited a policy set nobody fully understands, and for anyone who is about to add a rule to one.

When to use it

  • On a tenant you did not build. The first scan on a policy set with a few years of history routinely surfaces dozens of dead rules and assignments.
  • After an audit finding. “These allow-rules do nothing” is easier to fix when you can see which rule shadows them.
  • Before adding a rule. A new broad rule near the top can silently kill everything specific underneath it. The real-time safety net is the same detection, applied while you are still editing.
  • When the policy set has become too big to reason about. Deleting what cannot match is the cheapest simplification available.

Where to find it in the UI

Unreachable findings arrive through the Analysis Engine, so you meet them in three places:

  • In the Analysis Engine drawer, listed with everything else and filterable by severity.
  • On the policy list, where an unreachable rule renders greyed out.
  • On the entity, in the Analysis tab of the drill-down drawer.

The two families

ZHERO distinguishes a dead rule from a dead criterion, because the fix is different.

FamilyWhat it flagsTypical fix
Potentially Useless (policy type)The whole rule can never match: unreachable for every criterion it configures, or an ANY/ANY rule made redundant by a preceding ANY/ANY ruleDelete the rule, or move it above what shadows it
Unreachable Policy AssignmentsOne criterion inside a rule can never be evaluated, even though the rule itself still worksRemove the dead criterion, or fix the ordering that makes it unreachable

The first family covers ZIA firewall, SSL inspection and URL filtering rules, plus ZPA access and client forwarding policies. The second covers 23 entity types across both planes: on ZIA cloud apps, departments, destination and source IP groups, device groups, device trust levels, locations and location groups, network services and service groups, URL categories, users and user groups; on ZPA application segments and segment groups, client types, machine groups, platforms, posture profiles, risk factor types, trusted networks, users and user groups.

Step by step

  1. Open the Analysis Engine drawer and look for the unreachable families, or open a policy list and look for greyed-out rows.
  2. Read the finding. For a whole rule, it lists every configured criterion and says, per criterion, whether the policy is reachable for it, unreachable for it, or undeterminable because the data is missing. For the redundant ANY/ANY case, it names the preceding rule and its order number.
  3. Decide. Either the rule is genuinely dead, in which case delete it, or it is shadowed by mistake, in which case it needs to move.
  4. If it needs to move, use Policy Reordering from the Entities tab. Select the shadowed rules and bulk-move them above the rule that catches their traffic, then review the diff in Pending Changes before applying.
  5. Re-run the analysis and confirm the findings are gone. Reordering usually clears several at once, because they were all shadowed by the same rule.

What to watch

  • A cluster of unreachable rules under one broad rule is the classic pattern. Fix the broad rule or the ordering, not the twenty rules underneath.
  • “Cannot determine reachability” means the analytics data for that criterion was not available, typically because your admin role cannot read the referenced object. It is not a clean result: treat it as unknown.
  • An unreachable ALLOW rule is a functional bug waiting for a ticket; an unreachable BLOCK rule is usually harmless clutter, but it also means the traffic is being blocked somewhere you have not looked.
  • On ZPA, unused is not the same as unreachable. ZPA defaults to block, so an application segment no policy references is unreachable in a different sense. That case has its own templates (Unused Application Segment and Unused Application Segment Group).

Limits and notes

  • These findings are hygiene, and they score as hygiene. Both families are scored as low-impact in the posture score, and all their variants share a single score cap, so a tenant with hundreds of dead assignments does not see its score collapse over clutter. The exposure is in the rule that shadows them, not in the shadowed rules.
  • No automatic fix is staged. The finding names the change (typically “delete this policy”), but deletion and reordering are decisions you make deliberately. Reordering has its own drag-and-drop workflow.
  • Analysis reflects the configuration, not traffic. A rule can be reachable in theory and dead in practice. Cross-check with the 30 or 180-day traffic window in Traffic Analytics before deleting something that merely looks unused.
  • Order changes as you edit. Reordering rules re-runs the analysis: fixing one shadow can reveal, or create, another.

FAQ

A rule is greyed out but I am sure it works. Who is right? Check the finding’s per-criterion breakdown. If it says “cannot determine reachability” for some criteria, ZHERO is telling you it lacked data, not that the rule is dead. If every criterion is marked unreachable, look at the rule the analysis names as matching first.

Can I delete every unreachable rule in one pass? There is no bulk-delete for findings. Deleting policies is deliberate by design. What you can do in bulk is reorder: select the shadowed rules and move them together above the rule that shadows them.

Does an unreachable rule cost me anything? Some evaluation overhead, and much more in human terms: dead configuration is what makes the next admin distrust the whole policy set.

Why does the same finding appear on many entities? Because the assignment family reports per entity. One badly ordered catch-all can produce a finding on every user group, location and category it shadows. Fix the ordering and they clear together.

Does this work on ZPA? Yes, for access policies and client forwarding policies, and for the ten ZPA criteria entity types. ZPA has no native equivalent.

Next steps

  1. Filter the Analysis Engine drawer to the unreachable families and count what you have
  2. Group the findings by the rule that shadows them
  3. Reorder one cluster, review the diff, apply, and re-run the analysis
  4. Repeat until the policy list has no grey rows left