Introduction

Once the Encryption at Rest (EAR) architecture has been understood and the appropriate deployment scenario has been identified, administrators can begin working with Encryption at Rest key management operations.

This guide explains how to create, import, export, validate, activate, and manage encryption keys throughout their lifecycle. In addition, it describes how to migrate existing encrypted data to the Encryption at Rest framework and how to verify the successful completion of key management and migration activities.

Whether Encryption at Rest is being enabled for the first time following an upgrade, deployed in a newly installed environment, or integrated with organization-supplied key material, the procedures in this guide provide the operational steps required to manage Encryption at Rest securely and consistently.

Working with Encryption at rest 

All Encryption at Rest (EAR) administration tasks are performed through the Endpoint Data Protection Administrative Tool (AdminTool). The AdminTool provides command-line operations for managing the complete EAR lifecycle, including key creation, import and export operations, key rotation, key revocation, backup and recovery procedures, and migration of existing encrypted data. Before working with Encryption at Rest, it is recommended to become familiar with the general usage and syntax of the AdminTool. For additional information about the tool itself, refer to the AdminTool Command Line documentation.

Requirements

• An elevated command prompt (Run as administrator) on the Server machine.
• AdminTool.exe, located in the Server installation folder.
• The Server service running on that machine.
• The database reachable from that machine.
• The Server registered in the database. A Server registers itself when its service connects to the database; one that has never connected successfully cannot run any of these commands.

Before you start

• Before enabling or modifying Encryption at Rest, administrators should familiarize themselves with the concepts, architecture, and operational procedures described in this guide. Encryption at Rest introduces key lifecycle management processes such as key creation, backup, recovery, rotation, and server onboarding. Understanding these concepts beforehand helps reduce the risk of configuration errors and ensures that recovery procedures are available when needed.
• In addition, organizations should establish an appropriate backup and recovery strategy before placing Encryption at Rest into production use. Encryption keys, key backup files, associated passwords, and database backups all play a critical role in recovery scenarios. Loss of required key material will prevent access to encrypted data and could impact disaster recovery operations.
• In newly deployed environments, the first Endpoint Data Protection server that registers against a new database automatically initializes the Encryption at Rest infrastructure and generates the initial encryption key. Additional servers joining the deployment do not automatically create their own keys and must instead use the existing Encryption at Rest key set.

Operational Best Practices

• Export and verify every newly created key.
• Store backup files and passwords separately.
• Keep backups of all keys, including revoked keys.
• Run List Keys before and after every key operation.
• Create a database backup before running a migration.
• Clear command history after handling sensitive key material. Encryption keys, passwords, or hexadecimal key values entered on the command line may be retained in command history or administrative log

Run the AdminTool and Review Commands

The following sections provide an overview of the available Encryption at Rest commands and explain their purpose before demonstrating common administration and maintenance procedures. To run the AdminTool, perform the following:

• Run cmd as administrator.
• Define the path to the AdminTool.exe. By default, the following path is used: C:\Program Files\EgoSecure\EgoSecure Server\

cd "C:\Program Files\EgoSecure\EgoSecure Server\"

• Press Enter.
• Type the following command to review all available commands:

AdminTool.exe/?

• Scroll down and locate the [Encryption at Rest] section and review the new items and their explanation:

Parameters 

Verify Existing Key

Before performing any Encryption at Rest administration tasks, the current key configuration should be reviewed. Type the following command to List every key held by every Server, and any Server missing the key in use:

AdminTool.exe /encryptionAtRestListKeys

Review the Results

Sample output for a single server deployment with no available keys:

CMD: List encryption at rest keys

No encryption at rest keys found.
==========================================================
1 of 1 commands proceeded successfully

Sample output for a healthy two-Server deployment with a key rotated. Identifiers and timestamps will differ:

CMD: List encryption at rest keys

Server: 3f2b8c14-7d5a-4e91-b0c6-2a8e5f1d94b7 (SRV-EDP-01) [THIS SERVER]
  ALGORITHM  DEFAULT  REVOKED  THUMBPRINT-SHA256                                                 TIMESTAMP
  -----------------------------------------------------------------------------------------------------------------------
  AES-256    no       YES      4e7b1f90c28d5a3607e9b4d1c85f2a6309be7d4a15c80f236ba9e5d7c41f8203  2026-03-04T09:12:44.180Z
  AES-256    no       no       9a41c7e0b32d8f14a6e5c09b7d2f4813e6a0c5d9b8f37241ae0d6c39b5f82714  2026-09-17T10:04:22.417Z
  AES-256    YES      no       c58e0d3a91b74f26d0a8e35c7b91f04d28a6c1e5b93f7204ad1c8e6b35f90d82  2026-10-02T14:22:07.318Z

Server: b6d09e52-1c84-47af-9e30-5b7c2f8a01d3 (SRV-EDP-02)
  ALGORITHM  DEFAULT  REVOKED  THUMBPRINT-SHA256                                                 TIMESTAMP
  -----------------------------------------------------------------------------------------------------------------------
  AES-256    no       YES      4e7b1f90c28d5a3607e9b4d1c85f2a6309be7d4a15c80f236ba9e5d7c41f8203  2026-03-04T09:38:51.602Z
  AES-256    no       no       9a41c7e0b32d8f14a6e5c09b7d2f4813e6a0c5d9b8f37241ae0d6c39b5f82714  2026-09-17T10:31:58.902Z
  AES-256    YES      no       c58e0d3a91b74f26d0a8e35c7b91f04d28a6c1e5b93f7204ad1c8e6b35f90d82  2026-10-02T14:49:16.774Z

Understanding the Key Store

Encryption at Rest keys are managed through a dedicated key store that is maintained by Endpoint Data Protection on each server.

Key Store Location

The local key store is located under:

%ProgramData%\EgoSecure\KeyRing\<DatabaseGUID>.json

Each Endpoint Data Protection server maintains its own key store file. The filename contains the database identifier, ensuring that keys are associated with the correct Endpoint Data Protection database.

Key Store Protection

The key store is protected by several security mechanisms:

• Access to the file is restricted to the account running the Endpoint Data Protection Server service.
• Stored key material is protected by the operating system and can only be decrypted on the server where it was created or imported.
• Copying the file to another machine does not provide access to the contained encryption keys.
• The key store is preserved during upgrades, repairs, and reinstallation of Endpoint Data Protection.

Checking the Current State

Depending on the deployment history, the key store file may already exist even when no Encryption at Rest keys are configured. For example, after upgrading to Endpoint Data Protection 26.2, administrators may discover a key store file within the KeyRing directory while the /encryptionAtRestListKeys command reports:

CMD: List encryption at rest keys

No encryption at rest keys found.
==========================================================
1 of 1 commands proceeded successfully

This behavior indicates that the Encryption at Rest infrastructure has been initialized and the key store location is available. However, no active Encryption at Rest key has been created or imported yet.

Add a key to a Server

Before Encryption at Rest can be used, at least one encryption key must be available in the server's local key store. Adding a key to the key store is the starting point for most Encryption at Rest administration tasks. Whether you are enabling Encryption at Rest for the first time, changing the key used for new encryption operations, restoring a previously exported key, or joining an additional server to an existing environment, the process always begins by placing the required key into the local key store.

It is important to understand that a key stored in the key store is not automatically used for encryption. A newly added key is available to the server and can be used to decrypt data that was previously encrypted with that key, but it will not be used for new encryption operations until it has been designated as the default key. This separation between storing a key and activating a key provides administrators with greater flexibility when managing encryption key lifecycles. Multiple keys can coexist within the key store, allowing organizations to perform key rotation, migrations, server onboarding, and recovery operations without disrupting access to existing encrypted data.

Available Options

Encryption at Rest keys can be added to a server using one of the following methods:

• Create a new custom key: Endpoint Data Protection generates a new AES-256 encryption key and stores it in the local key store. At the same time, a password-protected backup file is created. This is the recommended approach when enabling Encryption at Rest for the first time.
• Use Organization-Supplied Key Material: Organizations that maintain their own key management processes can provide their own Encryption at Rest 256-bit AES key material instead of generating a new random key. The key can then be imported into the local key store and managed through the standard Encryption at Rest lifecycle.

Regardless of how a key is added, it will only become active for new encryption operations after it has been designated as the default key.

Create and backup new custom key

Before creating a new Encryption at Rest key, ensure that:

• The Server service is running.
• A valid destination path for the key backup file is available. The command will not overwrite an existing file, therefore a new file name must be specified.
• A strong password has been selected to protect the backup file. Store the password securely and separately from the backup file itself.

To create a new random key, adjust the backup file path and password as required, then execute the following command:

AdminTool.exe /encryptionAtRestCreateKey /encryptionAtRestFile D:\keybackup\edp-key-2026-09-17.json /encryptionAtRestPassword <password>

Review the creation process

Once you executed the create key operation, the output should look like this:

Securely Store the Key Material

When a new Encryption at Rest key is created, three pieces of information should be retained and stored securely: the key thumbprint, the exported key backup file, and the encryption at rest password. Together, these elements allow administrators to identify, validate, and recover Encryption at Rest keys throughout their lifecycle. The key thumbprint serves as the unique identifier of the key and is used throughout Encryption at Rest administration tasks, including key activation, rotation, validation, and troubleshooting. It is also used internally to associate encrypted data with the key that was used to protect it.

The exported key backup file and its password are required to restore the key onto another server or recover it following a server migration or disaster recovery scenario. Both should be retained according to your organization's security and backup policies.

1. Record the Key Thumbprint (SHA-256), for example b60dc82f2c96064020cc8f0bd82a24f5821c966e57c60a3bf6cac994e6ecb1b5 . 
2. Move the file edp-key-2026-09-17.json to secure storage, separate from the Server machine. 
3. Record the Encryption At Rest Password in your organization's password store.

The password is given on the command line, where it may be visible to other users of the machine and may be recorded in the command history. Clear the history afterwards, or use a session whose history is not retained.

Using Organization-Supplied Key Material

In addition to creating Encryption at Rest keys directly within Endpoint Data Protection, organizations can provide their own cryptographic key material for use within the EAR framework. This approach allows organizations to generate and manage encryption keys outside of Endpoint Data Protection and import them into the platform when required. Unlike exported key backups, organization-supplied key material is provided directly as a hexadecimal value and does not require an intermediate backup file. This method may be appropriate when:

• Organizational security policies require externally generated keys.
• Key generation is handled by a dedicated security team.
• Cryptographic material must be shared across multiple servers without first creating a backup file.
• Customer-managed key material is required for compliance or governance purposes.

Before You Start

Before importing externally generated key material:

• The Endpoint Data Protection Server service must be running.
• The key value must be provided as a hexadecimal value.
• A 256-bit AES key requires exactly 64 hexadecimal characters.

Important: The key value is entered directly on the command line. Depending on the operating system configuration, the value may be visible to other users or recorded in shell history. Consider clearing command history afterwards or using a session that does not retain history. 

Importing the Key

Execute:

AdminTool.exe /encryptionAtRestImportKey /encryptionAtRestKeyHex <64 hexadecimal characters>

Verify the Result

The output should look like this:

CMD: Import encryption at rest key
ThumbprintSHA256: 9a41c7e0b32d8f14a6e5c09b7d2f4813e6a0c5d9b8f37241ae0d6c39b5f82714

Important Considerations

• Only import AES-256 compatible key material.
• When using organization-supplied key material in a multi-server environment, the same hexadecimal value must be imported onto every server that should hold the key. The same key value will produce the same thumbprint on every server.
• Because the key material is provided directly, no export or backup file is required to distribute the key between servers. 
• Review the Key Store and verify that the resulting algorithm is reported as AES-256.
• Record the generated thumbprint after import.
• Store the original key material according to your organization's security policies.

Review Key Store

After successfully creating the new custom Encryption at Rest key or importing your Organization-Supplied Key Material, execute the key listing command again to verify the result. 

AdminTool.exe /encryptionAtRestListKeys

The newly created key with your recorded thumbprint with AES-256 Algorithm should now appear in the list and be marked as not default and not revoked. 

Import and Export of Backups

Encryption at Rest keys can be exported and imported to support backup, disaster recovery, server migration, and multi-server deployments. Exporting a key creates a password-protected backup file that can later be imported on another Endpoint Data Protection server connected to the same database. Importing a key makes the key available within the local key store but does not automatically activate it for new encryption operations.

Backup Validation and Key Import

As a best practice, validate every newly created or exported Encryption at Rest key backup file before relying on it for server migration, disaster recovery, or recovery operations. Backup validation confirms that the export file can be read successfully, that the password is correct, and that the contained key can be identified by the import mechanism.

When validating a backup on the same server where the key already exists, the import operation is expected to report that the key is already present. This confirms that:

• the backup file can be read,
• the backup password is correct,
• the key can be identified successfully,
• the backup is suitable for future recovery operations.

To verify or import a backup, adjust and execute the following command:

AdminTool.exe /encryptionAtRestImportKey /encryptionAtRestFile D:\keybackup\edp-key-2026-09-17.json /encryptionAtRestPassword <password>

If you have stored the file on a remote location, adjust and run the following command:

AdminTool.exe /encryptionAtRestImportKey /encryptionAtRestFile "\\fs01\Company Share\EgoSecure\Backup\edp-key-2026-09-17.json" /encryptionAtRestPassword <password>

Importing a key makes the key available within the local key store but does not automatically activate it for new encryption operations. Encryption at Rest key backups can only be imported into servers connected to the same Endpoint Data Protection database from which the backup was originally created.

Backup and Export Key

Exporting a key creates an encrypted backup file. The exported file can be viewed using a text editor, but the contained key material remains encrypted and can only be restored using the password specified during export.

Overview

Key exports are commonly used for:

• Creating backup copies of Encryption at Rest keys
• Preparing a key for import onto another server
• Disaster recovery planning
• Server migration scenarios

 The exported backup is stored as a JSON document and can be opened using a text editor. 

However, the Encryption at Rest key itself is not stored in plain text. The file contains encrypted key material together with the cryptographic information required to restore it later. Both the backup file and the associated password are required to successfully import the key.

Execute Backup

Exporting a key does not modify the key stored in the local key store and does not affect active encryption operations. The export process only creates an encrypted backup copy of the selected key. To create a backup, adjust and execute the following command:

AdminTool.exe /encryptionAtRestExportKey /encryptionAtRestThumbprint <thumbprint> /encryptionAtRestFile D:\keybackup\edp-key-
2026-09-17.json /encryptionAtRestPassword <password>

After Exporting the Key

Once the key has been exported successfully:

• Review the generated backup file and verify that it was created successfully.
• Securely store the key thumbprint, backup file, and backup password as described in Securely Store the Key Material.
• Validate the backup by following the Importing a Backup procedure before relying on it for server migration, disaster recovery, or recovery scenarios.
• Historical and revoked keys should also be backed up. Previously encrypted data or historical database backups may still depend on those keys.

Making a Key the Default Key

Making a key the default key activates it for new encryption operations. This procedure is required when enabling Encryption at Rest for the first time, during key rotation, and when bringing additional servers into alignment with the active Encryption at Rest configuration.

Prerequisites

Before making a key the default key:

• The key must already exist in the local key store.
• The key must not be revoked.
• The key thumbprint must be known.

List available keys

To list available keys and obtain the thumbprint, execute:

AdminTool.exe /encryptionAtRestListKeys

The recently created key with your recorded thumbprint with AES-256 Algorithm should now appear in the list and be marked as not default and not revoked. 

Set Key as Default

To start using a key for new encryption operations, the key must be designated as the default key. For newly upgraded Endpoint Data Protection environments, assigning the first default key effectively enables the new Encryption at Rest architecture for all future encryption operations. 

Important: In multi-server environments, the key must be present on all active servers before it can be made the default key. If one or more servers do not hold the key, the operation will be rejected. 

To enable the updated encryption at rest architecture, adjust and run the following command:

AdminTool.exe /encryptionAtRestMakeDefaultKey /encryptionAtRestThumbprint <thumbprint>

After execution, the following output should ne shown

Verify the Result

List again all available keys with:

AdminTool.exe /encryptionAtRestListKeys

The desired key should now be listed as Default on each of your servers:

Once a key has been marked as the default key:

• All newly encrypted secrets are protected using this key.
• Existing encrypted data remains unchanged.
• Previously encrypted data remains accessible using the key that originally encrypted it.
• Only one key can be the default key at any given time.

Migrating Existing Encrypted Data

For environments upgraded to Endpoint Data Protection 26.2, assigning a default key enables Encryption at Rest for all newly encrypted data. However, secrets that were stored before Encryption at Rest was enabled remain protected using the legacy encryption mechanism. To bring existing data under the new Encryption at Rest architecture, a migration must be performed. During this process, previously stored secrets are re-encrypted using the currently active Encryption at Rest key. Please note that newly deployed Endpoint Data Protection environments do not require this step because Encryption at Rest is available from the initial deployment and all data is encrypted using the current architecture from the beginning. 

Before You Start

Before starting the migration:

• A default Encryption at Rest key must already be configured.
• All active Endpoint Data Protection servers must hold the same key.
• The List Keys command should report the key as the current default key.
• No key synchronization warnings should be present.
• Ensure a recent database backup is available before starting the migration process. While the migration is designed to update existing encrypted data in place, a backup provides a recovery option in the event of an unexpected interruption or environmental issue.

Running the Migration

The migration command only needs to be executed once. Although the command is started from a specific Endpoint Data Protection server, the process operates on the entire Endpoint Data Protection database rather than the local server. As a result:

• The migration must not be executed on every server.
• Running the migration from one server is sufficient.
• All previously stored secrets within the database are evaluated and migrated as required.
• The migration process is centralized and affects the complete Endpoint Data Protection environment.

Performance Considerations

Most environments complete the migration within a short period of time.

For larger deployments, particularly environments containing hundreds of thousands of directory objects synchronized from Active Directory or Microsoft Entra ID, the migration may take several minutes to complete. Execution time primarily depends on:

• The number of stored secrets.
• Database performance.
• Network latency between the Endpoint Data Protection server and the database server.

As a general guideline, very large environments with more than 500,000 synchronized directory objects may require approximately ten minutes to complete the migration.

What Changes?

After a successful migration:

• Existing secrets are protected using the active Encryption at Rest key.
• Future secrets continue to use the current default key.
• No application configuration changes are required.
• Users and administrators should not experience any operational impact.

The migration only affects data that was stored prior to Encryption at Rest being enabled. Data that is already protected using the active Encryption at Rest key is not modified.

Execute the Migration

Run: 

AdminTool.exe /encryptionAtRestMigrate

• failed should be 0 for every row.
• skipped counts entries that need no change, such as empty values.
• Counts of 0 across a row simply mean that area holds no data.
• A non-zero failed count means only those entries were left as they were; everything else in that row was saved.

Review Logs (optional)

If one or more entries fail during the migration process, the first step should always be to review the server logs. The latest Endpoint Data Protection server log files can be found for example in:

C:\ProgramData\EgoSecure\EgoSecureServer\LOG

Review the most recent log entries and locate any MigrateEncryptionAtRest entries

Tip: If the issue cannot be resolved internally, include the relevant log files when opening a support case with Matrix42 Support.

Review Database (optional)

If you have direct access to the database, you may notice a new format for encrypted values after the migration has completed. Sensitive data protected by the Encryption at Rest framework is stored using the JSON format and includes a reference to the thumbprint of the encryption key that was used to protect the value. This can be used to identify which Encryption at Rest key is associated with a particular encrypted entry.

Legacy Encryption	New AES-256-GCM Encryption after Migration

Next Steps

At this stage, Encryption at Rest has been initialized, a key has been created or imported, secured through a validated backup, designated as the default key, and existing data has been migrated to the new architecture where applicable. For most Endpoint Data Protection environments, no further administrative action is required at this time. Encryption at Rest will continue to protect newly encrypted data automatically using the active key configuration.

The topics covered in the following guide address operational lifecycle activities that may become relevant later, such as key rotation, key retirement, server onboarding, hardware replacement, disaster recovery, and troubleshooting scenarios. For more information, see Encryption at Rest Operations, Recovery and Troubleshooting.