A Keeper Enterprise tenant holds the shared credentials of a whole organisation, so the admin roles, enforcement policies, device approval method and machine access configuration around it decide how far one compromised administrator or client device can reach. This guide explains how to run Keeper securely, using Keeper's own documentation as the source for every product detail (checked 8 November 2026). It covers roles and the Keeper Administrator role, enforcement policies, SSO Connect Cloud and device approvals, Keeper Secrets Manager (KSM) applications, client devices and one-time access tokens, the Advanced Reporting and Alerts Module (ARAM), and a hardening baseline. It is written for identity teams, security engineers and IT administrators who own a Keeper Business or Enterprise tenant. For the general discipline see the Secrets Management Guide.
This is an independent guide from NHI Mgmt Group, based on Keeper's public documentation as of November 2026. It is not sponsored or reviewed by Keeper. Product features change, so confirm settings against Keeper's current documentation.
Key takeaways
- Roles carry both policy and power. In Keeper a role applies enforcement policies to users and can also grant administrative permissions in the Admin Console, so role design is the core of least privilege.
- The most restrictive policy usually wins. Keeper applies every enforcement from every role a user holds, with the net result typically the most restrictive, which makes a tight baseline role safe to layer under team roles.
- Device approval is where SSO trust is decided. SSO Connect Cloud authenticates with SAML 2.0, but a new device only gets the user's encrypted data key after approval by Keeper Push, an administrator, Commander or a customer-hosted Keeper Automator.
- KSM client configurations are the real machine credential. The one-time access token is consumed on first use; the resulting configuration holds the client's private key and application key, and must be stored like any other secret.
- ARAM gives immutable events and real-time alerts. Keeper describes it as an append-only audit system with over 200 event types, alerts by email or SMS and export to one external SIEM destination at a time; custom reports and alerts need the ARAM add-on.
How identity and access work in Keeper
Keeper describes its platform as zero-knowledge: encryption and decryption happen on the client, and Keeper's cloud stores and transmits ciphertext. Users reach the vault either with a master password or through SSO Connect Cloud, and administrators organise the tenant into a tree of nodes beneath a Root Node, with roles and teams attached to nodes.
- Roles: define enforcement policies and, optionally, administrative permissions. Roles can be created manually, through SCIM, Keeper Commander or the Keeper AD Bridge for Active Directory and LDAP.
- Teams: mainly for sharing records and shared folders. A role assigned to a team gives its members the role's enforcements, but Keeper blocks administrative roles from being mapped to teams so that a team change cannot silently elevate someone. With SCIM, group names carrying an optional prefix map to roles rather than teams.
- Master password users: governed by Master Password Complexity (length, digits, upper and lower case, special characters) and Master Password Expiration (10 to 150 days, not applied to SSO Connect Cloud users).
SSO Connect Cloud and device approvals
SSO Connect Cloud is a SAML 2.0 service that adds Keeper's zero-knowledge encryption to an existing identity provider; Keeper lists Microsoft Entra ID, Okta, Google Workspace, Duo, OneLogin, Ping Identity and JumpCloud among compatible providers. Because Keeper never holds the keys, a new device must receive the user's encrypted data key from somewhere. The device generates an elliptic curve key pair; after identity provider authentication, an approval step delivers the encrypted data key, which the device decrypts locally.
| Approval method | Who approves | Security considerations |
|---|---|---|
| Keeper Push | The user, from an existing logged-in device | Depends on users recognising unexpected requests; no administrator involvement |
| Admin Approval | An administrator in the Admin Console | Strong human check, but slow at scale and only as good as the administrator's verification of the request |
| Keeper Automator | A customer-hosted service, without user interaction | Keeper's documented preferred option; the service becomes a sensitive component that must be hardened, patched and monitored |
| Commander CLI | An administrator, semi-automated | Useful for bulk approvals; protect the Commander session that performs them |
Decision guidance: small organisations with a handful of new devices a month can use Admin Approval or Keeper Push; large organisations usually need Keeper Automator to avoid approval fatigue. Note that guest, private or incognito browser sessions count as a new device every time they launch.
Admin roles and privileged access
Keeper creates a default Keeper Administrator role under the Root Node for the initial administrator, with full administrative rights. Keeper strongly recommends adding a secondary administrator to that role so that the tenant is not lost with one account. Beyond it, create narrower roles: Keeper encourages an optional General Employee role for the baseline, and administrative permissions can be granted per role and scoped to nodes.
| Role pattern | Purpose | Hardening note |
|---|---|---|
| Keeper Administrator | Full tenant control from the Root Node | Two or three named people, phishing-resistant 2FA, IP allow list |
| Delegated node administrators | Manage users and teams in one business unit or region | Scope to the node; avoid Root Node grants |
| Baseline user role | Enforcements for everyone | 2FA, logout timer, export restriction, sharing limits |
| KeeperPAM and KSM roles | Permissions such as "Can create applications and manage secrets", "Can rotate credentials", "Can launch connections", "Can view session recordings" | Grant to platform engineers only; separate who configures from who uses |
| Transfer Account role | The role eligible to perform account transfers | Restrict tightly: transfer moves a departing user's vault to another user |
Account transfer: the Transfer Account policy is a toggle plus a choice of the role that may perform transfers, and users must accept the transfer agreement at vault login before a transfer can occur. Because a transfer hands one person's records to another, treat the eligible role as privileged and log every use.
Privileged access to infrastructure through KeeperPAM brings further permissions, including Keeper Gateway deployment, rotation settings, tunnels and remote browsing. Each is a distinct privilege, so map them to separate roles rather than one platform-admin role. See the Privileged Access Management Guide.
Integrations, API tokens and service accounts
Keeper Secrets Manager is Keeper's cloud, zero-knowledge service for non-human identities and infrastructure secrets such as API keys, database passwords, access keys and certificates. Its objects map directly to access control decisions.
| KSM object | What Keeper's documentation says | Security implication |
|---|---|---|
| Application | The permission boundary defining which records and shared folders a workload can access; holds permissions, client devices, audit trail and history; Keeper recommends up to 500 records per application | Create one application per workload or environment so a breach is bounded |
| Client device | A machine, service or runtime instance (a developer machine, a Terraform script, a CI/CD instance) with its own unique key; many per application | One client per consumer gives precise revocation |
| One-Time Access Token | 32 random bytes with a region prefix; a provisioning credential, not a bearer credential; consumed by the first API call; expires (default 24 hours) and can be locked to a source IP | Deliver it just before first use; an unused token is a live provisioning secret until expiry |
| Configuration | JSON holding fields such as clientId, privateKey and appKey; one per client device | This is the long-lived credential; protect it like a private key |
Protecting client configurations
- Use native secure storage: the KSM CLI stores configuration in the operating system store by default (Keychain, Windows Credential Manager or Secret Service on Linux), with
keeper.inias an optional alternative. The developer SDKs can protect configuration files with AWS KMS, Azure Key Vault, Google Cloud KMS, Oracle Key Vault or an Entrust HSM. - Keep IP lockdown on: Keeper's encryption model page recommends keeping client IP lockdown enabled unless the deployment has a dynamic WAN IP.
- Set client expiration: client access expiration is an optional setting, disabled by default; use it for temporary and ephemeral clients.
- Revoke precisely:
secrets-manager client revoke --client [ClientID]in Commander cuts a client off immediately without rotating the application or re-keying records. Still rotate the secrets that client could read if you believe its configuration was copied. - Know the key hierarchy: the AES-256 Application Key decrypts shared folder and record keys, and each client signs requests with its own ECC secp256r1 private key that never leaves the device.
Commander and automation
Keeper Commander is both an administration tool (roles, approvals, reports, KSM client management) and an automation surface, and the Platform Restriction policy can allow or block the Commander SDK per role. Restrict Commander to the roles that need it, and treat any service identity running Commander scripts as a privileged non-human identity. For pipeline patterns see the CI/CD Pipeline Identity Security Guide.
Logging and detection
All Business and Enterprise subscriptions include the Recent Activity report (last 1,000 events) and All Security Events. ARAM, a paid add-on, adds custom reports and alerts across more than 200 event types and is described by Keeper as an immutable, append-only audit system that administrators cannot alter. Alerts go to email, SMS or both, to recipients who need not be enterprise users, with frequency set to Every Occurrence or Once Per Time Period. One external SIEM sync can be active at a time; destinations include Splunk, Microsoft Sentinel, Azure Monitor, Elastic, IBM QRadar, Google Security Operations, Sumo Logic, Datadog, Syslog and AWS S3.
| Detection goal | Keeper source | Alert or report |
|---|---|---|
| Password spraying or stolen credentials | login_failure events with result codes such as auth_failed | ARAM alert on failure bursts per user or remote address |
| Unusual sign-in | login events carrying client version and remote address | Correlate with identity provider sign-ins in the SIEM |
| Record tampering | record_update with the Record UID | Alert on changes to privileged shared folders |
| Policy relaxation and admin change | Admin Console events | Alert every occurrence to the security team |
| Weak or reused passwords | Commander security-audit-report | Monthly trend |
| Oversharing | Commander share-report and compliance-report | Quarterly access review evidence |
Metrics that show the controls work:
- Number of users in the Keeper Administrator role (target two or three, never one).
- Percentage of users covered by a role enforcing 2FA with FIDO2 WebAuthn or TOTP rather than SMS.
- KSM client devices with IP lockdown enabled, and with expiration set where temporary.
- Unused one-time access tokens older than one day (target zero).
- Median time from a device approval request to decision, and the share of approvals by Automator versus people.
- ARAM alerts acknowledged within the agreed response time.
Hardening baseline
Roll out in phases. Keeper warns that IP allow lists can lock you out, so test each restrictive policy on a role that does not include your own account, then a pilot group, before applying it widely. Rolling back is a matter of removing users from the pilot role or relaxing the policy.
- Protect the top role: add a secondary Keeper Administrator, enforce 2FA for that role with FIDO2 WebAuthn security keys, and apply an Allow IP List for administrators.
- Create a baseline role for everyone: enforce Two-Factor Authentication with allowed methods limited to FIDO2 WebAuthn, TOTP and Duo where available (drop Text Message), set the Logout Timer for Web, Mobile and Desktop, restrict Export from vault, and set Master Password Complexity for master password users.
- Control sharing: under Creating and Sharing, decide on Share to users outside of the enterprise, Share records with file attachments and Generate One-Time Share links; disable what the business does not need.
- Restrict platforms: use Platform Restriction to block clients you do not support, including the Commander SDK for ordinary users.
- Integrate identity: deploy SSO Connect Cloud, choose a device approval method, and provision through SCIM so leavers are removed at the source.
- Govern KSM: one application per workload, one client per consumer, IP lockdown on, configurations in native secure storage or KMS-protected files, and a register of applications and owners.
- Turn on monitoring: enable ARAM, connect the SIEM, and build alerts for administrator changes, login failure bursts and privileged record updates.
Framework mapping
| Keeper control | NIST CSF 2.0 | NIST SP 800-53 Rev 5 |
|---|---|---|
| 2FA, master password complexity, SSO Connect Cloud | PR.AA-01 | IA-2, IA-5 |
| Roles, node-scoped administration, KSM application boundaries | PR.AA-05 | AC-6 |
| SCIM provisioning, account transfer, client revocation | PR.AA-01 | AC-2 |
| Zero-knowledge keys, client configuration protection | PR.DS-01 | SC-12, SC-28 |
| ARAM events, alerts and SIEM export | DE.CM-03 | AU-2, AU-6 |
Common misconfigurations
- A single Keeper Administrator: the tenant depends on one account, against Keeper's own recommendation of a secondary administrator.
- Allowing SMS as a 2FA method: Text Message remains selectable per role; we (NHI Mgmt Group) recommend turning it off for administrators and using a stronger method for the most important accounts.
- Testing an IP allow list on your own role: the documented lockout risk; build and test on a separate role first.
- Shared KSM clients: one configuration copied to many hosts or pipelines, so revocation breaks everything and attribution is lost.
- Configurations in plain files:
keeper.inior JSON configs committed to repositories or baked into images, when native secure storage or KMS protection is available. - Automator treated as a utility: the customer-hosted approval service can release keys to new devices without user interaction, yet is left unpatched and unmonitored.
Practitioner checklist
- Add a secondary Keeper Administrator and enforce FIDO2 WebAuthn and an IP allow list for that role.
- Build a baseline enforcement role for all users with 2FA, logout timers and export restriction; remove SMS as a 2FA method.
- Scope delegated administrators to nodes and keep administrative roles off teams.
- Restrict the Transfer Account role and the Commander SDK to named administrators.
- Choose a device approval method for SSO Connect Cloud and harden Keeper Automator if you run it.
- Create one KSM application per workload and one client per consumer, with IP lockdown on.
- Store KSM configurations in OS secure storage or KMS-protected files, never in repositories.
- Enable ARAM, stream to your SIEM and alert on admin changes, login failure bursts and privileged record updates.
- Run share, compliance and security audit reports quarterly as access review evidence.
Standards and references
- Keeper: Roles, RBAC and Permissions
- Keeper: Enforcement Policies
- Keeper: SSO Connect Cloud
- Keeper: Device Approvals
- Keeper: Secrets Manager Overview
- Keeper: Secrets Manager Terminology
- Keeper: Secrets Manager Security and Encryption Model
- Keeper: Advanced Reporting and Alerts Module (ARAM)
Related NHI Mgmt Group resources: Secrets Management Guide · Privileged Access Management Guide · CI/CD Pipeline Identity Security Guide