Security

Audience: Customers of Keeper Endpoint Privileged Manager. This page summarizes what makes Keeper Privilege Manager secure—so you can understand how the product protects your endpoints, data, and users without needing to read developer or internal documentation.

---

Overview

Keeper Privilege Manager is built to reduce risk while enabling the right actions. Security is designed into how the agent runs, how it communicates, how policies are enforced, and how actions are audited. Below we outline the main ways the product keeps your environment secure.

Zero-Standing Privilege and Least Privilege

• Users don’t need to be local administrators. The product is designed so you can move toward zero-standing privilege: users get standard accounts by default. When they need elevation or sensitive file access, they request it; your policies decide whether to allow it, require MFA, require approval or justification, or deny it.

• Elevation and access are time-limited and scoped. When policy allows an action, the product can grant temporary elevation or file access (e.g., for a specific app or path and a set duration). When the time or scope is done, the privilege is gone—no permanent “always admin” for daily use.

• Least-privilege enforcement can remove standing admin rights where appropriate while keeping controlled exceptions. You define who can do what, and the agent enforces it consistently.

Why it matters: Fewer standing admin accounts means a smaller attack surface. Compromised user accounts have less built-in privilege; sensitive actions are gated by policy and, when you choose, by MFA or approval.

Policy-Driven Control

• You decide what is allowed and how. Policies in the Keeper dashboard define exactly which applications, users, machines, and paths can be allowed, denied, or required to complete MFA, justification, or approval. There is no “allow everything” by default—the agent enforces what you configure.

• Granular targeting lets you scope policies by application, command line, folder, user, and machine (including variables and wildcards). So you can allow one tool and deny another, or require approval only for high-risk actions.

• Redirects let you say “yes” in a controlled way—for example, sending “Network settings” to a substitute, policy-approved experience instead of the full OS dialog—so users get the function they need without unnecessary privilege.

• MFA, approval, and justification add extra checks before sensitive actions proceed. All of this is configurable per policy so you can match control to risk.

Why it matters: Every sensitive action is gated by your rules. Unauthorized or unexpected apps and commands don’t get a free pass; they are evaluated against the same policy set.

Local-Only Exposure: The Agent Does Not Listen on the Network

• The management API and message bus are bound to localhost only (e.g., 127.0.0.1). The agent’s HTTP/HTTPS API and MQTT broker are not exposed on the network—they are only reachable from the same machine.

• No open network ports for the agent’s control plane. External attackers cannot directly call the agent’s API or message bus from across the network. Management and automation (scripts, monitoring) that need to talk to the agent typically run on the same endpoint or use supported, secure mechanisms (e.g., secure backend sync).

Why it matters: The agent’s “brain” (policy engine, job runner, plugins) is not a network service. That significantly reduces the remote attack surface.

Only Trusted Components Can Talk to the Service

• Only processes started by Keeper Privilege Manager (and that present a valid identity) are allowed to connect to the agent’s message bus and to use the local API for sensitive operations. Arbitrary applications or scripts cannot connect unless they meet the product’s requirements (e.g., launched by the service or by an authorized admin context).

• Multi-level authorization separates what different callers can do: for example, health checks may be unauthenticated for monitoring, while changing settings or running jobs requires an authorized (e.g., admin or plugin) context. This limits the impact of a compromised or misused client.

Why it matters: Malware or a normal user app cannot simply “call in” to the agent to change policy or trigger privileged actions. Only the product’s own components and properly authorized callers can do that.

Encryption and Protected Data

• HTTPS is used for the local management API (with a certificate, often self-signed for localhost). TLS is used for the local MQTT message bus. So traffic between the agent’s components on the machine is encrypted.

• Sensitive data at rest (e.g., in the agent’s storage for policies, settings, and audit-related data) is encrypted. The product is designed so that secrets and sensitive configuration are not stored in plain text in accessible files.

• Certificates and validation are used so that the agent can verify the identity of the components it launches and talks to. Plugins and signed components are validated before they run.

Why it matters: Communication between the agent’s parts is protected from eavesdropping on the host, and sensitive stored data is protected from casual read access.

Full Audit and Visibility

• Privilege elevation, file access, policy evaluations, approvals, and denials can be audited. The product records what was requested, which policies matched, what was allowed or denied, and how approvers and users interacted. These events can be sent to the Keeper backend and used for reporting and integration with your SIEM or audit tools.

• Logging is configurable so you can tune verbosity and retention for troubleshooting and compliance. Logs help you verify that policies are working as intended and investigate incidents.

Why it matters: You get a clear record of who did what and whether it was allowed or denied by policy. That supports compliance, incident response, and continuous improvement of your rules.

Controlled Plugins and Jobs

• Plugins (e.g., policy engine, backend sync, logger) are loaded and started by the agent from known locations and configurations. They are validated (e.g., path and identity checks) before they run. The agent monitors their health and can restart them if configured.

• Jobs are defined in configuration (e.g., JSON in a controlled directory or via the API) and run under the agent’s control. Task execution is subject to the same authorization and audit as the rest of the system. You control what jobs exist and when they run (schedule, event, or manual).

Why it matters: The only code that runs “as” the agent’s automation and policy engine is code you deploy and the product validates—not arbitrary scripts or executables from the network.

Secure Registration and Backend Communication

• Agent registration uses tokens you create and manage in the Keeper Admin Console. Registration is done over a secure channel (e.g., HTTPS to the local agent, then the agent to the backend). Tokens should be treated as secrets and stored and transmitted securely.

• Communication with the Keeper backend (policy sync, approval data, audit, inventory) uses secure channels (e.g., HTTPS). Credentials and sensitive data are not sent in the clear.

Why it matters: Only agents you explicitly register with a valid token join your tenant. Backend traffic is protected so policies, approvals, and audit data are not exposed in transit.

Operational Security

• Monitor and Monitor & Notify modes let you test policies without blocking users. You can see what would have been allowed or denied (and get notified) before you switch to full enforcement. That reduces the risk of misconfiguration locking people out or opening too much.

• Configuration from the dashboard (policies, approvers, deployment groups, and in many cases plugin or job settings) is pushed to agents over secure sync. So you manage security and compliance from a central place instead of editing files on every machine.

Why it matters: You can roll out and tune policies safely, keep configuration consistent and traceable, and meet strict network or compliance requirements.

Summary

Keeper Privilege Manager is designed to be secure by default and under your control:

Area	How the product helps
Privilege	Zero-standing privilege; policy-gated, time-limited elevation and file access; least-privilege enforcement.
Control	Policy-driven allow/deny/MFA/approval/justification; granular targeting; redirects for controlled “yes.”
Network	Agent API and message bus are localhost-only; no network exposure of the control plane.
Trust	Only KPM-launched (and validated) components can use sensitive APIs; multi-level authorization.
Data	HTTPS/TLS for local traffic; encryption at rest for sensitive storage; certificate-based validation.
Visibility	Audit events for elevation, file access, policy, approvals; configurable logging; backend and SIEM integration.
Operations	Validated plugins and jobs; secure registration and backend sync; Monitor mode; central configuration; airgapped options.

For day-to-day configuration and best practices, see Architecture, Best Practices & FAQs and the rest of this guide. This page is intended to give you a clear, customer-level picture of what makes Keeper Privilege Manager secure.