# Privilege Elevation Policy Type
### Overview
The Privilege Elevation policy provides control over the ability of a user to elevate to an administrative role. It is recommended to first apply a [Least Privilege policy](https://docs.keeper.io/en/keeperpam/endpoint-privilege-manager/policies/policy-types/least-privilege-policy-type) to ensure that standard users do not have built-in administrative privilege.
On Windows, the privilege elevation policy will trigger the Keeper Client user interface to open when the user triggers an elevation event. On macOS and Linux (Ubuntu/Gnome), the Keeper Client user interface is available for the user to initiate the request.
#### How it Works
On the endpoint, the Keeper agent service runs with system privilege. All elevations are executed with an ephemeral account called `keeperusersession`.
### Approval Control
Approval-based elevation integrates with a centralized global approval framework. All elevation approval requests are managed through a unified administrative interface, ensuring consistent governance across request types and enforcement models.
### Elevation Controls (ALLOW / DENY / MFA / JUSTIFY / APPROVAL)
Elevation policies may enforce granular command-level restrictions, allowing administrators to approve specific command-line arguments or subcommands while denying others within the same executable. This supports highly precise enforcement of elevated operations. **Controls are additive (stacked)**—when multiple applicable policies apply to the same elevation scenario, **all enforced requirements must be satisfied**. For example, if one policy requires **MFA** and another requires **approval**, the user must complete **both MFA and approval** before elevation is granted.
### Policy Targeting
Elevation policies support advanced targeting across user, machine, application, and collection attributes, enabling refined enforcement strategies that align to operational context.
### Managing Privilege Elevation
From the **Admin Console** > **Endpoint Privilege Manager** > **Policies** create a new policy. Select "**Privilege Elevation**" from the policy type and then "**Enforce**".
Select the **control** (Require approval, Require MFA or Require justification)
After applying the policy, the affected users on the endpoint will need to adhere to the policy in order to elevate their role on the device.
As an example, if the user attempts to run cmd.exe as administrator, Keeper will intercept the request and prompt for approval.
If MFA or justification is required, the user is prompted.
The Admin receives a request to approve the elevation.
After approval, the user is able to run the approved command directly from the Keeper user interface.
### Ephemeral Accounts
**Ephemeral accounts** in KEPM are **temporary, system-managed local accounts** (commonly the **KeeperUserSession** account) that KEPM uses to perform **privilege elevation without permanently granting admin rights** to the end user. When an elevation is approved (and any required controls are satisfied), KEPM ensures the ephemeral account exists, uses it to run the approved process with elevated rights, and then **revokes that privilege automatically** and records the event for auditing. This approach supports “just-in-time” privilege by granting elevation only for the approved operation and only for as long as needed.
In practice, KEPM’s agent/job flow launches the elevated process **as the ephemeral account** (for example on Linux using `sudo -u ` rather than elevating the user directly), and KEPM includes APIs and background cleanup to manage these accounts over time (create/launch, list/delete, cleanup). On Windows, because the OS may generate profile folders when the ephemeral account is created/recreated, KEPM includes scheduled cleanup to remove **orphaned KeeperUserSession profile folders** that can accumulate under `C:\Users` after the account is deleted and recreated.
