For the complete documentation index, see llms.txt. This page is also available as Markdown.

System Extension Configuration

The macOS System Extension (KeeperSystemExtension) is the user-space component that gives KEPM visibility into privilege elevation requests, command-line invocations, and package installations on macOS. It uses Apple's Endpoint Security Framework to intercept authorization petitions — the same mechanism macOS uses for UAC-like elevation prompts — and routes them through the KEPM policy engine before allowing or denying them.

This page covers what the System Extension is, the identifiers and entitlements MDM administrators need to allowlist it, how to configure it, and how to troubleshoot common issues.


Identifiers and Code Signing

KEPM's macOS components are signed and distributed by Keeper Security. The values below are required for any MDM-managed allowlisting, PPPC profile, or System Extension policy.

Property
Value

App name

Keeper Endpoint Privilege Manager.app

App bundle ID

com.keeper.endpoint-privilege-manager

App install path

/Applications/Keeper/Keeper Endpoint Privilege Manager.app

System Extension name

com.keeper.keeper-privilege-manager.monitor.systemextension

System Extension bundle ID

com.keeper.keeper-privilege-manager.monitor

System Extension binary path

/Applications/Keeper/Keeper Endpoint Privilege Manager.app/Contents/Library/SystemExtensions/com.keeper.keeper-privilege-manager.monitor.systemextension/Contents/MacOS/com.keeper.keeper-privilege-manager.monitor

System Extension type

EndpointSecurityExtension

Notification helper bundle ID

com.keeper.keepernotify

Apple Developer Team ID

234QNB7GCA (verifiable on any installed Mac with codesign -dv "/Applications/Keeper/Keeper Endpoint Privilege Manager.app")

Signing Authority

Developer ID Application: Callpod Inc. (234QNB7GCA)

Runtime identifier (in systemextensionsctl list)

com.keeper.keeper-privilege-manager.monitor

Code requirement (extension)

anchor apple generic and identifier "com.keeper.keeper-privilege-manager.monitor" and (certificate leaf[field.1.2.840.113635.100.6.1.9] /* exists */ or certificate 1[field.1.2.840.113635.100.6.2.6] /* exists */ and certificate leaf[field.1.2.840.113635.100.6.1.13] /* exists */ and certificate leaf[subject.OU] = "234QNB7GCA")

Code requirement (app)

anchor apple generic and identifier "com.keeper.endpoint-privilege-manager" and (certificate leaf[field.1.2.840.113635.100.6.1.9] /* exists */ or certificate 1[field.1.2.840.113635.100.6.2.6] /* exists */ and certificate leaf[field.1.2.840.113635.100.6.1.13] /* exists */ and certificate leaf[subject.OU] = "234QNB7GCA")

Code requirement (notification helper)

anchor apple generic and identifier "com.keeper.keepernotify" and (certificate leaf[field.1.2.840.113635.100.6.1.9] /* exists */ or certificate 1[field.1.2.840.113635.100.6.2.6] /* exists */ and certificate leaf[field.1.2.840.113635.100.6.1.13] /* exists */ and certificate leaf[subject.OU] = "234QNB7GCA")

Why "Callpod Inc."? Keeper Security is a wholly-owned subsidiary of Callpod Inc. Apple requires Developer ID certificates to be issued to the parent legal entity, so the signing Authority string reads Callpod Inc. rather than Keeper Security, Inc. This is expected — do not flag profiles with this Authority string as suspicious.

Why does each component have its own bundle ID? Each Keeper macOS component (app, extension, notification helper, and any plugins) is signed with a distinct bundle ID under the com.keeper.* namespace so they can be allowlisted, audited, and controlled independently.

How it Works

When a user attempts to run a command with sudo, install a .pkg file, or trigger any other authorization petition on a managed Mac, the System Extension intercepts the request before macOS processes it. It sends the request to the KEPM policy engine via the internal MQTT broker, waits for a policy decision, and responds accordingly — allowing, denying, or triggering a control flow (justification, MFA, or approval).

For .dmg disk image opens, the System Extension coalesces burst events: regardless of how many open events macOS generates for the same file, the user sees exactly one policy prompt and the agent processes exactly one policy request per mount operation.

The System Extension runs in user space (not the kernel) using Apple's Endpoint Security Framework, and requires explicit user approval — or MDM pre-approval — before it can be activated.

Why the app installs under /Applications/Keeper/ rather than /Library/Keeper/: Apple's System Extensions and Drivers documentation requires that "your app is installed in an appropriate Applications directory of the system" before the System Extension framework will allow activation. KEPM places the app under /Applications/Keeper/ to satisfy this requirement. Supporting binaries that are not subject to this constraint (CLI tools, plugins, jobs, configuration) continue to live under /Library/Keeper/.

MDM Deployment

A complete MDM rollout of KEPM requires three configuration profiles, deployed in order:

  1. System Extension allowlist — pre-approves the extension so it activates silently on install.

  2. Full Disk Access (PPPC) — grants the app and extension the file-system visibility needed to enforce policy.

  3. Notification permissions (recommended) — allows KEPM to display elevation prompts and approval status.

Deploy the System Extension allowlist before installing the KEPM package. If the extension is installed before the allowlist profile is in place, the user will see a "System Extension Blocked" notification and the extension will enter the [terminated waiting for user] state until approved manually in System Settings or until an MDM profile arrives.

1

System Extension Allowlist Profile

This profile uses Apple's com.apple.system-extension-policy payload to pre-approve KEPM's Endpoint Security extension.

AllowUserOverrides is set to true so administrators can manually remove the extension during troubleshooting; set it to false to enforce strict policy and prevent local removal.

2

Full Disk Access (PPPC)

The System Extension and the Keeper Endpoint Privilege Manager app both require Full Disk Access to monitor file operations and intercept authorization events.

Interactive install: When a user is logged in at the console, the installer automatically opens System Settings to the Full Disk Access pane and displays a floating alert listing the items that need approval:

  • Keeper Endpoint Privilege Manager (/Applications/Keeper/Keeper Endpoint Privilege Manager.app)

  • com.keeper.keeper-privilege-manager.monitor (the System Extension, shown by bundle ID)

MDM / headless install: When deployed via MDM (no interactive terminal), the installer skips the FDA dialog automatically. Grant Full Disk Access using the Privacy Preferences Policy Control payload below.

The certificate leaf[subject.OU] = "234QNB7GCA" clause in CodeRequirement pins the profile to Keeper-signed binaries only. Without it, a non-Keeper binary registering the same bundle ID would inherit Full Disk Access — a real risk worth eliminating.

3

KEPM uses KeeperNotify — a Swift-based companion app — to display elevation prompts, approval results, and policy notifications in the macOS Notification Center. Without this profile, users may not see elevation prompts until they manually approve notifications in System Settings.

AlertType: 2 displays persistent alerts (banner that stays until dismissed), appropriate for elevation prompts that require user action. Use 1 for temporary banners if you prefer less intrusive notifications.

Verifying MDM Deployment

After all three profiles deploy and the KEPM package installs, verify on a target Mac:

The extension should appear as [activated enabled]. auth_value=2 in the TCC database means access is granted (0=denied, 1=prompt, 2=allowed).

Configuration File

The System Extension is configured via SystemExtension.json. KeeperPrivilegeManager reads this file and serves its contents to the System Extension over HTTPS when the extension initializes or reconnects. The file is located at:

Settings are structured as a nested JSON object under a top-level "metadata" key. The sections below show each setting using its full JSON path (e.g. metadata.mqttOutages.connectionFailureBehavior). All settings ship with defaults in the file; override only the values that need to differ from those defaults.

MQTT Outage Behavior

If the System Extension loses its connection to the internal MQTT broker (which can happen briefly during service restarts), it falls back to a configurable behavior for pending authorization petitions. This is a deliberate fail-open default to prevent the machine from becoming unusable if the KEPM service is temporarily unavailable.

Setting
Default
Description

metadata.mqttOutages.connectionFailureBehavior

"allow"

What to do with authorization petitions during an MQTT outage: "allow" or "deny"

metadata.mqttOutages.retries.minDelay

1

Minimum delay in seconds between reconnect attempts

metadata.mqttOutages.retries.maxDelay

20

Maximum delay in seconds between reconnect attempts (exponential backoff cap)

Security note: If your security posture requires fail-closed behavior (deny all during MQTT outages), set connectionFailureBehavior to "deny". Be aware that this means any KEPM service interruption will block all privilege elevation on the affected Mac until the service is restored.

Policy Response Timeout

If the policy engine does not respond to an authorization petition within the configured timeout, the System Extension falls back to a configurable action.

Setting
Default
Description

metadata.policy.maxResponseTimeout

5.0

Seconds to wait for a policy decision before applying the timeout action

metadata.policy.onPolicyTimeout

"allow"

Action on timeout: "allow" or "deny"

The 5-second default is appropriate for most environments. For approval-gated workflows where a user must wait for a remote approver to respond, increase this value to match your expected approval latency — for example, 300 for a 5-minute approval window. Be aware that setting this too high will cause elevation requests to hang for the full duration if the policy engine is unavailable.

Policy Response Cache

The extension caches policy responses to avoid re-evaluating repeated identical requests within a short window.

Setting
Default
Description

metadata.policy.cache.cleanupInterval

30

How often (in minutes) the cache sweeps and removes expired entries

metadata.policy.cache.expireAfter

60

How long (in seconds) a cached policy response remains valid

High-Load Relief

When the policy engine is saturated and stops responding promptly, the extension can automatically allow requests from known-safe system paths rather than queuing them behind overloaded policy evaluation.

Setting
Default
Description

metadata.policy.highLoad.inflightThreshold

200

Number of concurrent in-flight policy requests at which high-load relief engages

metadata.policy.highLoad.fallbackAllowPaths

(see below)

Paths auto-allowed while the threshold is exceeded

The default fallbackAllowPaths covers standard macOS system locations:

Only modify this list if you have tested the impact. Removing system paths from the fallback list under sustained high load may cause system processes to be delayed or denied.

Path Allow-Lists

The System Extension uses allow-lists to identify activity that should pass through without a full policy round-trip — typically Keeper's own binaries and well-known macOS system paths that do not require monitoring.

Setting
Description

metadata.fileAccess.allowPaths

File paths exempt from file-access policy evaluation

metadata.commandLine.allowPaths

Executable paths exempt from command-line policy evaluation

metadata.privilegeElevation.allowPaths

Executable paths exempt from privilege-elevation policy evaluation

Example — adding a path to the file-access allow-list:

Only add paths you are confident do not need policy coverage. Adding too broadly may create gaps in policy enforcement.

Updating Settings via Policy

System Extension settings can also be updated from the Admin Console using an UpdateSettings policy, without requiring manual file edits on each endpoint. When a settings update is applied, the extension fetches the revised configuration from KeeperPrivilegeManager over HTTPS. This is the recommended approach for fleet-wide configuration changes. See Update Settings Policy Type for details.

Checking Extension Status

The Keeper extension should appear in systemextensionsctl list with status [activated enabled]. If it shows [terminated waiting for user], the System Extension allowlist profile (see above) has not been deployed, or the user has not yet approved the extension in System Settings → Privacy & Security.

The codesign output should show:

  • Identifier=com.keeper.endpoint-privilege-manager (for the app) or Identifier=com.keeper.keeper-privilege-manager.monitor (for the extension)

  • TeamIdentifier=234QNB7GCA

  • Authority=Developer ID Application: Callpod Inc. (234QNB7GCA) (Callpod is Keeper's parent company — see the note in the Identifiers table)

Troubleshooting

The extension is installed but privilege elevation is not being intercepted. Confirm Full Disk Access has been granted to both the extension and the app. In System Settings → Privacy & Security → Full Disk Access, both Keeper Endpoint Privilege Manager and the com.keeper.keeper-privilege-manager.monitor extension should be listed and enabled. If the PPPC profile is deployed but FDA still shows as off, verify the CodeRequirement Team ID in your profile matches the actual signing Team ID returned by codesign -dv.

Authorization petitions are timing out and users are blocked. Either the KEPM service is not running, or the policy engine is not responding. Check that the service is running and that the KeeperPolicy plugin is in a Running state. If the service is healthy, check whether the timeout is set to a value that is too short for your approval workflow.

Package installations are not being intercepted. Verify the extension is in [activated enabled] state via systemextensionsctl list. If it is activated but packages are not being intercepted, confirm the KEPM service was running at the time of the installation attempt and review the service log for MQTT-level errors.

The extension appears in systemextensionsctl list as [terminated waiting for user]. The System Extension allowlist profile has not been received, or its AllowedSystemExtensions Team ID does not match the binary. Verify the profile is installed (profiles show -type configuration) and that the Team ID in the profile matches the output of codesign -dv "/Applications/Keeper/Keeper Endpoint Privilege Manager.app/Contents/Library/SystemExtensions/com.keeper.keeper-privilege-manager.monitor.systemextension". On a user-managed Mac without MDM, re-open the Keeper Endpoint Privilege Manager app from /Applications/Keeper/ and approve the extension manually in System Settings.

The extension appears as [terminated] after a macOS upgrade. Re-open the Keeper Endpoint Privilege Manager application from /Applications/Keeper/ to trigger re-installation of the extension, then approve it in System Settings (or re-push the allowlist profile if MDM-managed).

Users see "Notification not delivered" or no prompts for elevation requests. The notifications PPPC profile has not been deployed, or the user has revoked notification permissions. The notification helper is a separate binary with its own bundle ID (com.keeper.keepernotify) — verify with defaults read com.apple.ncprefs apps | grep com.keeper.keepernotify. The entry should show a flags value indicating notifications are enabled. If the notification profile targets the wrong bundle ID (e.g. com.keeper.endpoint-privilege-manager), notifications will not be delivered.

Last updated