Policy: Controls
When a policy is set to Enforce status, every action that matches the policy's scope must satisfy one or more controls before it is allowed to proceed. Controls define exactly what the user must do — or what Keeper will do automatically — in response to a privileged action.
Controls are configured per-policy and apply consistently across all supported policy types (Privilege Elevation, File Access, Command Line, and Least Privilege). Multiple controls can be combined on a single policy to create layered verification requirements.
Conflict resolution: When multiple policies apply to the same user, machine, or application simultaneously, Keeper enforces all applicable policies and automatically applies the most restrictive outcome where conflicts exist.
Available Controls
The following controls are available when creating or editing a policy in Enforce mode.
Require Approval
What it does: The user's action is paused and routed to a designated approver team. The action is blocked until an approver explicitly grants or denies the request.
How it works:
The user triggers a privileged action (for example, running an application as Administrator).
The Keeper agent intercepts the request and presents the user with a pending notification.
The request is sent to the Keeper backend and appears in the Admin Console → Endpoint Privilege Manager → Requests queue.
The assigned approver reviews the request details — including the requesting user, machine, application, command-line arguments, and any justification provided — and either approves or denies it.
If approved, the user is notified and can proceed with the action.
Key behaviors and timeouts:
Initial approval request expires
30 minutes
Request auto-escalates to secondary approver
After 30 minutes
Escalated request expires
4 hours from escalation
Approved request available for use
24 hours from approval
Timeout windows are configurable in the Admin Console under Admin → Approvals for each event type.
Approver configuration: Approval rules, approver assignments, escalation behavior, and time windows are managed centrally in Admin → Approvals in the Keeper Admin Console — not within individual policies. Keeper Administrators always retain full approval rights. Review activity is tracked under Endpoint Privilege Manager → Requests.
Offline behavior: Approval requests require an active network connection. Users cannot initiate an approval request while offline.
Note: Approvals always require a justification. When Require Approval is selected, the user is always prompted to provide a reason for the request, even if Require Justification is not separately enabled.
Require MFA
What it does: The user must prove their identity using a time-based one-time password (TOTP) before the action is permitted.
How it works:
The user triggers a privileged action.
The Keeper agent prompts the user to enter a valid MFA code from their registered TOTP authenticator app.
The code is validated against the user's Keeper vault MFA configuration.
If the code is valid and within the session window, the action proceeds. If the code is invalid or expired, the action is blocked.
Key behaviors:
Users must have an active Keeper vault account within the tenant and must have configured a TOTP-based two-factor authentication method.
Any valid Keeper email and 2FA combination is accepted as long as the account belongs to the tenant.
MFA sessions are valid for 5 minutes. Within that window, the user will not be re-prompted for the same type of action.
MFA verification requires an active network connection. If the device is offline, MFA-gated actions are blocked.
Require Justification
What it does: The user must type a written explanation of why they need to perform the requested action before it is allowed to proceed.
How it works:
The user triggers a privileged action.
The Keeper agent displays a prompt asking the user to enter a justification message.
The user types their explanation and submits it.
The action is permitted and the justification text is recorded in the audit log.
Key behaviors:
No approver review is required when Require Justification is used alone. The action proceeds immediately after the user submits a justification.
The justification message is captured and associated with the audit event for compliance and review purposes.
Offline behavior: If a policy requires only justification (and not MFA or Approval), execution is permitted offline. The justification message is cached on the device and sent to the server once the agent reconnects.
Advanced Controls
The following controls are available in Advanced Mode via the JSON policy editor. They provide explicit allow and deny outcomes that can be scoped to specific applications, commands, or file paths.
Allow (Advanced)
What it does: Explicitly permits a matched action to proceed without requiring any additional user verification. The action passes through silently.
When to use it: Use Allow when you want to create a permissive exception for a specific application, command, or file path within a broader restrictive policy. For example, you may want to permit a trusted IT tool to elevate without interruption while all other elevation attempts require approval.
Key behaviors:
Allow overrides default-deny behavior for the matched scope.
No notification, MFA prompt, justification dialog, or approval workflow is triggered.
The event is still recorded in the audit log when the policy status is set to Monitor or Monitor & Notify.
Allow and Deny controls can coexist in different policies. When multiple policies apply, Keeper enforces the most restrictive applicable outcome.
Deny (Advanced)
What it does: Explicitly blocks a matched action and prevents it from proceeding under any circumstances, without presenting any verification pathway to the user.
When to use it: Use Deny to implement a hard block on specific applications, commands, or file paths — for example, as part of a default-deny strategy or to block known risky executables. Deny is the appropriate control when there is no valid business reason to permit the action.
Key behaviors:
The action is terminated immediately upon match. No approval, MFA, or justification prompt is shown.
The block is recorded in the audit log.
When building a "Deny Everything" model, Keeper's protected-path logic is applied automatically to prevent unintended disruption of critical operating system components.
Deny policies are evaluated with the highest enforcement priority when multiple policies conflict.
Combining Controls
KEPM supports combining multiple controls on a single policy to enforce layered verification requirements. When controls are combined, all configured controls must be satisfied before the action is permitted.
Approval + MFA
When to use it: Apply this combination when you need both human oversight (an approver must review and grant the request) and identity assurance (the requesting user must prove who they are). This is the strongest available verification gate and is recommended for high-risk actions such as unrestricted elevation across a fleet of endpoints.
User experience:
The user triggers a privileged action and is shown a pending notification.
The request is routed to the approver queue.
After an approver grants the request, the user is prompted to complete MFA.
Once MFA is verified, the action proceeds.
Considerations:
Because approval workflows have their own timeout windows (30 minutes for initial review, 4 hours after escalation), adding MFA extends the total interaction time slightly.
In environments where this combination is applied broadly (e.g. all elevation attempts across all endpoints), expect higher approval queue volume and more frequent MFA challenges for end users. Consider scoping by application, user group, or time window to reduce friction.
JSON representation:
Approval + Justification
When to use it: Apply this combination when you need human oversight but also want to capture the user's stated reason as part of the approval record. Approvers can see the justification text in the request details before deciding to approve or deny, enabling more informed decisions.
User experience:
The user triggers a privileged action.
The user is prompted to enter a justification message before the request is submitted.
The request — including the justification — is routed to the approver queue.
The approver reviews the justification alongside the request details and approves or denies it.
If approved, the action proceeds.
Considerations:
When Require Approval is used alone, justification is already implicitly required. Adding Require Justification explicitly ensures the justification step is consistently presented and recorded in the workflow.
Justification text is visible to approvers in the Requests dashboard detail view and is retained in the audit log.
JSON representation:
MFA + Justification
When to use it: Apply this combination when you want the user to prove their identity and provide a documented reason — but where real-time approver review is not required. This combination is well suited for routine self-service privileged actions that still require accountability and an auditable record.
User experience:
The user triggers a privileged action.
The user is prompted to complete MFA first.
After MFA is verified, the user is prompted to enter a justification message.
The action proceeds immediately after the justification is submitted — no approver review is required.
Considerations:
MFA is always processed before the justification prompt when both are configured together.
This combination requires an active network connection (MFA cannot be completed offline).
The justification message is captured in the audit log and associated with the verified MFA identity, providing a strong chain of accountability without manual approver involvement.
JSON representation:
Control Reference Summary
Require Approval
Yes
No
No (pending until decided)
Yes
Require MFA
Yes
Yes (with TOTP configured)
No (blocked if offline)
No
Require Justification
No (offline cached)
No
No
No
Allow (Advanced)
No
No
No (permits action)
No
Deny (Advanced)
No
No
Yes
No
Offline Behavior Summary
Policies are pushed to endpoints and evaluated locally on the device. The following rules apply when the device is offline:
Approval required: The user cannot initiate an approval request. The action is blocked.
MFA required: The user cannot complete MFA verification. The action is blocked.
Justification only: The action is permitted. The justification is cached and sent to the server when the agent reconnects.
Allow / Deny: Evaluated locally with no network dependency.
Audit events: Cached locally and sent to the server once the agent comes back online.
Last updated
Was this helpful?