How to: Configure Whitelisting and Permissions for CaseGuard Studio

This article walks IT administrators through the settings that commonly need to be allowed on a company network or endpoint before CaseGuard Studio will install and run correctly. Use it as a checklist during deployment, or hand it to a customer’s IT team when they report install failures, crashes, login/email delivery issues, or slow performance that traces back to a security tool intercepting the app.

Overview: What Needs to Be Allowed

CaseGuard Studio touches four layers of a typical corporate security stack. If any one of them blocks it, the symptoms range from “installer won’t run” to “app opens then crashes” to “I never got my temporary password email.”

Layer	What it protects against	Typical symptom if blocking
Application/installer control	Unapproved executables running on the endpoint	Installer is deleted, quarantined, or won’t launch
Email/domain filtering	Phishing and unknown senders	Temp password / account emails never arrive or land in quarantine
VPN / network access control	Unapproved outbound traffic	App can’t reach licensing or cloud services; hangs on load
Endpoint security (AV/EDR)	Malicious process behavior	App is killed mid-run, crashes, or GPU-accelerated features fail silently
Secure web gateway / SSL inspection	Unapproved or unencrypted traffic	API calls time out or fail TLS handshake

1. Allowing the CaseGuard Studio Installer (.exe)

Many companies run some form of application control (Windows AppLocker, Windows Defender Application Control / WDAC, or a third-party allowlisting tool) that blocks unrecognized executables by default, sometimes silently deleting them from Downloads.

What to check

Confirm whether the organization runs AppLocker, WDAC, or a third-party application control product. If IT can’t answer immediately, check Group Policy under Computer Configuration > Windows Settings > Security Settings > Application Control Policies.
Confirm SmartScreen isn’t blocking the download itself (Settings > Privacy & Security > Windows Security > App & browser control > Reputation-based protection).
Get the exact installer filename, version, and ideally its SHA-256 hash so it can be added as a specific rule rather than a broad exception.

How to allow it (AppLocker example)

Open Local Security Policy (secpol.msc) or the relevant GPO on a domain controller.
Navigate to Application Control Policies > AppLocker > Executable Rules.
Create a new rule scoped to the CaseGuard Studio publisher certificate (preferred, survives version updates) or to the specific file hash/path: [C:\Program Files\CaseGuard Studio\CaseGuardStudio.exe]
Set the rule action to Allow and apply it to the security group covering the affected users.
Run gpupdate /force on the endpoint, then retry the install.

2. Allowing the *.caseguard.com Domain (Web + Email)

Users sign in to CaseGuard Studio-related portals such as my.caseguard.com and, for government/law-enforcement customers, gov.caseguard.com. When new accounts are created, a temporary password email goes out from a caseguard.com sending address. On a customer’s first interaction with CaseGuard, their mail filter (Proofpoint, Mimecast, Microsoft Defender for Office 365, Google Workspace, etc.) often has no reputation history for the domain and will quarantine or silently drop that email.

Web/network allowlisting

Allow the wildcard domain *.caseguard.com at the firewall, proxy, or web content filter so all current and future subdomains (my.caseguard.com, gov.caseguard.com, api.caseguard.com, etc.) are reachable without one-off requests.
If the filter doesn’t support wildcards, add each subdomain the customer actually uses individually, and note that new ones may need to be added later.

Email allowlisting (for temp password / account emails)

Add caseguard.com as an allowed sender domain in the mail filter’s allowlist (sometimes called a “safe senders” or “tenant allow/block list”).
In Microsoft 365: Defender portal > Email & collaboration > Policies & rules > Threat policies > Tenant Allow/Block Lists > Domains & addresses > add caseguard.com.
In Google Workspace: Admin console > Apps > Google Workspace > Gmail > Spam, phishing, and malware > Approved senders list.
If SPF/DKIM/DMARC alignment is being checked strictly, confirm with CaseGuard support that the sending domain’s records are set up as expected on your end mismatches here are a common reason a domain-only allow list still doesn’t stop quarantining.

Note: A first-time domain often needs 24–48 hours to build sender reputation even after allowlisting, since some filters combine an allowlist with adaptive reputation scoring. If the temp password email still doesn’t arrive after allowlisting, have IT check the quarantine folder directly rather than assuming it never sent.

3. VPN / Network Access Considerations

If the company enforces a strict VPN with split-tunneling disabled or a default-deny network policy, CaseGuard Studio’s traffic needs an explicit path out.

What to allow

Outbound HTTPS (443) to *.caseguard.com.
If the customer uses a full-tunnel VPN (all traffic routed through corporate infrastructure), confirm the VPN’s own egress firewall also allows the above, allowing it on the local firewall alone won’t help if the VPN concentrator blocks it upstream.

How to check for VPN-side blocking

Have the user try the affected action (login, cloud feature, license check) while temporarily disconnected from VPN, if company policy allows a controlled test. If it works off-VPN, the block is in the VPN’s routing/firewall policy, not the local machine.
Ask IT to check VPN concentrator or NGFW logs (e.g., Palo Alto, Fortinet, Cisco ASA/Firepower) for denied sessions to caseguard.com around the time of the failure.

4. Endpoint Security (Antivirus / EDR) Exclusions

Endpoint security tools flag CaseGuard Studio less because it’s doing anything malicious and more because of what its behavior pattern looks like: it decodes/transcodes video (FFmpeg-based processing), runs local AI/ML inference for detection features, and can be GPU-intensive. Modern EDR tools use behavioral heuristics, not just signatures — a process that suddenly spikes GPU usage, spawns child processes to handle media, or makes frequent disk writes to temp/cache folders can trip the same rules written to catch cryptominers or ransomware staging. That’s a false positive, but it still needs an explicit exclusion to stop recurring.

Common culprits in the field

Product	What usually needs excluding	Where it lives
Sophos Endpoint (Intercept X)	Install directory, executable process, and behavior monitoring for the process	Sophos Central > Endpoint Protection > Policies > Exclusions (add Application Exclusion for both file/folder and process/runtime detection)
CrowdStrike Falcon	The executable path added to the sensor’s exclusion policy; sometimes also needs an IOA (Indicator of Attack) exception rather than just a file exclusion, since Falcon flags on behavior, not just hash	Falcon console > Host setup and management > Sensor visibility exclusions (for file/scan exclusions) and Configuration > IOA exclusions (for behavioral rules)
Windows Defender / Microsoft Defender for Endpoint	Install folder and process, especially if Controlled Folder Access or Attack Surface Reduction rules are on	Windows Security > Virus & threat protection > Manage settings > Add or remove exclusions; or via Intune/GPO for managed fleets
Other EDR (SentinelOne, Carbon Black, etc.)	Same general pattern: folder/process exclusion plus behavioral/IOA exception	Vendor-specific console, usually under Exclusions or Exceptions

General steps to build the exclusion

Identify the exact install path (default is typically (C:\Program Files (x86)\CaseGuard\CaseGuard Studio\CaseGuard Studio.exe) and the running process name (e.g., CaseGuardStudio.exe).
In the security console, add a scan/file exclusion for that folder and executable so it isn’t opened, hashed, or quarantined on access.
Separately, add a behavioral/runtime exclusion (this is the step people miss) so the process is exempt from things like process-injection heuristics, high-resource-usage flags, or child-process monitoring a file exclusion alone often isn’t enough on EDR tools, since those trigger on behavior in memory, not just the file on disk.
Re-launch CaseGuard Studio and confirm in the security console’s event log that no new alerts fire during a normal session (open a case, play back footage, run a detection pass).

Note: Ask the customer’s security team to scope the exclusion as narrowly as possible by exact path and process name rather than a whole drive or user profile, so this doesn’t become a broader gap in their protection than necessary.

5. Zscaler (Secure Web Gateway / SSL Inspection)

Zscaler (ZIA/ZPA) is a common source of blocks because it sits inline and inspects/decrypts HTTPS traffic by default. If CaseGuard Studio’s traffic isn’t explicitly allowed, Zscaler can break the TLS handshake (SSL inspection interfering with certificate pinning) or simply categorize the destination as unknown/uncategorized and block it.

How to check and allow it

In the ZIA Admin Portal, go to Administration > Nanolog / Insights, or Analytics > Web Insights, and search for caseguard.com around the time of the failure to confirm Zscaler is actually the block point (look for a “Blocked” or “SSL Error” action).
Go to Policy > SSL Inspection and add *.caseguard.com to an SSL Inspection exemption list, so Zscaler passes the traffic through without decrypting it, this avoids certificate-pinning failures for apps that don’t tolerate a re-signed certificate.
Go to Policy > URL & Cloud App Control and add *.caseguard.com to an allowed URL category/allowlist so it isn’t caught by a default-deny or “Unknown” category rule.
If the customer uses Zscaler Client Connector (ZPA) for private app access instead of ZIA, confirm CaseGuard’s domains are included in the forwarding profile’s bypass list if they should go direct rather than through the tunnel.

6. Other Places an Exclusion May Be Needed

Depending on the environment, one or more of the following may also require an exception. Use this as a checklist to run through with the customer’s IT team rather than assuming only one layer is responsible.

Windows Firewall (local or GPO-managed): allow outbound rules for the executable and required ports.
Third-party host-based firewalls (e.g., Comodo, ZoneAlarm on older environments): same idea as Windows Firewall.
DNS filtering (Cisco Umbrella, Cloudflare Gateway, etc.): allow *.caseguard.com in the DNS policy so lookups aren’t sinkholed before the connection is even attempted.
Proxy auto-config (PAC) files: confirm caseguard.com isn’t being routed through a proxy that then blocks it separately from the main firewall rule.
Mobile Device Management (Intune, Jamf) app protection policies: if CaseGuard Studio is deployed to managed devices, confirm it’s in the allowed/approved app list, not just installed manually.

If the Issue Persists

If CaseGuard Studio still fails to install or run after working through this checklist, gather the following before contacting CaseGuard support so the ticket can be triaged faster:

Whether the issue reproduces off-VPN or on a different network, to help isolate the layer.
The exact error message or crash behavior, with a screenshot if possible.
Which security product(s) are in place (name and version) and whether an exclusion was already added.
Relevant log entries from the security console showing the block (timestamp, action taken, rule name).

For a more comprehensive list of domains, endpoints, and network requirements that should be allowlisted for CaseGuard services, please refer to the official CaseGuard guide:

How to Whitelist Domains for CaseGuard Online Services

If issues persist after completing these steps, gather the diagnostic information outlined above and contact CaseGuard Support so the team can assist with further troubleshooting.