Security Hardening

This guide covers security best practices and hardening recommendations for KEPM deployments. The default configuration is designed to be secure out of the box, but the settings in this guide will help you meet stricter security requirements in enterprise and regulated environments.

Network Security

All communication stays on localhost. The KEPM agent binds exclusively to 127.0.0.1 — the HTTP server (ports 6888 and 6889) and the internal MQTT broker (port 8675) are never exposed to the network. No firewall rules are required for inbound access, and no network-level access controls are needed.

Do not expose the local API to the network. The API is designed for local inter-process communication only. If you are considering binding it to a network interface for remote management, contact Keeper before doing so — the authorization model is not designed for network-accessible endpoints.

Verify localhost-only binding after deployment:

# Windows
netstat -an | findstr :6889
# Expected: TCP 127.0.0.1:6889 ... LISTENING

# Linux / macOS
netstat -an | grep :6889
# Expected: 127.0.0.1:6889 ... LISTEN

TLS is always on. All HTTPS communication uses TLS 1.2 or TLS 1.3. The agent generates a self-signed certificate at startup for localhost use. This is the correct and expected behavior — the certificate secures localhost communication, and self-signed certificates are appropriate in this context.

Service Account Configuration

Run as SYSTEM or root. The KeeperPrivilegeManager service must run as SYSTEM on Windows or root on Linux/macOS. This is a hard requirement — running as a lower-privileged account will prevent the agent from intercepting elevation requests and enforcing policies.

Installation path must be owned and writable only by the service account. The installation directory and all subdirectories must be owned by the service account and not writable by standard users. If a non-privileged user can modify executables or plugin files in the installation directory, the cryptographic validation protecting against tampered plugins is undermined.

Verify path security on Linux/macOS:

# Check that /opt/keeper/sbin and all parent directories are root-owned
# and not world-writable
ls -la /opt/keeper/
stat /opt/keeper/sbin/KeeperPrivilegeManager

On Windows, verify the installation directory ACL:

Get-Acl "C:\Program Files\Keeper Security\Endpoint Privilege Management" | Format-List

Standard users should have Read and Execute, but not Write or Modify.

Certificate and Signature Management

Leave AlternativeSignatures empty unless you have a specific need. The AlternativeSignatures setting in appsettings.json allows additional certificate thumbprints to be trusted for plugin signing. The default (empty) configuration means only Keeper-signed plugins will load. Adding thumbprints here allows third-party or custom plugins — review the need carefully before adding any entry.

{
  "Settings": {
    "AlternativeSignatures": []
  }
}

Never store certificate passwords in configuration files. If you are deploying custom certificates, use the Windows Certificate Store or a platform credential manager to store credentials. The CertPassword field in the configuration should always be empty.

Rotate custom certificates on a regular schedule. If your organization uses custom certificates for the KEPM HTTPS endpoint, establish a rotation schedule consistent with your PKI policy (typically annually or when a certificate approaches its expiry date). The agent generates a new self-signed certificate automatically at each restart if no custom certificate is configured.

File Permissions

The following permission model should be enforced on all platforms:

Directory

Recommended Access

Installation root	Service account: Full control; Administrators: Read/Execute; Users: none
Plugins/	Service account: Full control; Administrators: Read/Execute; Users: none
Jobs/	Service account: Full control; Administrators: Read/Execute; Users: none
KeeperStorage/	Service account: Full control; Administrators: Read only; Users: none
policies/	Service account: Full control; Administrators: Read only; Users: none

On Linux, verify that the /opt/keeper/sbin/ directory tree is owned by root and that group and world write permissions are absent:

find /opt/keeper/sbin -perm /o+w -o -perm /g+w | head
# Should return nothing

Allowed Hosts

The AllowedHosts setting in appsettings.json controls which HTTP Host headers are accepted. The default value of "*" accepts any host header — this is acceptable for localhost-only deployments but can be tightened:

{
  "AllowedHosts": "localhost;127.0.0.1"
}

In production deployments where only local processes will interact with the API, set this to localhost;127.0.0.1. Changes to AllowedHosts require a service restart.

Audit Logging

Audit logging is enabled by default and cannot be disabled. All policy evaluations, privilege elevations, file access attempts, configuration changes, and administrative actions are recorded automatically to the MQTT AuditMessage topic and unified storage.

Audit logs are the primary evidence source for compliance reviews, incident response, and policy effectiveness analysis.

Review logs regularly. At a minimum, review audit logs weekly for:

• Repeated High-Frequency Policy evaluations from a single user that could indicate policy circumvention attempts

• Administrative Actions — Admin-level API calls carry the highest privilege in the local authorization model. Logging who performed them and when creates the audit trail needed to detect privilege abuse and satisfy compliance requirements.

• Policy Evaluation Denials — A spike in denials can reveal either a misconfigured policy that is blocking legitimate work, or a user or process actively testing the boundaries of what is permitted — both require investigation.

• Configuration Changes — Changes to appsettings.json, plugin configs, or job definitions directly affect what the agent trusts and enforces. Unauthorized or unexpected changes are a strong indicator of tampering or a supply-chain-style attack against the agent itself.

• Failed Authentication Attempts — Repeated failures against the local API indicate a process on the endpoint is attempting unauthorized access, which could signal malware, a compromised application, or a misconfigured integration probing for access.

  • AUTHORIZATION_FAILED and PROCESS_AUTHENTICATION_FAILED are defined as audit event types and recorded, but these are local API authorization failures, not endpoint-level login failures. Whether a specific failure scenario surfaces as an audit event depends on where in the stack it occurs.

• Policy Circumvention Attempts — The policy engine tracks evaluation requests per source, keyed by SessionId or UserName+MachineName combination, and queues requests that exceed the configured rate limit (default: 100 requests per minute). A circuit breaker opens after 10 consecutive failures from the same source and remains open for 5 minutes before auto-resetting. In the audit log, look for a single user_info value generating an abnormal volume of policy_evaluation_status DENY events against the same target_info in a short window, or bursts that trigger the rate limiter queue — both indicate a user or automated process probing for a permissive execution path rather than performing legitimate work.

Retain logs for your compliance requirement period. Log files are retained for 15 days by default. If your compliance framework (SOC 2, ISO 27001, FedRAMP, etc.) requires longer retention, implement log forwarding to a SIEM or central log store before the 15-day window expires. See Reading Logs for log file paths.

Security Monitoring Recommendations

Monitor for the following conditions and set up alerts where your infrastructure supports it:

Area	Recommendation
Agent Availability	Monitor for unexpected service stops or agent going offline; treat unscheduled outages as potential tampering until ruled out
Audit Logging — Config Changes	Alert on changes to appsettings.json; monitor plugin and job configuration files separately via file integrity monitoring
Audit Logging — Denials	Export to SIEM regularly; alert on repeated DENY events from the same user_info in a short window
Audit Logging — Registration	Alert on agent registration events that occur outside scheduled deployment windows
Certificates	Never store passwords in config; keep AlternativeSignatures empty or minimal
File Permissions	Admin-only read/write on config, storage, and policy paths
Log Levels	Set to Warning or Information in production (not Debug)
Network	Keep localhost-only binding; set AllowedHosts to specific hostnames
Process Authentication	Review service logs for process authentication events involving processes not launched by KEPM; these appear as PROCESS_AUTHENTICATION_FAILED entries and should be rare in a healthy deployment
Service Account	Run as SYSTEM (Windows) or root (Linux/macOS)