Keeper Security Benchmarks and Recommended Security Settings
Administrative recommendations for Keeper Security policies and settings
Last updated
Was this helpful?
Enterprise Guide
Administrative recommendations for Keeper Security policies and settings
Last updated
Was this helpful?
Keeper Security Benchmarks measure your organization's baseline of compliance with recommended security settings, policies and controls for achieving best-in-class zero trust and zero knowledge security.
At the foundation, Keeper is an encryption platform with policies and controls in place to protect customer data, within the constraints set by the Keeper Administrator. In this shared security model, the customer is responsible for implementing recommended policies to ensure least privilege, break glass access, and the highest levels of data protection.
This document outlines key recommendations and policies that will help you secure the data stored within the environment, while ensuring the best possible experience for your target users.
Keeper Administrators hold the encryption keys used to access the Admin Console, provision users, manage enforcement policies and perform day to day user administration.
The "Keeper Administrator" role should have at least two users in that role. We strongly recommend adding a secondary admin to this role in case one account is lost, the person leaves the organization or the employee is terminated. The Keeper support team cannot elevate a user to an administrative role or reset an administrator's Master Password, by design.
By design, if all of the Keeper Administrators lose access, Keeper's support team cannot elevate privilege, and Keepers support team cannot approve SSO user devices. Make sure you have a break glass account with root level Keeper Administrator access.
Keeper Administrators have elevated privilege in the platform and must be protected against both outside attacks, identity provider attacks and insider attack vectors. Ensure that the Keeper Administrator role and any other role with administrative privilege is enforcing the use of 2FA.
If an admin is logging in to Keeper with an SSO provider, we still recommend adding the additional layer of 2FA on the Keeper side for any administrative role. This protects against IdP account takeover or other insider threats.
Keeper SSO Connect Cloud provides customers with the ability to provision and authenticate users with their preferred SAML 2.0 identity provider.
While Keeper supports the ability for administrators to login to the Keeper Admin Console with SSO, it is important that at least one administrator account is able to login to Keeper with a Master Password. This is because a situation could occur in which all admins rely on SSO, and there may be no admins to approve a new device. Or, the SSO provider could have an outage which then locks everyone out. We recommend creating an administrator "service account" which uses a strong Master Password, 2FA and (optionally) IP AllowListing to optimally lock down this account.
In the situation where all administrators use SSO, and all administrators are on new devices (unable to approve them) Keeper support will not be able to help recover. By design, Keeper is a zero knowledge platform and our support team has no ability to approve SSO-enabled devices, or recover Device-Encrypted Data Keys for users.
Keeper's role enforcement policies allow customers to create administrative roles within nodes and sub-nodes. It is important to always ensure least privilege for administrators.
Reduce the total number of administrators to the minimum required to operate efficiently
Reduce privilege within administrator roles. For example, if an administrator does not require the ability to manage roles, remove that privilege.
Don't leave old administrator accounts from former employees in an locked state longer than necessary to transfer the contents of the vault.
If you are integrating Keeper with your SSO identity provider, ensure that your IdP is locked down with MFA policies and reduced privilege. Follow the guidance and best practices of your identity provider to ensure that administrative accounts are minimized with the least amount of privilege necessary to perform their jobs.
As with any SaaS platform, account recovery provides end-users with a route to restore access to their account, if the primary authentication methods are lost or forgotten. In Keeper, by default the user has an ability to configure a Recovery Phrase - a simple, auto-generated set of 24 words that can be used to restore access to their Keeper Vault. The recovery phrase encrypts the user's Data Key using a key derivation similar to the Master Password method.
If you are deploying to users with a single sign-on product like Azure or Okta, account recovery may not be necessary or warranted, since authentication is delegated to your identity provider. Therefore, it is best to simply not have account recovery as an option, if this is acceptable to your users.
To disable account recovery, visit the Role > Enforcement Policies > Account Settings > select "Disable Recovery Phrase for account recovery".
Account recovery can be enabled if the affected users store their Recovery Phrase in a safe location.
For users who login with a Master Password, the key to decrypt and encrypt the Data Key is derived from the user’s Master Password using the password-based key derivation function (PBKDF2), with 1,000,000 iterations by default. After the user types their Master Password, the key is derived locally and then unwraps the Data Key. After the Data Key is decrypted, it is used to unwrap the individual record keys and folder keys. The Record Key then decrypts each of the stored record contents locally.
Keeper implements several mitigations against unauthorized access, device verification, throttling and other protections in the Amazon AWS environment. Enforcing a strong Master Password complexity significantly reduces any risk of offline brute force attack on a user's encrypted vault.
Two-Factor Authentication (2FA), also commonly referred to as multi-factor authentication (MFA), adds an additional layer of security to access the vault. The first layer is something your users know; their Master Password or SSO. The second layer is something they have. It can be either their mobile device (SMS text or a TOTP application) or by using a hardware device such as YubiKey or Google Titan key.
To prevent users from accessing their work vault outside of approved locations and networks, administrators should consider activating IP Address Allowlisting. This is a role-based enforcement setting that designated users can only access their vaults when their device is on an approved network.
At minimum, users with Administrative privileges in Keeper should be locked down to specific IPs or IP ranges. This prevents malicious insider attacks as well as identity provider takeover attack vectors. If this is not possible, ensure that MFA is enforced.
Account Transfer provides a mechanism for a designated administrator to recover the contents of a user's vault, in case the employee suddenly leaves or is terminated. This is an optional feature that must be configured by the Keeper Administrator during the initial deployment phase of the Keeper rollout, because it requires specific steps to escrow the user's encryption keys.
The Account Transfer policy is recommended if users are authenticating with a Master Password, and if the enterprise has concerns regarding the loss of specific user vaults.
The Account Transfer policy gives admins with the assigned privilege to perform transfers of a Keeper vault for their managed users. If you have users (such as C-level executives or root-level admins) that do not want their vault transferred under any circumstances, these users can be placed into a role that does not have the transfer policy enabled.
As a general security practice, we recommend that Enterprise customers limit the ability of end-users to install unapproved 3rd party browser extensions. Browser extensions with elevated permissions could have the ability to access any information within any website or browser-based application. Please refer to your device management software to ensure that Keeper is allowed, and unapproved extensions are blocked or removed.
To protect all of your users across all of their devices, applications and websites, Keeper should be deployed to all users in your entire organization who handle privileged credentials. Any administrator or privileged user who does not use a secure password manager can put your organization at risk.
The provides Cloud SSO-enabled users with a frictionless experience when accessing their vault on a new or unrecognized device. While this improves the user experience, it also requires that your SSO identity provider is protected against unauthorized access. If you enable the Keeper Automator service, you are placing full trust in the identity provider authentication and the user provisioning process. For additional security, the Automator service can limit automated approvals to specific IP ranges, or it can be left disabled completely to force users to manually approve new devices.
The National Institute of Standards and Technology (NIST) provides password guidelines in: . The guidelines promote a balance between usability and security; Or in other words, passwords should be easy to remember but hard to guess. The NIST instruction recommends an eight character minimum but a higher value will ultimately result in a harder to guess/crack password. Keeper enforces at least 12 characters. We recommend increasing this to 16 or more.
Password complexity can be configured on a per role-basis. See the enforcement setting in the guide.
While Keeper's cloud infrastructure implements several mitigations against brute force attack, adding a second means of authentication will makes it considerably more difficult for an attacker to gain access a user's vault. Using a role based enforcement can ensure all users of the enterprise are mandated to configure 2FA on their vault account. SSO-enabled users should ensure 2FA is configured with their IdP at a minimum. Keeper checks for a signed assertion from the identity provider during SSO authentication. For additional security, 2FA can be enabled on the Keeper side in addition to the IdP. To set up 2FA See the section in the guide:
Visit the section on for more information on configuring roles to include this feature.
For step by step details visit the .
Keeper's Advanced Reporting System provides built-in Alerting capabilities that will notify users and Administrators for important events. As a best practice, we have that can be configured by the Keeper Administrator. Alerts should be enabled on key administrative events to notify any suspicious activity coming from both external and insider threats.
Modern browsers typically have their own versions of a password manager. In addition to being less robust and secure than Keeper, these password managers can conflict with Keeper, causing login issues or even security contradictions. To prevent conflicts and harden security, Keeper recommends .
