Policy: Global File Access Policy

This example shows a File Access Policy used as a Global Approval Requirement for running applications. When enabled, it applies to any application a user tries to launch, creating a single, top‑level control point across all endpoints. After this Baseline Global File Access Policy is in place, additional policies can be added to allow specific applications, teams, or scenarios to run without approval.

---

What this Policy Does

When a user on any in-scope endpoint tries to run an application:

1. The request is evaluated by the File Access policy engine.

2. Because the policy is broadly scoped (all users, all applications), it matches most execution attempts on those endpoints.

3. The policy requires Approval within the Admin Console before allowing the action to proceed.

Why it Behaves this Way

This policy is intentionally written as a “broad match” policy, then applies a control:

• Enforced: The policy is active and will apply controls (not just log).

• Approval control on success: When the policy matches, it triggers an approval workflow.

• All users: A wildcard user filter makes it apply to any user account on in-scope machines.

• All applications: A wildcard application filter makes it apply to any application being evaluated by this File Access policy.

• Built-in checks: Standard checks (user, machine, file, date/time/day, certificate) are present. If those constraints aren’t narrowed (for example, no date/time/day/cert restrictions are provided), the policy behaves like a broad catch-all for execution on the targeted endpoints.

What the User Experiences

• Most application launches on the targeted endpoints will generate an approval request.

• The policy includes a user-facing notification message. If the message references a specific date or one-off event, replace it with something generic (or remove it) to avoid confusion in production.

---

Important Notes and Common Adjustments

• High prompt volume: Because this applies to all applications, it can create a lot of approvals—especially when expanded to many endpoints.

• Narrow the scope if needed:

  • Restrict the application filter to a specific set of executables or paths

  • Restrict the user filter to specific users/groups

  • Add certificate/publisher constraints to treat trusted vs. untrusted software differently

  • Add time/day/date restrictions for staged rollouts or business-hours-only enforcement

---

How Build a Global File Access Policy

1

Create Policy

From the Policies tab of the Admin Console's Endpoint Privilege Manager page, click the Create Policy button.

This will open the Create Policy Form in a modal window.

2

Policy Name

Enter a descriptive name for your new Global File Access Policy.

3

Policy Type

Select File Access from the Policy Type select list.

4

Status

Select the status that you would like your new Global File Access Policy to be in upon submition of the completed Create Policy form.

5

Controls

Select Require approval from the Add Control sub-form.

6

User Groups

Click the Add Group link in the Create Policy form. This will open the Add Group sub-form.

Check the Select all users checkbox in the Add Group sub-form then click off of the sub-form to close it. All Users and Groups will now appear under User Groups as applied to your Global File Access Policy.

7

Machine Collections

Click the Add Collection link in the Create Policy form to the right of Machine Collections. This will open the Add Collection sub-form. Select the Machine Collection that you want apply to your Global File Access Policy. You may use the filter as you type box to narrow your search for your Machine Collection.

Check the checkbox(s) of the Collection or Collections that you would like applied to your Global File Access Policy.

The Machine Collections that you selected will now appear under Machine Collections as applied to your Global File Access Policy.

8

Applications

Click the Add Applications link in the Create Policy form. This will open the Add Applications sub-form.

Check the Select all applications checkbox in the Add Applications sub-form then click off of the sub-form to close it. All Applications will now appear under Applications as applied to your Global File Access Policy.

9

Date & Time

For a Global File Access Policy, it is recommended that the Date and Time Ranges be set to Always, as shown below.

10

Save Your New Global File Access Policy

Once the form has been sufficiently filled in per the previous steps, the Save button will be changed from an inactive to an active state. Click on the Save button. The Create Policy modal form will be closed and your Global File Access Policy will be saved.

---

Use-Case Definitions

This pattern — a Global File Access Approval Baseline that catches everything by default — serves a very specific and important strategic purpose in endpoint privilege management. Here's a full breakdown of the use-cases and the reasoning behind it:

The Core Concept: "Default-Deny via Default-Require-Approval"

Rather than trying to enumerate every dangerous application upfront (which is nearly impossible), this approach inverts the model: everything requires approval by default, and you then carve out exceptions for trusted, known-good applications. It's conceptually similar to a default-deny firewall rule at the bottom of a ruleset.

Primary Use-Cases

1. Regulated or High-Security Environments

Organizations subject to compliance frameworks like HIPAA, PCI-DSS, SOC 2, or government/defense mandates often need to demonstrate that no unauthorized software can execute on managed endpoints without a documented approval chain. A global approval policy creates a single, auditable control point for every application launch.

2. Application Allowlisting Rollouts

This policy is the ideal foundation layer when an organization is building out an application allowlist. Rather than blocking everything immediately (which would be disruptive), you:

• Start with a global approval requirement (less disruptive — users can still run things, but must request approval)

• Observe what gets requested

• Add targeted Allow policies above it for IT-approved software (approved apps pass through without triggering the approval gate)

• Over time, transition toward a true deny policy at the baseline once the allowlist matures

This policy structure is intentionally written as a "broad match" policy that applies a control — because the user and application filters both use wildcards, it functions as a broad catch-all for execution on targeted endpoints.

3. Pilot or Phased Deployment

This type of policy is useful for demonstrating how to introduce an approval workflow for application execution across a group of endpoints — for example, a pilot group or a department. Security teams can validate the approval workflow, tune approver capacity, and build the exception list before rolling out to the full fleet.

4. Zero-Trust Endpoint Posture

In a zero-trust model, implicit trust is eliminated — even for standard user applications. A global approval policy enforces that posture at the execution layer. No application is implicitly trusted simply because it's present on the machine.

5. Incident Response / Breach Containment

If an organization has experienced (or suspects) a compromise, this policy can be rapidly deployed to lock down a segment of endpoints — requiring every application launch to be human-approved — while the investigation proceeds, without immediately blocking everything and causing a full outage.

6. High-Risk User Groups or Machines

For specific populations like contractors, third-party vendors, or endpoints in sensitive network segments (e.g., OT adjacent, finance systems), a global approval gate provides maximum oversight without requiring granular per-app policy authoring upfront.

---

Why File Access Policy (Not Privilege Elevation) for the use-cases?

This is a nuanced but important distinction. A File Access policy intercepts the execution of a file (the moment an application is launched), while a Privilege Elevation policy only intercepts attempts to run something with elevated privileges. By using File Access here, the approval requirement applies to any application launch — regardless of whether the user needs admin rights — giving broader coverage.

The Layered Policy Strategy That Follows

Implement sophisticated policy combinations using layered policies — applying multiple policies to the same resources for defense-in-depth. Once the global baseline is in place, the operational model looks like this:

Priority	Policy	Scope
High	Allow — IT-approved apps (browsers, Office, etc.)	Specific apps, all users
High	Allow — Developer tools	Specific users/groups
Low (catch-all)	Require Approval — Everything else	All users, all apps

Applications matched by a higher-priority Allow policy pass silently. Anything not explicitly allowed falls through to the global approval requirement.

---

Key Operational Consideration

Because this policy applies to all applications, it can create a high volume of approval requests — especially when expanded to many endpoints. This is why the documentation recommends starting with a pilot group and building out the exception (Allow) policies before broad deployment. Deploying in batches while monitoring system performance and user feedback, and adjusting policies based on operational requirements, is the recommended approach.