Overview

Sharing Keeper records is a secure and powerful feature of the platform. Keeper offers various easy-to-use sharing capabilities with role-based enforcement policies to solve the most common use cases.

Types of Sharing

• Record and File Sharing - easily share a single record with another Keeper user and choose from various permission types to control access.

• Shared Folders - share multiple records in a folder to a specific set of users or Keeper Teams.

• PAM Resource Sharing - share access to a zero-trust privileged session without sharing access to credentials

• One-Time Share - provides time-limited secure sharing of a record to anyone, even if they don't have a Keeper account. This is a useful feature for sharing information with contractors or new employees during their onboarding process.

• Share Admin - role-based permission that gives administrators elevated access rights over your organization's shared folders and shared records.

• Time-Limited Access - securely share credentials or secrets with other Keeper users on a temporary basis, automatically revoking access at a specified time.

• Self-Destructing Records - One-time share records that automatically delete from both sides when shared and viewed.

Share a Record

A Keeper record can contain credentials, files, two-factor codes, or any type of content. Keeper records can be shared individually with other users. In the example below, the record contains a login/password, Passkey (for MFA), a file attachment and a two-factor code.

Click the Share button.

From the "Add People" tab, click within the email address field and search or type the email address of the Keeper user you would like to share the record with.

Click the dropdown arrow to set their permission level (can edit, share, edit & share, view only and transfer ownership) and click Add.

Sharing within an existing Keeper Enterprise tenant does not require any further steps. If you are sharing with a person outside of the tenant, you will first need to establish a "sharing relationship". The user will receive an email prompting them to login to Keeper and either accept or deny the share request. Once you establish a sharing relationship, the user will appear in the email dropdown list.

User Permissions

User Permissions are designed to control the permissions a user has over the record that is shared with them.

Administrative Controls

The use of record and file sharing can be restricted by the Keeper Administrator in the Roles section of the Keeper Admin Console.

Commander CLI

Record sharing commands are available from the Keeper Commander CLI tool. This provides advanced users with the ability to script and automate any sharing actions.

For more info, see: Commander Sharing Commands

• share-record

• record-permission

Overview

Keeper's Private Folder, Shared Folder and Subfolder capabilities are flexible and secure. Private Folders and Shared Folders can be created within the vault (if permitted by the Admin). Users and Teams may be provisioned automatically from Active Directory through the Keeper Bridge, or from SCIM-connected identity providers such as Azure, Okta and Google Workspace allowing for simple setup of shared folder permissions.

Private Folder

A private folder is only visible to the user who created the folder and can be made up of subfolders and records. A folder can also contain other shared folders and shared records. To create a private folder, click Create New > Folder. Choose where you would like to nest the folder using the dropdown menu. You can select the parent folder or select My Vault to add the folder at the root level.

Shared Folder

A shared folder can be shared with an individual Keeper user or with a Team of users (as designated in the Admin Console). Shared Folder permissions can be applied to Users, Teams and Records.

To create a Shared Folder, click Create New > Shared Folder. Choose where you would like to nest the folder using the dropdown menu. You can select the parent folder or select My Vault to add the folder at the root level. Next enter the name of the folder and set the User and Folder Permissions.

A Team can be setup in the Admin Console manually from Admin Panel and the Teams tab by clicking on the Add Team button and then selecting users via the + user checkbox dialogue.

Alternatively, when a user is provisioned to a Team through any of the previously described onboarding methods (Active Directory Bridge, SSO, Azure AD, SCIM, API, etc...), the user will instantly receive the shared folders for that team, and the records associated with those shared folders. When the user is removed from a team, their access is revoked from any shared folders and those folders are immediately removed from their vault.

Add Records & Set Record Permissions

You can add records to the folder by a simple drag-and-drop or you can click Edit and add the records using the record search bar.

Record Permissions are used to govern folder members' (users) interactions with each individual record in the folder. You can access these permissions from the Records Tab by clicking Edit and then the dropdown icon next to each record name.

Add Users & Set User Permissions

While in Edit mode, from the "Users" tab, click within the email address field and enter the email address of the Keeper user (including Share Admins) or Team you would like to share the folder with.

Next, set the user permissions by clicking on the dropdown arrow next to each user's email.

Subfolders

To create a Subfolder within a Shared Folder, right-click on a Shared Folder and select New Folder. You can add records to the folder by a simple drag-and-drop or you can click Edit and add the records using the record search bar.

While viewing the records within a Shared Folder, click the Edit Icon and check the box next to “Show subfolder records" located in the Records tab to include those records in view or leave it unchecked to collapse them from view.

Both private and shared folders can be nested and contain an unlimited number of records or subfolders. Each subfolder inherits the same permissions structure as the parent folder.

If the parent folder is a shared folder and you move a private folder into it, the private folder will now inherit the permissions set from the shared folder, including the users that have permission to view and edit that folder and its records.

In the screen capture below, the Region 1 folder is not shared but 1 of its 2 subfolders is shared (Monthly Sales Projections) as noted by the shared folder icon. Region 2 is a shared folder so all the records contained within its subfolders are also shared and they as noted in their shared record icons.

Default Shared Folder Settings

Default Shared Folder Settings are configured in order to easily set folder permissions for all users and records within the folder and subfolder(s). These are selected upon the initial creation of the Shared Folder but you can change them at any time by clicking the edit icon in the upper right corner of the shared folder.

Please note, newly created records inherit these permissions when adding users or records to the shared folder.

If you would also like to apply the permissions change to your subfolder records, you must first check the box next to "Show subfolder records" located within the "Records" tab.

Next, select the "Settings" tab and click each dropdown arrow to set your default "User" and "Record" permissions for the folder.

Optionally, check the box next to "Apply permissions to existing [x] records" to apply the changes to any existing folder records. You can also check the box next "Apply permissions to all subfolders ([x] records)".

Once the default folder settings are configured, it will only affect users added after the change was made. To edit permissions for the users added prior to the default settings change, edit them individually or through a bulk change from the "Users" tab.

A bulk change can be achieved by checking the box next to "Name" and clicking the "Permissions" dropdown to make your selection.

Notes for Managing Folders and Subfolders

A Folder and a Shared Folder are objects that are created independently of records. Keeper's implementation of Subfolders (Nested Folders) is powerful and flexible, providing Enterprise customers with the most secure encryption model while providing ease-of-use functionality such as drag-and-drop.

• A folder can be made up of private records, shared records or other regular subfolders.

• Subfolders can be either shared or private.

• You can create an unlimited number of folders and shared folders.

• A shared folder can be made up of an unlimited number of subfolders, each subfolder beneath a shared folder retains the permissions of the parent.

• There is no limit to the folder tree depth.

• A folder is a container of records and record references (shortcuts).

• A shared folder is a container of records, with flexible user and team sharing capability.

• Folders and subfolders contained within Shared Folders will inherit the permission of the Shared Folder.

Watch the video below to learn about creating shared folders and assigning permissions.

Bulk Record Permission Changes with Commander

Keeper Commander, our command-line SDK toolkit, provides a method of bulk record permission changes. Commander has special features that can be executed on the CLI instead of using the user interface. To download Keeper Commander binaries on Mac or PC please visit:

https://github.com/Keeper-Security/Commander/releases Or, to install the CLI in a developer mode, please follow the installation instructions in the documentation here:

https://github.com/Keeper-Security/Commander

Example: Elevate Permissions on All Records

In this example, we will recursively change the record permissions in a Shared Folder.

(1) Identify the Shared Folder UID on the Vault user interface, or from the Commander CLI.

On Commander, you can use the "ls -l" command, similar to a Bash shell.

On the Vault user interface, you can click on the info icon to display the Shared Folder UID.

(2) On Commander, execute the "record-permission" command with the "--dry-run" option to simulate the command. In this example, the Shared Folder UID is "-FHdesR_GSERHUwBg4vTXw". The command is below:

record-permission --dry-run --recursive --action grant --can-edit -- -FHdesR_GSERHUwBg4vTXw

As you can see, the Shared Folder UID starts with a dash so we add "--" before the identifier to escape the character.

Running this command produces the following output:

The "SKIP" section is saying that the current user on Commander cannot make those requested changes, because we are not the owner of the record. The "GRANT" section indicates the changes that will be allowed.

(3) To execute the command, we remove the "--dry-run" portion:

Now, on the Vault UI, the permission of those affected records has been changed to "Can Edit".

If you are in a situation with many record owners in the same shared folder that require update, each of those users can simply run the above Commander action to change the permissions of their respective records.

Share Admin

Keeper's Share Admin feature is a role-based permission that gives administrators elevated access rights over your organization's shared folders and shared records.

Learn more about Share Admin

Moving Records

A record can exist outside of a folder, inside a folder or inside a Shared Folder. A record can also be linked into multiple folders or Shared Folders. A linked record is also referred to as a Shortcut. In either case, modifying a linked record will change it everywhere it has a shortcut.

There are two ways to move a record into a folder:

• Drag-and-drop the record from the list of records and select Move when prompted

• Right-click on a record and select Move To...

Watch the video below to learn about adding records to shared folders.

Creating Record Shortcuts

Use one of the following methods to to add a record to multiple folders (create a Shortcut):

• Select the Folder and then select Edit. In the Add Records search box, search for the records to add and select Add. This method will always add a Shortcut to the folder.

• Drag-and-Drop the record from list of records and select Create Shortcut when prompted

• Right-click on a record from the list of records and select Create Shortcut...

Teams in Shared Folders

Teams are created by the Keeper Administrator, or any user who has been given administrative permissions for a specific node or organizational unit. A team is made up of users within a node or sub-node. Additionally, there is no limit to the number of teams that can be created. Teams can be provisioned using any of the following methods:

• Manual creation in the Keeper Admin Console

• Automatically provisioned through the Active Directory / LDAP Bridge software

• Automatically provisioned through SCIM

• Automatically provisioned through the Keeper Commander SDK

At the encryption layer, Teams have a public and private key pair. In order to add a user to a team, you must first be a member of the team because you need to encrypt the Team Key with the recipient's public key. When the recipient logs into their vault, the Team Key is retrieved by decrypting it with the user's private key. This encryption process is automatically handled by the provisioning methods listed above.

Team Level Restrictions

Inside the Admin Console there are several team security options. Teams that are added to a shared folder can be given limited rights:

• Disable record re-shares

• Disable record edits

• Apply privacy screen

Deleting & Leaving Shared Folders

A user with access to a Shared Folder has the option to remove themselves from the Shared Folder. If the user has been granted the Can Manage Users & Records permission, the user also has the ability to delete the Shared Folder.

Changing Colors of Folders

Users can change the color of a shared folder in order to make is stand out visually. This can be done on both Shared Folders and Private Folders.

Administrative Controls

The use of shared folders can be restricted by the Keeper Administrator in the Roles section of the Keeper Admin Console.

Managing PAM Resources with Sharing

Overview

Keeper Vault uses Shared Folders as the access control mechanism for all KeeperPAM-managed resources. These PAM resources can be organized within shared folders in the same way as standard Keeper records.

A significant advantage of the KeeperPAM architecture is that it enables resource access sharing without revealing the actual credentials to users. This zero-knowledge approach maintains security while providing necessary access.

Types of PAM Resources

Shared Folders can contain various types of PAM resources:

• PAM Machine - For server and endpoint connections

• PAM Database - For database system access

• PAM Directory - For directory service management

• PAM Remote Browser - For secure web application access

• PAM User - For service credential management

The share receipient can then initiate a zero-trust privileged session to the target system, without having access to the underlying credentials.

Implementing Least Privilege

For optimal security through least privilege principles, we suggest maintaining PAM Users in a dedicated shared folder separate from other resources. This separation helps limit access to sensitive underlying credentials.

The recommended configuration includes:

1. A shared folder for infrastructure components (Machines, Databases, etc.)

2. A separate shared folder specifically for PAM User credentials

When you utilize Keeper's Quick Start Sandbox or Gateway wizard, this separation happens automatically, establishing the recommended security structure from the beginning.

Security Benefits

This organizational approach provides several advantages:

• Credentials remain protected even when resource access is shared

• Administration is streamlined through the familiar Keeper interface

• Access permissions can be precisely configured at the folder level

• Complete audit trails track all resource access activity

• The system integrates seamlessly with existing Keeper workflows

For more information:

• KeeperPAM Overview

• KeeperPAM Sharing and Access Control

Overview

Keeper "One-Time Share" provides time-limited secure sharing of a record to anyone without having to create a Keeper account. One-Time Share is the most secure way to send confidential information to an external person or contractor without exposing information over email, text message or messaging.

One-Time Shares are secure by design, utilizing Keeper's Zero-Knowledge encryption. The record data is decrypted locally on the recipient's device using 256-bit AES and all requests to the server are signed with elliptic-curve cryptography (ECDSA).

How to Share

To create a One-Time Share, open a Keeper record and click on the Edit Icon > One-Time Share.

Select how long the share link should be valid. The record will expire at a time of your choosing, and it can only be viewed on one device. Even if you forget to un-share the record, it will expire and access will be revoked.

Share links will expire after the selected amount of time, if the link is never used. If the link is used and bound to a device, the record access will expire after the same amount of time.

You can either copy the Link only, the Invitation to share the record with another person, or simply scan the QR code.

When the recipient opens the link, the record will render in the device browser.

As an additional layer of security, One-Time Shares are device-locked which means that only the original recipient is able to access the data. If the link is later opened up by a third party, or your email account is compromised, the link cannot be accessed, except on the original device.

Use Cases

• Share access credentials with a contractor

• Share an encrypted file with a co-worker

• Provide secure documentation or instructions

Delivery of One-Time Shares

One-Time Share links can be sent to recipients through any trusted channel, such as:

• Direct QR Code Scan

• Airdrop

• Email

• SMS

• Enterprise messaging platforms

• Any other out-of-band channel

The applications and uses for this are virtually endless. Any time you have a need to securely deliver data to a non-Keeper user, One-Time Shares are the perfect choice.

Activating One-Time Share

For existing Enterprise customers, One-Time Share is disabled on all default role policies.

To allow this feature on your existing default role policies, visit the Role > Enforcement Policies > Creating and Sharing.

For all new role policies created after the launch of the One-Time Share feature, it is enabled by default.

Bidirectional Sharing

Keeper's upgraded One-Time Share feature enables two-way sharing between Keeper users and non-users, providing a secure way of exchanging confidential information and files.

Bidirectional one-time sharing encourages seamless collaboration with the ability to collect signed documents, feedback or sensitive files and information from clients, contractors, legal times and anyone else without requiring them to create a Keeper account.

To utilize the bidirectional one-time sharing feature, begin by creating a one-time share as you normally would. Within the selected record, click Share > One-Time Share > Create a One-Time Share.

To enable the bidirectional sharing capabilities for the record, check the box next to "Allow recipient to edit record fields and upload files". Use the dropdown menu to select when you would like the share to expire and click Create Link.

Once the recipient receives the secure share link, they can then Click to Open to view the contents of the shared record.

The recipient can upload file attachments and enter any other requested information or notes.

Once the recipient clicks Save, the original record will automatically update within the sender's vault with the added files/information. The sender and recipient can continue to edit the record until the share link expires or once access is revoked.

One-Time Share With Keeper Commander

Create One-Time Share links programmatically using the Keeper Commander CLI tool. Relevant commands:

• share

• share-record

Commander offers additional controls such as fine-grained expiration times, additional output methods, and the ability to remove previously created One-Time Shares.

For more information see our Keeper Commander Documentation.

Security and Encryption Model

The encryption model implemented for one-time sharing uses the same technology as Keeper Secrets Manager, a zero-knowledge and zero-trust platform for protecting cloud infrastructure.

The security model and method of encryption is detailed below:

(1) In the vault, the sharer generates a one-time access token by clicking on "One-Time Share" in the record options screen. The 256-bit AES Record Key for the record being shared is encrypted with the one-time access token, and this encrypted value is stored in the Keeper Cloud.

(2) The sharer sends the One-Time Access Token to a recipient via a simple URL or QR code through their preferred channel. The URL portion that contains the access token is held within the "fragment identifier" section of the URL which is never sent over the network to Keeper's servers. Therefore, zero-knowledge is retained and Keeper has no ability to access or decrypt the information.

(3) The recipient opens the URL on their device browser, and a single-page Vault application is loaded on the device. The One-Time Access Token is handed off directly to the local vault application (not sent to the server).

(4) Upon loading the URL, the recipient's device generates a client-side public/private Elliptic Curve key pair, and the private key is stored locally on the Client Device in the browser's CryptoKey storage.

(5) Upon first use, the SDK library authenticates using the hash of the One Time Access Token and upon successful authentication, the server responds with the encrypted record ciphertext plus the Encrypted Record Key.

(6) The Client decrypts the Record Key with the One Time Access Token, and the record contents are decrypted using the Record Key. The Record Key is then stored locally on the client device in the browser's CryptoKey storage or other designated storage location.

(7) On the server, the encrypted record key for that given device is deleted so that the One Time Access Token cannot be used again. After that, the client's requests must be signed with the Client Private Key.

(8) Subsequent calls on the same device to the server are sent with an identifier which uniquely defines the device (hash of the one-time access token) and a request body that is signed with the Client Private Key. The server checks the ECDSA signature of the request for the given device identifier using the Client Public Key of the device. The Keeper Cloud processes the request for the record, and the server returns encrypted record ciphertext to the Client upon successful authentication.

(9) In addition to the record-level encryption, the Client Device creates a randomly generated AES-256 bit Transmission Key which is encrypted with the public key of the Keeper cloud API. The Client Device decrypts the response from the server with the Transmission Key and then decrypts the ciphertext response payload with the Record Key, which decrypts the contents of the record.

Additional details about Keeper's encryption model is documented here.

Administrative Controls

The use of One-Time Sharing can be restricted by the Keeper Administrator in the Roles section of the Keeper Admin Console.

Overview

Keeper's Share Admin feature is a role-based permission that gives administrators elevated access rights over your organization's shared folders and shared records.

Share Admins have full user and record privileges for any shared record that they have access to.

How it Works

• From the Admin Console, assign a role with Share Admin privilege

• From the Vault, add the Share Admin user to the folder or record

• The Share Admin will immediately have full access rights on their Shared Folders

Restrictions

(1) The Share Admin can only take effect on Shared Folders that are owner/created by users within the Enterprise.

(2) The Share Admin can only take effect on Shared Folders that are owner/created by users within nodes under management by the Share Admin

(3) These restrictions are useful when you have Share Administrators that are managing just an organizational unit (or Node) and not the entire company.

(4) The Share Admin user must be added to folders they wish to manage. Anyone with "Can Manage Users" can add the Share Admin to the designated shared folder or record.

Share Admin Features

• Add or remove records and users from shared folders

• Change folder default permissions

• Modify record permissions

• Transfer record ownership to other users

• Delete shared folders

Create a Share Admin

In support of least-privileged access, Share Administrator permissions are granted via Role-Based Enforcement Policies. This provides the ability to grant Share Administrator rights to a limited group of administrators and provide elevated access rights to your organizations shared records and folders.

To assign someone in your organization Share Admin permissions, first create a role or select an existing role. Under administrative permissions click on the gear icon to display the list of permissions and select “Share Admin”.

Creating a Share Admin from the CLI

In Keeper Commander, you can also run this command on the CLI:

enterprise-role "Role Name or ID" --node="Node Name or ID" --add-privilege=sharing_administrator

To learn more about Keeper Commander visit: https://docs.keeper.io/secrets-manager/commander-cli/overview

Managing Share Admins in the Vault

Shared Folders

While in edit mode for the shared folder, select the Users tab then click within the user search bar. Your organization’s available Share Admins will appear at the top of the list. Select the share admin(s) you would like to invite to the folder and click Add.

Individual Records

Share Admins can also be added directly to an individual record through the Share Record screen.

Once a shared record or folder is shared with the Share Administrator, they will immediately be granted full permissions over the Shared Folders or Records.

Share Admin Features

From the vault, a user with Share Admin permission for a shared folder is able to view all shared folder content, change shared folder default permissions, add or remove records and users, and delete the shared folder. The Share Admin can change record permissions for those records owned by users managed by the Share Admin. Changing record permissions includes editing, sharing, or transferring ownership.

Viewing Share Admin Info

Users can view who has Share Admin permissions over a folder by clicking on the Folder Information icon.

Add & Remove Users or Records

Share Admins can add or remove users and records from Shared Folders, no matter who owns the record.

Change Record Permissions

Share Admins can change record permissions of any record within a Shared Folder or a direct share.

Change Shared Folder Default Folder Settings

Share Admins can change the Default Folder Settings of any Shared Folder.

Delete Shared Folders

Share Admins can delete Shared Folders or Shared Records.

Transfer Record Ownership

Share Admins have full record edit permissions including the right to transfer ownership of single or multiple records at once. To transfer ownership of multiple records, select the records, then right-click to reveal the context menu and select transfer ownership.

Enter the new owner’s email address or select it from the dropdown and click the transfer ownership button.

The transfer is verified if successful, if not, you will receive a notification of any records that are unable to be transferred. Share Admins can also perform a transfer of ownership of a single record directly from the record’s “Options” menu.

Working with the Commander CLI

Share Admins can use the Commander CLI for making changes to Shared Folders and Shared Records. For example:

• Record Commands such as edit

• Sharing Commands such as share-record, record-permissions and share-folder

To learn more about Keeper Commander visit: https://docs.keeper.io/secrets-manager/commander-cli/overview

Compliance Reports

Share Admins will show up in the Compliance Reports interface as seen below:

Use Cases

Some use cases for Share Admin include:

• Simplifies the process of editing record permissions when there are multiple users who contribute to a Shared Folder with mixed permission settings

• Shared Folders that were created with unintentionally restrictive settings can be updated easily

• Shared folder contains records that need to be moved to another shared folder

• Records need to be transferred without having to completely transfer an entire vault

• Temporarily elevate rights to make folder permission and record changes

FAQs

How do I view the Share Admins for a shared folder in my vault?

Click the “Info” icon to reveal the shared folder detail panel. Share Admins are listed in the information dialog.

As a shared folder participant, how do I know who the “Share Admins” are for the organization so that I can invite them to participate in my shared folder?

While in edit mode for the shared folder, select the “Users” tab and “Add” users button. The organization’s available Share Admins will appear at the top of the list.

What happens to a consumer’s shared folder with owned records, if the consumer shares the folder with an enterprise user who is a Share Administrator, and the records in the shared folder have “read only” access?

The Share Admin does not manage the consumer, which means that the Share Admin cannot change record permissions and would have “read only” access to the records owned by the consumer. However, the Share Admin can manage the shared folder, users and records in the shared folder. These permissions allow the Share Admin to remove or invite users to the shared folder, change default folder permissions, or even delete the shared folder.

Given this scenario: A consumer has a shared folder with owned records and the consumer shares the folder to two users of the same enterprise with Manage Record permissions, where one of them is a Share Administrator. The non-share administrator adds a record to the folder. Can the Share Administrator manage users for this folder in this scenario since they can manage user access for records of managed record owners?

Yes. The Share Admin can manage (add/remove) any record or user from the shared folder. Additionally, if the non-share admin is associated with a node managed by the share administrator, the share administrator can change record permissions for those records owned by the administrator that does not have share admin permission.

What happens if a shared folder is shared between two businesses and there are shared folder administrators participating in the shared folder from both businesses.

The Share Admin can edit the default shared folder permissions, add/remove users and records from the shared folder, and edit record permissions for records that are owned by their managed users. If a record is removed from the shared folder, and it is the last reference to that record, it is moved to the record owner’s trash bin.

Are Share Admin permissions shown in Compliance Reports?

Yes. If a user has Share Admin access to records in a Compliance Report, this is shown in the report.

Can a Share Admin be removed from the Share Admin role and/or removed from a shared folder? If so, what happens to their permissions?

A Keeper Administrator can be temporarily assigned to a role with Share Admin permission. When they are removed from this role, their permissions to shared folders and records will revert to their previous shared folder permissions. A Share Admin can be removed from a Shared Folder by any participant that has “manage users” permission.

Will Share Admin permission be turned "on" by default for the Keeper Administrator role?

Yes. This permission is automatically turned on for the default Keeper Administrator role.

Overview

Time-Limited Access allows you to securely share credentials, secrets or PAM Resources like machines, databases and directories - with other Keeper users on a temporary basis, automatically revoking access at a specified time. Time-Limited Access prevents long standing privileges and ensures that information is removed from the recipient’s vault, greatly reducing the risk of unauthorized access.

Key Benefits

• Revoked access at a specified time designated by the record owner, minimizing the workload on the owner to remove the share at a later time.

• Enhances security as traditional short term sharing has been done in insecure ways like using sticky notes, text messages or instant messengers.

• Simplified compliance with event tracking on all sharing activity, ensuring least privilege access is maintained.

• When paired with KeeperPAM or Keeper Secrets Manager (KSM) automatic service account rotation capabilities, users can schedule rotation of the shared credential upon the expiration of access, ensuring the recipient never has standing privilege

Share a Record

Select the record from your vault and click Share, entering their email address or selecting it from your contacts list. Set their permission level and click Add.

Select the “Permissions” dropdown and click Set Expiration. Here you can select one of the default expirations or click custom date and time to set your own. Next, check the box if you would like the record owner, such as yourself, or users with edit access to be notified via email when the recipient's record access expires. Click Done to save.

Share a Folder

Open the shared folder from your vault and click the edit icon and from the “Users” tab, add the user or team you would like to share the folder with.

Set their permissions and from the dropdown menu click Set Expiration, following the same steps you would for a single record share (described above).

Next, check the box if you would like users with "can manage records" permissions over the folder to be notified via email when the recipient's record access expires. Click Done to save.

Sharing PAM Resources

When sharing access to PAM Resources (such as a Windows or Linux server), privileged sessions can be established to the target resource, without access to the credentials. When access is revoked, the session is terminated and session logs are created for the administrator.

For more information about PAM sessions and permissions, see the KeeperPAM documentation.

Overview

Self-Destructing Records utilize Keeper’s existing One-Time Share technology which allows time-limited, secure sharing of a record to anyone, even if they don’t have a Keeper account.

Self-Destructing Records take our One-Time Share feature even further by automatically deleting the record from your vault once the share link is disabled and the recipient’s access is revoked. This reduces your workload to revoke record access and removing it from your vault at a later time.

Key Benefits

• Providing the most secure, encrypted method to send sensitive information to users outside of your organization without exposing sensitive information in plain text over email, text message or messaging.

• Avoids the accumulation of unnecessary privileges within an organization over time.

• Assurance that the details of a shared record remain with the recipient, on a single device.

Create a Self-Destructing Record

To create a Self-Destructing Record, create a new record as you normally would. Enter the record details and click Add Self-Destruct.

From the menu that is now presented, select when you want the share link to expire.

Once you've made your selection, click Save & Share to generate a One-Time Share link.

You have the option to copy the link directly, or send it in an invite or QR code format.

The recipient of a Self-Destructing Record simply clicks on the provided link and is instantly presented with the shared record in their web browser. One-Time Share links are bound to a single device, further strengthening security and preventing unauthorized distribution or viewing on multiple devices. The link will expire at the specified time or once the recipient has viewed the record for five minutes, whichever comes first.

Securely Share Files Using Self-Destruct

Keeper's Self-Destructing Records allow you to securely share records with file attachments that self-destruct at a specified time.

Create a record as you normally would and click Add Attachments to upload your file, or simply drag and drop the file directly into your vault.

Click Add Self-Destruct, select when you want the share link to expire, then click Save & Share to generate a One-Time Share link.

The recipient of a Self-Destructing Record simply clicks on the provided link and is instantly presented with the shared record in their web browser. They can then click on the file to download it to their local device.

Delete a Self-Destructing Record

You can delete a Self-Destructing Record at any time, thus disabling the share link by clicking Delete Now. Deleted Self-Destructing Records will appear in your vault's “Deleted Items” with the option to "Restore".

Overview

In many enterprise environments, it’s essential to hide passwords from end-users to maintain security and enforce access policies. This is especially relevant for access to web applications, cloud services, internal tools, and infrastructure. Keeper offers multiple methods to prevent users from viewing passwords while still enabling seamless access:

• Privacy Screen

• KeeperPAM Connections

• Remote Browser Isolation

Privacy Screen

The Privacy Screen feature of Keeper is a front-end method of hiding a password from viewing within the Keeper vault, browser extension and mobile apps. Privacy Screen can be applied at the team level, role policy level (based on specific record domains), and at the record type (template) level.

With this policy in place, passwords are not visible from the user interface serving as a deterrent from casual observation. This feature is commonly used to limit viewing of passwords for the non-technically savvy users.

Team Level

In the Keeper Admin Console, the Team resource provides additional restrictions. The "Enable Privacy Screen" restriction is applied to any shared folder which the team has been added. Below is a screenshot of the "Client Services" team which has privacy screen enabled.

Role Level

At the role policy level, the Privacy Screen enforcement policy is used in conjunction with the Generated Password Complexity policy to control the viewing (unmasking) of passwords based on a specified domain.

This feature can be enabled within the Generated Password Complexity settings by checking the “Apply Privacy Screen” box once a domain has been added.

Record Type Level

At the custom record type level, the Privacy Screen feature can be activated on the password field. For more information on record types, see this page.

Vault Treatment

From the Vault shared folder, any user or team with Privacy Screen activated can be added to a shared folder:

On the recipient side, any record with a matching URL will be locked, and the user cannot unmask to view the password.

Browser Extension

On the browser extension, the password cannot be viewed:

KeeperPAM Connections

Keeper Connections allow users to instantly and securely access assets within their target infrastructure, such as servers, databases, web apps and workloads directly from their Keeper Vault. Connections can be established without exposing the underlying credentials to the user, ensuring zero-trust and zero-knowledge access.

There are several use cases which support password hiding:

• RDP Sessions

• SSH Sessions

• Database Sessions

To learn more about KeeperPAM Connections, see the below links:

• KeeperPAM Overview

• Connections

• Website page

Self-Hosted Connection Manager

Keeper Connection Manager (KCM) is a self-hosted, agentless remote desktop gateway that provides instant and secure access to desktops, servers, databases and web applications from a web browser. Sessions created through Keeper Connection Manager provide a passwordless experience for users across any protocol, including:

• RDP, SSH, VNC, K8s

• MySQL, PostgreSQL, SQL Server

• Web Applications through Remote Browser Isolation

To learn more about Keeper Connection Manager:

• Documentation

• Connection Manager web page

Remote Browser Isolation

Keeper’s Remote Browser Isolation (RBI) enables passwordless access to web-based applications by visually projecting secure browsing sessions from the Keeper Gateway directly into the user's vault. These sessions run in an up-to-date Chromium browser within a virtualized container, completely isolated from the local environment. With this approach, passwords are hidden from the end-user—credentials are securely injected via autofill, preventing exposure while still enabling seamless access. This protects users from malware, phishing, and other web-based threats, and eliminates the need for VPNs.

Remote Browser Isolation is an available connection protocol in the KeeperPAM cloud platform, and standalone Keeper Connection Manager.

To learn more about Remote Browser Isolation:

• KeeperPAM RBI

• Keeper Connection Manager RBI