# Reference Targeting

<figure><img src="https://762006384-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MJXOXEifAmpyvNVL1to%2Fuploads%2F8C25fCghRSlXXYUiTbID%2FGetting%20Started%20-%20Reference%20Targeting.png?alt=media&#x26;token=90397bdf-212a-42e0-9e6c-5f320fd9c82b" alt=""><figcaption></figcaption></figure>

This section explains how you **target** policies and configuration at **applications**, **machines**, **operating systems**, and **users**, and how **variables** and **wildcards** make targeting simpler and scalable.

### Targeting Applications, Machines, Operating Systems & Users

Policies and deployment apply to **who** (users), **what** (applications, commands, files), and **where** (machines, operating systems). You control this through **filters** when you create a policy or deployment group.

#### Applications

* **What it is:** The executable or app that the user is running (or trying to run) when the policy is evaluated. For example, `notepad.exe`, `cmd.exe`, or a path like `C:\Program Files\MyApp\app.exe`.
* **How you target:** In the policy’s application filter, you specify which applications the policy applies to. You can use exact names, paths, or patterns with variables and wildcards (see below). This lets you allow or restrict elevation, file access, or command execution per app.

<figure><img src="https://762006384-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MJXOXEifAmpyvNVL1to%2Fuploads%2F0L6YEqLsQ7bEInIDyk9q%2Fimage.png?alt=media&#x26;token=b888a7d7-53b6-4406-8d57-63d87f4ea666" alt=""><figcaption></figcaption></figure>

#### Machines

* **What it is:** The endpoint (computer or device) where the agent runs. Machines can be identified by hostname, deployment group, or other identifiers your console uses.
* **How you target:** In the policy’s machine filter (or in deployment group assignment), you choose which machines the policy applies to. You can use collections or groups so one policy covers many machines without listing each one.

<figure><img src="https://762006384-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MJXOXEifAmpyvNVL1to%2Fuploads%2FYUL2BdhO6wLy7G1ruhm6%2Fimage.png?alt=media&#x26;token=59932000-9495-4b0c-9039-c45e5b206bce" alt=""><figcaption></figcaption></figure>

#### Operating Systems

* **What it is:** The OS of the endpoint—Windows, Linux, or macOS. Keeper EPM supports all three; policies and jobs can be written to work across platforms or to be OS-specific.
* **How you target:** When you define policies or jobs, you can scope them by platform where needed. Path variables (see below) help keep paths correct on each OS.

<figure><img src="https://762006384-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MJXOXEifAmpyvNVL1to%2Fuploads%2FCSdIWvJXctnczUKQQfEP%2Fimage.png?alt=media&#x26;token=3211998a-514c-4d69-b87b-85d6231504c7" alt=""><figcaption></figcaption></figure>

#### Users

* **What it is:** The user account (or group) on the endpoint or in your directory (e.g., AD/Azure AD) that is performing the action.
* **How you target:** In the policy’s user filter, you specify which users (or groups) the policy applies to. Again, collections and wildcards can apply one policy to many users.

<figure><img src="https://762006384-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MJXOXEifAmpyvNVL1to%2Fuploads%2FTvl7xfdL8ujq346xX2ti%2Fimage.png?alt=media&#x26;token=be7a7fd4-ce51-4588-801e-9c57cb9f8ac0" alt=""><figcaption></figcaption></figure>

When **all** of the filters in a policy match (user, machine, application, and any time/date rules), the policy is considered for that request. The product then applies precedence rules (e.g., more specific policies override broader ones) and enforces the matching policy’s controls. For more on policy behavior, see [Policies in Detail](https://docs.keeper.io/en/keeperpam/endpoint-privilege-manager/setup/policies).

## Variable Support

**Variables** are placeholders that resolve to real paths or values on each endpoint. They let you write **one** policy that works on many machines and operating systems without hard-coding paths.

#### Format

Variables use curly braces: `{variableName}`. For example, `{userprofile}` might resolve to `C:\Users\jane` on Windows or `/Users/jane` on macOS.

#### Common Variables (examples)

You can use variables such as these in policy filters and configuration (exact names depend on the product version; these are typical):

* **All platforms:** `{rootdir}`, `{documents}`, `{userdesktop}`, `{home}`, `{tmp}`.
* **Windows:** `{systemroot}`, `{system32}`, `{programfiles}`, `{userprofile}`, `{appdata}`, `{programdata}`, `{temp}`.
* **Linux / macOS:** `{bin}`, `{etc}`, `{usr}`, `{var}`, `{applications}` (macOS), `{library}` (macOS).

So instead of writing `C:\Users\*` or `/Users/*`, you can use `{userprofile}` or `{home}` and the same policy works on Windows and macOS. The product resolves these at evaluation time on each endpoint.

#### Why Use Variables

* **Cross-platform:** One policy works on Windows, Linux, and macOS.
* **Maintainable:** No need to update paths when drive letters or install locations change.
* **Consistent:** Same logical meaning everywhere (e.g., “user’s documents” is always `{documents}`).

Use variables wherever the console or policy editor supports them (e.g., in application paths, file paths, or folder filters).

Form more information on Variable support, visit the [Reference: Variables](https://docs.keeper.io/en/keeperpam/endpoint-privilege-manager/reference/path-variables) page.

## Wildcard Support

**Wildcards** let one rule match **many** names or paths so you don’t have to list every application or file.

#### Typical Behavior

* **`*`** usually means “match any characters” in that part of the name or path. For example, `*.exe` matches any executable ending in `.exe`; `{programfiles}\*\*.exe` might match any `.exe` under any subfolder of Program Files.
* **Path variables** can be combined with wildcards, e.g. `{userprofile}\Documents\*.pdf` to match all PDFs in the user’s Documents folder.
* **Prefix matching** is often used for folders: e.g., a folder filter of `{downloads}` might match all files in the user’s Downloads folder and its subfolders.

Exact wildcard and prefix rules can vary by policy type (e.g., application vs. file access). The dashboard or policy UI will show which patterns are supported where.

#### Why Use Wildcards

* **Scale:** One policy can cover many apps or files (e.g., “all scripts in this folder” or “all executables in Program Files”).
* **Flexibility:** New apps or files that match the pattern are automatically included.
* **Simplicity:** Fewer rules to maintain.

Use wildcards in application filters, file/folder filters, or command-line rules where the product supports them. Together with variables, they keep your policies powerful and easy to manage.

Form more information on Wildcard support, visit the [Reference: Wildcard](https://docs.keeper.io/en/keeperpam/endpoint-privilege-manager/reference/wildcards) page.