Replace "Denylists / Allowlists" with action-neutral terms (Target Items / Exception List) across all protection actions

Products Endpoint Protector Ideas
, , ,
1

Which aspect of EPP are you submitting for?

Endpoint Protector Server

What is a one sentence summary of your feature request?

Replace misleading “Denylists/Allowlists” terminology with action-neutral terms like “Target Items” and “Exception List” that accurately apply across all protection actions (Report Only, Block, Remediate).

Please describe your idea in detail. What is your problem, why do you feel this idea is the best solution, etc.

Problem:
In Content Aware Protection (CAP) policies, using “Denylists” and “Allowlists” creates terminology conflicts depending on the selected Action:

When Action is ‘Report Only’, listed items are inspected and logged, not denied or blocked. Labeling them as a “Denylist” is misleading.

When Action is ‘Remediate’, items trigger corrective measures rather than pure blocking/denial.

Using “Denylist” across non-blocking or multi-action modes causes administrator confusion regarding actual policy behavior.

Proposed Solution:
Adopt a unified, action-neutral terminology that fits every protection mode without needing dynamic changes:

Replace “Denylists” with “Target Items” (or “Policy Targets”): Clearly represents the files, extensions, or patterns that trigger the policy, regardless of whether the action is Report Only, Block, or Remediate.

Replace “Allowlists” with “Exception List” (or “Exclusions”): Clearly represents items exempted from policy evaluation.

This unified wording eliminates ambiguity, provides consistency across all policy modes, and prevents configuration mistakes.

How do you currently solve the challenges you have by not having this feature?

Administrators must manually clarify to new users that items added under a “Denylist” are not actually denied when the policy action is set to Report Only or Remediate. This relies on custom internal documentation to prevent misunderstanding during policy setup.

2

Hi Hyun-Gyu,

Thank you — the semantic inconsistency you’ve identified is a legitimate observation. The terms “Denylist” and “Allowlist” do carry an implicit assumption of blocking behavior.

That said, this is terminology that’s been in place for a long time and is well established across our customer base, so any change would need to be evaluated carefully to avoid introducing confusion for existing users in the process of fixing it for new ones. It’s not a simple rename.

We’ve noted the feedback and will take it into consideration as we think about how policy configuration is communicated in the product. No commitment on changes at this stage, but it’s a useful input.