File Access Policy Evaluation Guide

This guide explains when File Access policies apply, how layered ("defense in depth") policies work together, and which policy wins when more than one matches the same launch.

It complements the File Access Policy page, which covers how to author a File Access policy. Read this page when you need to reason about evaluation behavior — why a launch was (or was not) gated, and how to design a policy stack that holds up beyond a single path list.

For control types, status modes, and the authoring workflow, see File Access Policy. For wildcard behavior in application vs. folder filters, see Wildcards. For path variable resolution, see Path Variables & Protected Paths.

What File Access Policies Control

A File Access policy decides whether a user may launch an application (or open a protected file under File Access workflows) on a managed endpoint.

When a launch is intercepted, the agent evaluates enabled File Access policies against:

• Who is launching — user and group collections

• Which machine the launch is on — machine collections

• What is being launched — application collections (path, filename, file hash, and/or certificate)

• Optional time, day, or date schedules

• The policy's control — Allow, Deny, MFA, Justification, Approval, and combinations

Only policies in Enforce status can block or gate a launch. Monitor policies audit only and do not enforce when an enforced policy has already matched.

When a File Access Policy Applies

A policy applies to a launch only when all of the following are true:

1. Status is Enforce (not Disabled, and not Monitor when the goal is enforcement).

2. The user matches the policy's user or group scope (or the policy is scoped to all users).

3. The machine matches the policy's machine scope (or all machines).

4. The application or file matches the policy's application scope (see How Application Matching Works).

5. Any rules on the policy pass (for example, user check and file check).

6. Optional schedule filters (day, date, or time), if present, include "now."

If any required filter fails, that policy does not apply to this launch. Other policies may still apply.

Matching Is Against the Launch Being Evaluated

For File Access, application matching is compared to the path (and optional hash or certificate) of the process being launched right now — not "any copy of this tool that ever existed on disk."

So:

• A policy that lists {system32}\WindowsPowerShell\v1.0\powershell.exe matches PowerShell at that system path.

• The same bytes copied to C:\Users\alice\pwsh_copy.exe are a different launch path. The path-specific policy above does not match that copy unless you also target it by hash, filename pattern, certificate, or a broader application scope (for example, all applications).

That behavior is expected for path-based collections. It is why durable Living-off-the-Land (LOTL) and blocklist designs use layered policies (see Defense in Depth), not a single path list alone.

How Application Matching Works

Application collections can identify software in several ways. Members of a collection are combined with OR — any one match is enough for that collection.

Path or Filename Patterns

• Full paths after path variables resolve (for example, {system32}\cmd.exe resolves to C:\Windows\System32\cmd.exe).

• Wildcards in paths (for example, {programfiles}\*\*.exe).

• Filename-only patterns (for example, powershell.exe) — these can match that name under any directory.

• The wildcard * (or an empty / all-applications collection) — matches all applications for that filter.

Content Hash (SHA256)

• Hash-only collection members match the file contents, regardless of where the file is launched from.

• Path and hash members require both the path pattern and the hash to match.

Publisher Certificate

Policies can also require a matching code-signing certificate or thumbprint where configured. See Certificate Filter (CertificationCheck).

Practical Guidance

• Block a tool only at its normal install location — use path patterns (the Example 1 style list on the File Access Policy page).

• Block that same binary after it is copied elsewhere — use file hash (Layer C) and/or filename-only patterns, plus a broad Approval or allow-list posture (Layer B).

• Allow only approved software — allow-list known apps and/or trusted publishers by certificate (Layer D); require approval for (or deny) everything else with an all-applications policy.

What Happens When No File Access Policy Matches

If no enforced File Access policy matches the launch:

• The agent does not apply File Access controls for that event.

• The outcome is effectively EnforcementDisabled for File Access — the OS default behavior applies for that launch. Other policy types, such as Privilege Elevation, may still apply if elevation is requested.

File Access is not an implicit "deny everything" product mode by itself. Default gated or default deny is a posture you author with an all-applications Approval (or Deny) policy, then carve out Allows for approved software.

Defense in Depth (Recommended Model)

Treat File Access as a stack of policies, not a single list of paths.

Layer A — Specific Path Approvals (Known Locations)

Require Approval (or MFA / Justification + Approval) for {system32}\cmd.exe, {system32}\WindowsPowerShell\v1.0\powershell.exe, certutil.exe, and other LOTL tools at their documented system paths.

• Gates casual use from the real install location behind an explicit approval workflow.

• Clear for audit ("PowerShell at System32 required approval").

• Prefer Approval here rather than hard Deny when legitimate admin or support use of the real system path must remain possible after review.

• Alone, this layer does not stop a user from running a copy at another path.

Layer B — Broad Posture (All Applications or Allow-List)

Two common patterns:

• Default gated — File Access Approval for all applications (*), then specific Allow policies for business-approved apps that should not require a ticket.

• Default allow with gated exceptions — Allow broadly, Approval (or Deny) only for high-risk apps. Weaker for LOTL containment.

Prefer Approval on the all-applications policy when the goal is to stop unexpected launches without permanently blocking legitimate new software. Use hard Deny on Layer B only when the environment should refuse unknown launches outright with no approval path.

For LOTL mitigation, software blocklists, and incident response containment, Layer B is what catches relocated, renamed, or unexpected launches that miss Layer A's path list.

Layer C — Hash Identity (Known-Bad Binaries)

When you know a specific bad file — a malware sample, an abused tool build, or a binary you must stop everywhere it appears — add its SHA256 hash to a Deny policy.

How matching works depends on how the application collection member is defined:

• Hash-only member — SHA256 with no path. Matches by content hash alone. The file name and folder do not need to match. A renamed or relocated copy of the same bytes is still Denied. Use this when the goal is "block a specific binary everywhere."

• Path + hash member — a concrete path and SHA256 (common when an inventory app supplies both FullPath and FileHash). Requires both the path and the hash to match. The same bytes launched from a different folder will not match this member. That is "block this file at this location," not a global content block.

For incident response containment and precise blocklists where path alone is not enough, prefer hash-only members, or confirm the collection did not also bind the hash to an install path.

Layer D — Certificate Identity (Trusted Publishers)

Publisher certificates are best used on Allow (or reduced-control) policies for software you trust to run.

• Match approved vendors or signed products so legitimate apps can launch without relying only on brittle install paths.

• Prefer certificates for allow-lists of trusted publishers. Do not treat "signed by anyone" as a substitute for a known-bad Deny.

• Combine with Layer B so unknown or unsigned launches still require Approval (or are Denied), while trusted signed software is Allowed.

How the Layers Work Together

Consider a stack that has all four layers authored:

1. A user runs C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe.

   • Layer A path Approval policy matches → Approval required (launch blocked until approved).

2. The user copies that file to %USERPROFILE%\pwsh_copy.exe and runs it.

   • Layer A path Approval policy does not match.

   • Layer B all-applications Approval policy does match → Approval required.

   • If a hash Deny for that binary is also authored, Layer C matches as well.

Evaluating only Layer A in isolation will look like a "bypass." With Layers B and/or C in place, the relocated launch remains controlled.

Multiple File Access Policy Match Precedence

When more than one enforced File Access policy matches the same launch, the agent does not randomly pick one. It applies a fixed order.

1

Keep Policies That Match Filters

Only policies that pass user, machine, application, rules, and schedule filters are candidates.

2

Prefer More Specific Policies Over Wildcards

Among matching policies:

1. User specificity first. Policies that name a specific user or group take precedence over policies scoped to all users (*) for that person.

2. Application specificity next. Policies that target a specific application — concrete paths, filenames, certificates, command restrictions, and similar — take precedence over policies whose application scope is only the wildcard "all applications" (*).

Consequence: A specific-app Allow (or MFA / Approval) can win over an all-applications Deny for that app, because the specific policy is in the more specific bucket. Conversely, if the only matches are all-applications policies, those wildcard policies decide the outcome.

3

Within the Winning Bucket, Apply Control Priority

Among the policies left after specificity, controls are ranked:

1. Deny — highest, hard block.

2. Approval Required — blocked until approval completes; may run with other pending controls depending on composition.

3. Pending Controls — MFA, Justification, Operator Approval, and similar.

4. Allow.

5. Monitor modes do not enforce when an enforced policy has already applied.

If any policy in the winning bucket has Deny, the launch is Denied. Allow cannot override Deny inside the same bucket.

Deny holds the highest control priority and stops evaluation regardless of the specificity of an Allow in the same bucket. Specificity only resolves conflicts across buckets (specific vs. wildcard scope) — not within a bucket that already contains a Deny.

Plain-Language Examples

• Specific Deny for powershell.exe at System32 and an all-applications Allow.

  • System32 PowerShell is evaluated under the specific bucket → Deny.

  • A different app that only matches the all-applications Allow → Allow.

• All-applications Deny and a specific Allow for C:\Program Files\MyApp\app.exe.

  • MyApp matches the specific Allow bucket → Allow (specific beats app-wildcard).

  • An unknown copy under the user's profile matches only the wildcard Deny → Deny.

• All-applications Deny and all-applications Approval (same specificity).

  • Deny wins by control priority.

• Wildcard-user Deny for everyone and a user-specific Allow for Alice on the same app.

  • For Alice, the user-specific policy wins → Allow.

  • For Bob, only the wildcard-user policy applies → Deny.

Outcome Meanings (What the User Sees)

• Allow — Launch proceeds; no File Access challenge.

• Deny — Launch is blocked. The user may see a denial message naming a matching policy.

• Pending — Launch waits until MFA, justification, and/or approval controls complete successfully.

• Approval Required — Treated as blocked until an approver grants access, often shown as a deny-pending-approval workflow.

• No Matching Enforced Policy — File Access does not intervene; OS defaults apply for that event.

Temporary grants issued after a successful approval or justification workflow can allow a later launch without re-prompting for a limited time. A matching Deny policy still takes precedence over grant bypass for that resource. For grant duration configuration, see Configuring the Approval Duration.

Designing for LOTL, Blocklists, and Incident Response Containment

Use these patterns together:

1. Path-specific Approval for known system locations of high-risk tools (see the File Access Policy Example 1 list), so legitimate use of the real path can still be granted after review.

2. All-applications Approval (or Deny, if unknown launches must be refused with no approval path) as the backstop for anything not explicitly allowed. This is what stops path relocation.

3. Specific Allow policies for approved business applications, and optionally trusted publishers via certificate (Layer D).

4. Hash-based Deny for known-bad binaries that must be blocked by content identity everywhere they appear (Layer C).

Containment Checklist

Before relying on File Access for containment, confirm:

• Is there a policy that matches all applications, or an allow-list plus deny-everything-else design?

• Are approved apps covered by specific Allow policies so users can still work?

• For "block this known-bad binary everywhere," is a hash-only Deny in place (Layer C) — not a path+hash inventory member, and not only {system32}\... paths?

• For "allow trusted vendors," are publisher certificates used on Allow policies (Layer D) together with Layer B gating everything else?

• Have you tested both the real install path and a copy under a user-writable folder?

If you only deploy step 1, a copy to another folder will correctly miss that path policy. That is filter matching working as designed — not a failure of Deny enforcement when a broader policy also matches.

Quick Reference

When does a File Access policy apply? When it is in Enforce status and its user, machine, application (path, hash, or certificate), rules, and schedule filters all match the launch.

Does a System32 path Approval (or Deny) stop a copied binary elsewhere? No. Path policies match the launch path. Use all-applications Approval, an allow-list, and/or hash (or filename) identity for relocation coverage.

What wins when policies conflict?

1. Matching filters only.

2. User-specific over all-users; then app-specific over all-applications.

3. Inside that set: Deny > Approval > MFA / Justification / etc. > Allow.

Is File Access default-deny out of the box? No. Author an all-applications Approval (or Deny) if you want unknown launches gated or refused, then Allow what you trust.

Related Admin Console Concepts

• Collections → Applications — Define what "the app" means (paths, hashes, inventory members).

• Policies → File Access — Bind users, machines, applications, and controls.

• Policy Status — Enforce, Monitor, or Disabled.

• Policy Controls — Allow, Deny, MFA, Justification, Approval, and Operator Approval

This guide describes customer-visible File Access evaluation behavior for process launch control. Privilege Elevation, Agentic AI policy types, and OS ACL file-protection workflows follow related but separate rules. A Deny from baseline File Access still blocks agent-driven launches when those policies are in force.