Reported Issues & Root Causes

Customers may report that Risk Control rules does not appear in the Secure Access Overview widget, do not generate Secure Access History logs, trigger email alerts but show no UI entries, or do not enforce actions (e.g., Force Sign Out, Password Reset.)

In most cases the system is working correctly, and the perceived failure is caused by likelihood filtering logic that is not visible to customers.

The following are the root causes of missing logs and dashboard data in ZTSA:

• Aggregation queries for dashboard data fail due to large Internet access log volumes.
• Remediation log formatting errors prevent log entries from being generated.
• Certain events are not reaching the rule engine because of upstream Data Engine layer issues.
• Hardcoded risk score thresholds (≥70) cause some rules (e.g., Impossible Travel) not to trigger when event scores are below threshold.

Standard Behavior (Expected by Design)

• Event-Based Risk Control Rules Do Not Always Trigger

  Risk events (e.g., Impossible Travel, Leaked Account) will not trigger ZTSA rule actions unless the event likelihood is classified as High (≥ 70).

  ZTSA will not enforce any action unless likelihood ≥ 70 even if it meets the following conditions:

  • The event appears in CREM / Risk Reduction
  • The rule is configured correctly; and
  • Email alerts are generated

   

• Likelihood is Not Visible in the UI

  If the TrendAI Vision One interface,

  • Does not display likelihood values.
  • Does not indicate likelihood suppression decisions; or
  • Does not allow customers to adjust likelihood thresholds.

  This may lead to misinterpretation of correct filtering as a malfunction.

   

  Customer Complaint Validation and Escalation

  1. Confirm the Rule Type
     • If the rule is score-based (risk ≥ X) → Action should occur if the asset has activity and the Secure Access module is installed.
     • If the rule is event-based (e.g., Impossible Travel) → Action depends on likelihood.

     Only score-based rules are guaranteed.

  2. Confirm Action Criteria

     Ensure the device/user has:

     • Secure Access Module installed (if device rules)
     • Recent internet activity (actionable violation must exist)
     • Logs under User Activity Logs or Remediation Logs
  3. Check If the Event Was Suppressed

     If the event exists, but:

     • No remediation entry
     • No history entry
     • Only email notification exists

     → This indicates a low likelihood suppression and is NOT a bug.

  4. Escalate Only When Score-Rule Fails

     A case should be escalated when the score-based rules fail these provisions:

     • Device/User meets score threshold
     • Asset has activity
     • Secure Access Module is present
     • No remediation logs appear
     • No suppression scenario applies
     • Violation does not appear in history

     Do not escalate event-based rules unless likelihood visibility becomes a PM/UI request.

   

  Understanding Misunderstood Behavior

  • Hidden Logic: ZTSA only acts on event-based detections when:
    • Likelihood ≥ 70
    • Regardless of whether Risk Level appears high in the UI
    • Regardless of whether CREM shows a red/high severity event
    • Regardless of whether the customer expects immediate action
  • Why It Exists: ZTSA is originally designed to prevent false positives, avoid unnecessary account lockdowns, and reduce SOC alert fatigue.
  • Why It Creates Issues:
    • No likelihood visibility
    • No ability for customers to override
    • UI labels imply immediate action (e.g., “Force Sign Out”)
    • Widgets do not reflect suppressed events
   

  Future Road Map

  These items are required to eliminate confusion and repeat escalations:

  • Show likelihood score in UI
  • Show suppressed events and why they were suppressed
  • Allow customers to modify likelihood thresholds
  • Add ability to enforce “Always execute action” mode
  • Update rule descriptions to reflect dependencies

  The ZTSA risk control system is operational and stable. The remaining challenges are visibility and customer control, rather than technical failures.