FAQs

Frequently Asked Questions regarding Keeper Endpoint Privilege Manager

What features are coming to Endpoint Privilege Manager?

We have a full roadmap of capabilities planned. By the end of 2026, we will be incorporating several key capabilities including:

• Realtime / instant updates

• Mobile push approvals

• Enhanced user experiences for admins and end-users

• Additional MFA control options (such as FIDO2 keys)

How does Endpoint Privilege Manager work?

On Windows, Keeper Endpoint Privilege Manager is installed as an agent under system privilege, running as a service. The agent performs application hooking to intercept every process creation in Windows under the user session. We do not hook system processes or other security products.

When an application executable is launched, Keeper evaluates each subprocess request individually against policy before execution. This allows us to either require MFA, require justification, deny or request approval prior to elevation of a subprocess. When the process is executed, it is performed under an ephemeral account that is destroyed post-execution.

On macOS, Keeper is an approved Apple system extension. On Linux, we use a "pluggable authentication module" which handles process elevation.

System extensions on macOS provide a way for developers to extend the functionality of the operating system, running in user space rather than the kernel, which improves security and stability.

How does the Keeper Agent communicate to the backend service?

By default, the Keeper agent communicates to the Keeper backend infrastructure using a zero-knowledge encrypted messaging protocol. If the customer leverages a SPIFFE server in their environment, Keeper supports a SPIFFE plugin that can be registered to talk to the customer's SPIFFE agent with signed payloads.

Does Keeper have endpoint access?

No, Keeper is a zero-knowledge platform. All information collected by the Keeper agent is encrypted on the user's device and can only be decrypted by the Keeper administrator in the Admin Console.

Do Keeper's servers know what programs my employees are running?

No, Keeper is a zero-knowledge platform. All information collected by the Keeper agent is encrypted on the user's device and can only be decrypted by the Keeper administrator in the Admin Console.

How does Keeper provide Just-in-Time access when approval is required?

When approval is required, the request is sent to the Keeper admin and handled through the Admin Console or Commander CLI.

How does Keeper provide Just-in-Time access when there is no approval required?

If the policy applied to the device does not require an approval for the specific event, the Keeper agent will allow the elevation without any additional approval steps. If MFA is required, the user will be asked to present their multi-factor token to proceed.

How does Keeper allow users to elevate when they are offline and do not have an internet connection?

Keeper's agent caches the encrypted policy information offline. When the user is offline, the policies will still be enforced on the user. After the user is back online, the event logs are relayed back to the Keeper cloud.

Using KeeperPAM, Endpoint Privilege Manager and Microsoft LAPS Together

KeeperPAM and Endpoint Privilege Manager can work seamlessly alongside Microsoft LAPS in organizations that have already invested in LAPS deployment. In this complementary arrangement, LAPS can continue managing the rotation of local administrator passwords on domain-joined computers, while KeeperPAM handles credential management for domain accounts, service accounts, and other privileged credentials that fall outside LAPS's scope. This integration preserves your existing LAPS investment while extending privileged access protection across more systems and account types.

Endpoint Privilege Manager enhances this security ecosystem by implementing least-privilege enforcement on endpoints. While LAPS focuses on securing the credentials of standing admin accounts, Privilege Manager reduces the need to use those accounts in the first place by enabling temporary privilege elevation for specific tasks. Together, these solutions provide comprehensive coverage: LAPS secures local admin passwords, KeeperPAM manages and controls access to those credentials and other privileged accounts, and Privilege Manager ensures users only receive elevated privileges when necessary and authorized.

How can Keeper replace LAPS?

Keeper offers a more comprehensive approach to privileged access management than Microsoft LAPS. While LAPS only manages local administrator passwords on domain-joined computers, Keeper provides a complete solution through two complementary components:

1. KeeperPAM handles credential management and rotation for both domain and local accounts

2. Endpoint Privilege Manager implements least-privilege policies and just-in-time elevation

Organizations can either replace LAPS entirely with Keeper's solution or use them together during transition periods.

How does KeeperPAM manage credentials on the end-user machines?

KeeperPAM, through the Keeper Gateway, can rotate credentials for:

• Any domain user account within Active Directory

• Local administrator accounts on individual machines (requires access via WinRM for Windows or SSH for Linux/macOS)

This means KeeperPAM can manage both centralized domain credentials and decentralized local admin credentials across your environment.

What approach does Endpoint Privilege Manager take for securing admin access?

Endpoint Privilege Manager focuses on privilege elevation rather than credential management:

• Removes users from the local admin groups

• Requires users to request elevation when admin privileges are needed

• Can configure policies requiring that a default admin account must approve or perform elevation requests

• Provides just-in-time access without exposing admin credentials

What are the options for using Keeper solutions with or without Microsoft LAPS?

Option 1: Replace LAPS with KeeperPAM

• KeeperPAM manages and rotates both domain and local admin passwords

• Provides more comprehensive credential management than LAPS

• Enhances security through vaulting, MFA, and detailed access controls

Option 2: Complement LAPS with Keeper Solutions

• LAPS continues to manage local admin passwords

• KeeperPAM manages domain admin and service account credentials

• Endpoint Privilege Manager implements least-privilege policies and just-in-time elevation

Option 3: Full Keeper Solution (Most Secure)

• KeeperPAM manages all admin credentials (domain and local)

• Endpoint Privilege Manager implements least-privilege policies

• Users never need direct access to admin credentials

• Admin credentials are only used in emergency scenarios

Which approach is recommended for maximum security?

The full Keeper solution (Option 3) provides the most comprehensive approach by addressing both credential management through KeeperPAM and privilege management through Endpoint Privilege Manager. This effectively renders traditional LAPS unnecessary while providing superior security controls and detailed audit trails.

Does Keeper prevent shell escapes and the ability to spawn subprocesses?

Yes, when an application launches, Keeper evaluates each subprocess request against policy before execution. This allows us to block unauthorized shell escapes and prevent elevation through spawned subprocesses, enforcing strict control over privilege escalation paths.

Does Keeper centrally manage sudo policies?

Yes, Keeper's "Command Line" policy includes the ability to protect "sudo" usage. The admin can specify if justification is required, MFA required or approval required for executing the sudo command. This policy can then be applied to collections of users, groups and machines.

Why was my elevation request denied?

Often because no policy explicitly allowed it and the agent is configured to deny by default for certain cases (e.g., when the user is a local administrator and “enforce policies for administrators” is on). To allow a specific action, add a Privilege Elevation policy that matches that app, command, or scenario and set the control to Allow (or MFA/Justification/Approval as you prefer). Check the policy’s filters (user, machine, application) so they actually match the request.

What if I need to allow “Sync now” (time sync) or Local Users and Groups?

These are elevation actions. Create a Privilege Elevation policy that allows the specific executable or command (e.g., the time-sync or MMC snap-in). Some deployments use an AllowCommands (or similar) list for known-safe commands; if yours does, add the relevant command there. The same idea applies to any other admin tool you want to allow.

What’s the difference between Monitor and Enforce?

Monitor means the policy is evaluated and logged, but no control is applied—the action is allowed. Enforce means the policy’s controls (Allow, Deny, MFA, Approval, etc.) are applied. Use Monitor to test; use Enforce when you’re ready to block or require steps.

Do policies apply to administrators?

You can configure whether local administrators are subject to privilege-elevation policy when no policy matches. If “enforce policies for administrators” is off (default), admins can elevate without a matching policy. If it’s on, they are denied when no policy allows the request. This is a plugin setting (KeeperPolicy) that you can change from the dashboard or configuration policy.

Can I use my own approval system (e.g., ServiceNow, Jira)?

Keeper supports custom approval flows. You can integrate with external ticketing or approval systems so that requests are created there and the result is fed back to the agent. The exact setup depends on your Keeper deployment and the integration options available; check with your account team or the integration documentation for your console.

What ports does the agent use?

By default, the agent uses HTTP 6888, HTTPS 6889, and MQTT 8675 on the local machine. These are configurable. The agent binds to localhost so it is not exposed to the network unless you change that.

How do I troubleshoot “policy didn’t match” or unexpected denials?

Check: (1) Policy status is Enforce (not Off). (2) Filters (user, machine, application) actually match the request—use variables and wildcards if needed. (3) No other policy with higher precedence is denying. (4) Logs and audit events for that request to see which policies were evaluated and why they did or didn’t match.