# Global Allow File Access with Require Approval
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 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 Baseline File Access Policy
{% stepper %}
{% step %}
**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.
{% endstep %}
{% step %}
**Policy Name**
Enter a descriptive name for your new Baseline File Access Policy.
{% endstep %}
{% step %}
**Policy Type**
Select **File Access** from the **Policy Type** select list.
{% endstep %}
{% step %}
**Status**
Select the status that you would like your new **Baseline File Access Policy** to be in upon submission of the completed **Create Policy** form.
{% endstep %}
{% step %}
**Controls**
Select **Require approval** from the **Add Control** sub-form.
{% endstep %}
{% step %}
**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 **Baseline File Access Policy.**
{% endstep %}
{% step %}
**Machine Collections**
Click the **Add Collection** link in the Create Policy form. This will open the **Add Collection** sub-form.
Check the **Select all machines** checkbox in the **Add Collection** sub-form then click off of the sub-form to close it. **All Machines** will now appear under **machine Collections** as applied to your **Baseline File Access Policy.**
{% endstep %}
{% step %}
**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 **Baseline File Access Policy.**
{% endstep %}
{% step %}
**Date & Time**
For a **Baseline File Access Policy,** it is recommended that the **Date and Time Ranges** be set to **Always**, ensuring the block is continuously enforced with no time-based gaps.
{% endstep %}
{% step %}
**Save Your New Baseline 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 **Baseline File Access Policy** will be saved.
Why this Baseline File Access Policy Should be your First Policy
This pattern — a **Baseline File Access** which **Requires Approval** 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 file access with required approval as a baseline 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 within a baseline policy (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 file access with required approval as a baseline 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 policy 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 this baseline file access policy 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 baseline file access policy with required approval.
## 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.
---
# Agent Instructions: Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter:
```
GET https://docs.keeper.io/keeperpam/endpoint-privilege-manager/policies/policy-examples/policy-global-allow-file-access-require-approval.md?ask=
```
The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.