LogoLogo
Enterprise Guide
Enterprise Guide
  • Getting Started
  • Start Your Trial
  • Resources
  • Keeper for Teams and Small Business
  • Keeper Enterprise
  • Implementation Overview
  • Domain Reservation
  • Deploying Keeper to End-Users
    • Desktop Applications
      • Launch on Start Up
    • Browser Extension (KeeperFill)
      • Mac
        • PLIST (.plist) Policy Deployment
          • Jamf Pro Policy Deployment - Chrome
          • Microsoft Intune Policy Deployment - Chrome
      • Linux
        • JSON Policy Deployment - Chrome
      • Windows
        • Group Policy Deployment - Chrome
        • Group Policy Deployment - Firefox
        • Group Policy Deployment - Edge
        • SCCM Deployment - Chrome
        • Intune - Chrome
        • Intune - Edge
        • Edge Settings Policy
        • Chrome Settings Policy
      • Virtual Machine Persistence
    • Mobile Apps
      • IBM MaaS360
    • Optional Deployment Tasks
    • IE11 Trusted Sites
  • End-User Guides
  • Keeper Admin Console Overview
  • Nodes and Organizational Structure
  • Risk Management Dashboard
  • User and Team Provisioning
    • Custom Invite and Logo
      • Custom Email - Markdown Language
    • Simple Provisioning through the Admin Console
    • Active Directory Provisioning
    • LDAP Provisioning
    • SSO JIT (Just-in-Time) Provisioning
    • Okta Provisioning
    • Entra ID / Azure AD Provisioning
    • Google Workspace Provisioning
    • JumpCloud Provisioning
    • CloudGate Provisioning
    • OneLogin Provisioning
    • Microsoft AD FS Provisioning
    • API Provisioning with SCIM
      • Using SCIM API Provisioning
    • Team and User Approvals
    • Email Auto-Provisioning
    • CLI Provisioning with Commander SDK
  • SSO / SAML Authentication
  • User Management and Lifecycle
  • Email Address Changes
  • Roles, RBAC and Permissions
    • Enforcement Policies
    • Security Keys
  • Delegated Administration
  • Account Transfer Policy
  • Teams (Groups)
  • Sharing
    • Record and File Sharing
    • Shared Folders
    • PAM Resource Sharing
    • One-Time Share
    • Share Admin
    • Time-Limited Access
    • Self-Destructing Records
    • Hiding Passwords
  • Creating Vault Records
  • Importing Data
  • Record Types
  • Two-Factor Authentication
  • Storing Two-Factor Codes
  • Security Audit
    • Security Audit Score Calculation
  • BreachWatch (Dark Web)
  • Secure File Storage & Sharing
  • Reporting, Alerts & SIEM
    • Event Descriptions
    • Splunk
    • Sumo Logic
    • Exabeam (LogRhythm)
    • Syslog
    • QRadar
    • Azure Monitor
    • Azure Sentinel
    • AWS S3 Bucket
    • Devo
    • Datadog
    • Logz.io
    • Elastic
    • Firewall Configuration
    • On-site Commander Push
  • Recommended Alerts
  • Webhooks
    • Slack Webhooks
    • Teams Webhooks
    • Amazon Chime Webhooks
    • Discord Webhooks
  • Compliance Reports
  • Vault Offline Access
  • Secrets Manager
  • Commander CLI
  • Keeper Connection Manager
  • KeeperPAM Privileged Access Manager
  • Keeper Forcefield
  • KeeperChat
  • Keeper MSP
    • Free Trial
    • Getting Started
    • Fundamentals
    • Consumption-Based Billing
      • Secure Add-Ons
      • Existing MSP Admins
    • Onboarding
    • PSA Billing Reconciliation
    • Join the Slack Channel
    • Next Steps
    • Offboarding
    • Commander CLI/SDK
    • Account Management APIs
    • Provision Family Plans via API
    • MSP Best Practices
  • Free Family License for Personal Use
    • Provision Family plans via API
    • Provision Student plans via API
    • API Troubleshooting
      • API Parameters
      • API Response Codes
      • API Explorer - Swagger
  • Keeper Security Benchmarks and Recommended Security Settings
  • IP Allow Keeper
  • Keeper Encryption and Security Model Details
  • Developer API / SDK Tools
  • On-Prem vs. Cloud
  • Authentication Flow V3
  • Migrating from LastPass
  • Training and Support
  • Keeper SCORM Files for LMS Modules
  • Docs Home
Powered by GitBook

Company

  • Keeper Home
  • About Us
  • Careers
  • Security

Support

  • Help Center
  • Contact Sales
  • System Status
  • Terms of Use

Solutions

  • Enterprise Password Management
  • Business Password Management
  • Privileged Access Management
  • Public Sector

Pricing

  • Business and Enterprise
  • Personal and Family
  • Student
  • Military and Medical

© 2025 Keeper Security, Inc.

On this page
  • Keeper Security Benchmarks
  • Shared Security Model
  • 1. Create at least two Keeper Administrators
  • 2. Enforce 2FA on the Keeper Administrator Role
  • 3. Ensure an Administrator Exists Outside of SSO
  • 4. Reduce Administrator Privilege
  • 5. Lock down your SSO Provider
  • 6. Disable Account Recovery When Appropriate
  • 7. Enforce a Strong Master Password
  • 8. Enforce Two-Factor Authentication for End-Users
  • 9. Configure IP Allowlisting
  • 10. Enable Account Transfer Policy When Necessary
  • 11. Create Alerts
  • 12. Prevent Installation of Untrusted Extensions
  • 13. Disable Built-in Browser Password Managers
  • 14. Deploy Across Your Entire Organization

Was this helpful?

Export as PDF

Keeper Security Benchmarks and Recommended Security Settings

Administrative recommendations for Keeper Security policies and settings

PreviousAPI Explorer - SwaggerNextIP Allow Keeper

Last updated 6 days ago

Was this helpful?

Keeper Security Benchmarks

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.

Shared Security Model

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.

1. Create at least two Keeper Administrators

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.

2. Enforce 2FA on the Keeper Administrator Role

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.

3. Ensure an Administrator Exists Outside of SSO

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.

4. Reduce Administrator Privilege

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.

5. Lock down your SSO Provider

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.

6. Disable Account Recovery When Appropriate

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.

7. Enforce a Strong Master Password

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.

8. Enforce Two-Factor Authentication for End-Users

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.

9. Configure IP Allowlisting

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.

10. Enable Account Transfer Policy When Necessary

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.

11. Create Alerts

12. Prevent Installation of Untrusted Extensions

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.

13. Disable Built-in Browser Password Managers

14. Deploy Across Your Entire Organization

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 .

Keeper Automator service
Special Publication 800-63B
master password complexity
Two-factor Authentication
Account Transfer Policy guide
created a list of recommended alerts
disabling built-in browser password managers
IP Allowlisting