Policies

Applying least privilege policies to your users and machines

Policy Overview

Endpoint Privilege Manager can apply least privilege policies to applications, users and machines across the fleet of endpoints which are running the Keeper agent. Policies can be applied to any collections in the tenant. The policy is customized by the Admin based on the organization's requirements.

Policies support granular enforcement controls across applications, users, machines, collections, and execution context. Enhanced filtering capabilities allow administrators to target policies by Policy Type, Status, Control, User Groups, Machine Collections, Applications, and Date & Time Ranges, enabling both broad governance models and highly targeted enforcement strategies.

Policies are applied based on:

  • Collection of resources

  • Policy Type

  • Controls

  • Attributes

The Policies screen displays all active enforcements in the tenant.

Policies

Create a Policy

To create a new policy, click on "Create Policy" and complete the policy details form.

Important: Multiple policies can be applied simultaneously to the same device or user. When this happens, Keeper enforces all applicable policies with strict adherence to their requirements. In cases where policies have conflicting settings, Keeper automatically applies the most restrictive option, ensuring maximum security on the endpoint.

Policy Types

Keeper supports the following policy types:

  • Least Privilege: Removes local users from the admin role.

  • Privilege Elevation: Manages requests for an administrative elevation.

  • File Access: Controls access to executables and sensitive files.

  • Command Line: Controls sudo on unix-based systems.

  • Advanced Policy Types (Configured in Advanced Mode)

    • Update Settings: Configures how software updates are approved, scheduled, and enforced across managed endpoints.

    • Update Jobs: Creates and manages update deployment jobs, including targeting, timing, and rollout behavior.

    • Custom: Defines a custom policy with tailored rules and controls to meet specific organizational requirements.

Policy Status

A policy can be applied in one of the following methods:

  • Monitor: Keeper takes no action and the user will not receive any notifications.

  • Monitor & Notify: Keeper takes no action, but user will receive a notification that the event occurred.

    • Require Policy Acknowledgement Checkbox must be checked if Monitor & Notify is selected.

  • Enforce: Keeper takes action on the policy and user will be notified.

  • Off: Policy is disabled

Policy Controls

When a policy is enforced, the user must pass certain controls that are defined. The options are:

  • Requires MFA: The user must use their assigned MFA device to prove their identity. If MFA is required, the user needs to sign up with a Keeper vault and set up a TOTP-based 2FA method. MFA sessions are valid for 5 minutes. Any valid Keeper email/2FA combination will work as long as it's inside the tenant.

  • Requires Approval: The user must wait until an assigned approver handles the request. Approvals always require justification. The first level of approval request times out after 30 minutes. After 30 minutes the request is automatically escalated. The escalated approval must be completed within 4 hours. After the request is approved, the user has 24 hours to use it. Timeouts are configurable in the approval page for each event type.

  • Requires Justification: The user must type an explanation of why they need the request approved. If MFA is required in addition to a justification, the user will be first required to pass MFA followed by the justification request.

Policies support Application AllowList and DenyList enforcement for standard execution in addition to elevation controls. This extends least privilege principles beyond privileged actions to general application governance, enabling organizations to implement default-deny strategies while maintaining centralized control.

Policy Filters

A policy affects only the users and devices which are specified in the policy filter section. This includes the following options:

  • User Groups: Select from the auto-generated or custom user group collections

  • Machines: Select from the auto-generated or custom machine collections

  • Applications: Select from the auto-generated or custom application collections

  • Date and Time Window: Apply the policy only within the specific date range, days of the week and time of day. This allows you to create more restrictive policies outside of work hours, for example.

Deny Everything Policy

The “Deny Everything” model incorporates protected-path logic to prevent unintended system disruption while maintaining strict enforcement. Protected paths ensure critical operating system components remain stable while comprehensive restriction models are applied.

Reference: Protected Paths

Wildcard Policy

When select a policy filter, you can choose "Select All" which is what we call a wildcard policy. A wildcard policy ensures that future objects added to the collection are automatically picked up.

For example, the below policy has a wildcard policy against all user groups, machine collections and applications.

Policy Editor

Policies can be edited in the user interface in a basic or advanced mode. The advanced mode allows editing of the JSON policy definition.

Advanced Policy Editor

The Advanced mode of the policy editor allows the admin to manage the policy directly with JSON syntax.

Approval Settings

KEPM approvals are managed by a global approvals framework: approval configuration is now centralized in the Admin Console under Admin → Approvals, instead of being configured within KEPM directly. This makes approvals global across all request types, lets you designate teams as approvers or escalated approvers, and keeps Keeper Administrators with full approval rights. Approval windows are also configurable (up to 30 days).

In day-to-day use, you’ll still review request activity in Endpoint Privilege Manager → Requests, but the approval rules, approver assignments, escalation behavior, and approval time windows are managed centrally in Admin → Approvals.

This aligns with the general setup guidance that approvers/approval settings are configured in the Keeper Admin Console (location name can vary by console version).

Command-Level Elevation Support

Policies may enforce granular command-level elevation, allowing administrators to restrict or approve specific command-line arguments or subcommands within an executable. This ensures that elevated privileges are granted only for approved actions, reducing the risk of privilege misuse within otherwise permitted applications.

Policy Timing

Policies are pushed and applied across the fleet of endpoints within 30 minutes. The Keeper agent user interface also has a "Refresh Policies" option.

Offline Access

Policies created by the Keeper Admin are pushed to the end-user devices and cached locally. Policies are then evaluated on the device while offline.

  • If justification is required, the user's justification message is cached offline until the agent is online again and sent to the server. If the policy only requires justification, execution is permitted.

  • If MFA is required, the user will be able to execute the action only when online.

  • If approval is required, the user can initiate the approval only when online.

  • Audit messages are cached locally, and will be sent tot he server once the agent comes online.

Automation with Commander

Keeper Commander supports policy automation through our command-line interface, Service Mode REST API and Python SDK. Learn more about Endpoint Privilege Manager commands.

Policy Management

The epm policy command provides management over policy generation.

Linking Approvals to KEPM Policies

Creating an approval team does not automatically trigger approvals. Approval only occurs when:

  • A policy in Endpoint Privileged Manager includes the Require Approval control.

  • The request type matches the configured approval type in the Admin Console.

When both conditions are met, requests are routed to the assigned approval team.

Approval Workflow

When a policy requires approval:

  1. User initiates an action Example: Run as Administrator.

  2. Agent evaluates policy Policy returns a “Pending” decision with Approval required.

  3. Request is created The request is sent to the Keeper backend.

  4. Approval team receives request Approvers can view:

    • Requesting user

    • Machine

    • Application

    • Command line (if applicable)

    • Justification (if required)

  5. Approver acts

    • Approve → Elevation proceeds

    • Deny → Request is blocked

Next Steps

Learn about the policies:

Last updated

Was this helpful?