Frequently Asked Questions regarding Keeper Privilege Manager
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.
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.
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.
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.
When approval is required, the request is sent to the Keeper admin and handled through the Admin Console or Commander CLI.
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.
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.
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.
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:
KeeperPAM handles credential management and rotation for both domain and local accounts
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.
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.
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
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
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
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
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.
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.
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.