Encryption at Rest Architecture, Concepts and Deployment Scenarios
Table of Contents
Introduction
Encryption at Rest (EAR) protects secrets stored by EgoSecure Server in the Endpoint Data Protection database, while it does not encrypt the entire database and does not change Agent-side encryption behavior. As security requirements, compliance expectations, and cryptographic best practices continue to evolve, protecting these secrets requires not only strong encryption algorithms but also secure key management and lifecycle controls.
With Endpoint Data Protection 26.2, a redesigned Encryption at Rest architecture was introduced to replace the previous legacy implementation. The new architecture is based on modern cryptographic standards and introduces a dedicated key management framework that separates encryption keys from the database. This approach improves the protection of encrypted data, strengthens resilience against unauthorized database access, and provides a more secure foundation for future security and compliance requirements.
The Encryption at Rest framework supports both single-server and multi-server deployments and includes comprehensive key lifecycle management capabilities, such as key generation, import, export, rotation, revocation, backup, recovery, administrator-managed key distribution, and validation. Existing encrypted data can be migrated to the new architecture, allowing organizations to adopt the enhanced protection model while maintaining operational continuity.
This guide provides a comprehensive overview of the Encryption at Rest architecture introduced with Endpoint Data Protection 26.2 and explains how to deploy, configure, operate, and maintain EAR-protected environments. It also covers key management concepts, migration scenarios, multi-server considerations, backup and recovery procedures, security recommendations, and troubleshooting guidance.
Architecture Overview
The Encryption at Rest (EAR) architecture combines authenticated data encryption, server-local key stores, database-wide key metadata and validation, and operating system-level key protection to secure secrets stored in the Endpoint Data Protection database. The architecture is built on three core components:
AES-256-GCM Encryption
All newly encrypted data is protected using Advanced Encryption Standard (AES) with 256-bit keys operating in Galois/Counter Mode (GCM). In addition to providing confidentiality, GCM offers integrity protection, allowing the system to detect unauthorized modifications to encrypted data.
EAR Key Management
Encryption keys are managed through a dedicated Encryption at Rest (EAR) key management framework. The framework is responsible for the complete key lifecycle, including key generation, storage, import, export, backup, rotation, and revocation. Multiple keys can coexist simultaneously, enabling key rotation and migration scenarios without interrupting access to previously encrypted data.
Next Generation Windows Cryptography API
EAR encryption keys are protected using the Next Generation Windows Cryptography API (CNG/DPAPI-NG). This ensures that key material remains protected at the operating system level and is not stored directly within encrypted application data. In multi-server environments, database-wide key metadata is used to validate key availability across servers. Keys must be distributed by administrators using the Export Key and Import Key commands.
Together, these components provide the foundation for the Encryption at Rest architecture introduced in Endpoint Data Protection 26.2.
EAR Key Management Architecture
The Encryption at Rest (EAR) framework is built around a dedicated key management architecture that separates cryptographic keys from the encrypted data they protect. This separation reduces the risk associated with unauthorized database access and provides a foundation for secure key lifecycle management.
Within the EAR architecture, encrypted data remains stored in the Endpoint Data Protection database, while encryption keys are managed independently by the EAR key management framework. This ensures that access to the database alone is not sufficient to decrypt protected information.
Architectural Components and Concepts
The EAR architecture consists of the following components and concepts:
| Component / Concept | Description |
|---|---|
| Encrypted Data Store |
Sensitive information remains stored within the Endpoint Data Protection database in encrypted form. The database contains only the encrypted payload and references to the encryption key that was used to protect the data.
|
| EAR Keys | EAR keys are the cryptographic keys used to encrypt and decrypt protected information. Multiple keys can coexist within an environment, allowing administrators to perform key rotation and recovery operations without affecting existing data. Each encrypted object maintains a reference to the key that was used during encryption, ensuring that previously encrypted data remains accessible even after newer keys become available. |
| Key Repository | EAR keys are stored separately from the database within the Endpoint Data Protection key management framework. Key material is protected before being written to disk and is never stored directly alongside the encrypted application data. |
| Server Protection Layer |
To prevent unauthorized use of key material, stored EAR keys are additionally protected through platform-level security mechanisms. This ensures that possession of the key repository alone is insufficient to access cryptographic secrets without the corresponding server protection context.
|
| Key Backups | The architecture supports secure export and backup of EAR keys. Backups allow organizations to recover encrypted data following server failures, disaster recovery scenarios, or infrastructure migrations. |
| Default Key Concept | At any given time, one EAR key is designated as the default key. Newly encrypted data is protected using the current default key, while previously encrypted information remains associated with the key that was originally used for encryption. This approach enables seamless key rotation without requiring immediate re-encryption of all existing data. |
| Key Lifecycle Management | The architecture supports the complete lifecycle of encryption keys, including: creation, import, export, rotation, revocation, backup and recovery, administrator-managed key distribution, Key validation |
| Multi-Server Environments | In multi-server deployments, administrators must ensure that every server holds all keys required to decrypt the deployment's secrets. Keys are distributed manually using Export Key and Import Key. Before a key can be made the default, the framework checks that every server recorded in the EAR metadata holds that key in a non-revoked state. |
Deployment Scenarios
The following workflows provide a recommended starting point for the most common Encryption at Rest deployment and migration scenarios. Choose the workflow that matches your current Endpoint Data Protection environment and follow the linked procedures in the order shown.
Fresh Installations
Fresh Installation of Endpoint Data Protection 26.2 and later on a Single Server
For new Endpoint Data Protection installations, the Encryption at Rest infrastructure is automatically initialized when the EgoSecure Server service is started for the first time. During this process, an initial Encryption at Rest key is automatically generated and stored in the local key store. The generated key must be exported and stored securely as a backup. Until a backup of the key has been created, administrators are reminded through a notification in the Management Console. Creating and validating a key backup should therefore be one of the first administrative tasks after completing the installation.
Verify Existing Key
↓
Export / Backup Key
↓
Validate BackupFresh Installation of Endpoint Data Protection 26.2 and later on a Multi-Server Environment
When deploying Endpoint Data Protection in a multi-server environment, all participating servers must share the same Encryption at Rest key set. The initial key is created on one server automatically, distributed to all remaining servers by administrators, and then activated consistently across the environment to ensure all servers can encrypt and decrypt data using the same key material.
Verify Existing Key
↓
Export / Backup Key
↓
Import Key onto Server B, C, D, ...
↓
Verify identical thumbprint on all servers
↓
Make Default Key on all serversUpdated Installations
Updated Single Server to Endpoint Data Protection 26.2 and later
After upgrading an existing single-server deployment, the Encryption at Rest infrastructure becomes available, but no key is active by default. The first Encryption at Rest key must be created, validated, and activated before existing encrypted data can be migrated to the new architecture.
Create Key
↓
Validate Backup
↓
Make Default Key
↓
Migrate Existing DataUpdated Multi-Server Environment to Endpoint Data Protection 26.2 and later
After upgrading a multi-server deployment, the new Encryption at Rest architecture must be introduced consistently across all servers. The first Encryption at Rest key must be created. The same key must be available on every active server before it can be activated. Once the key has been designated as the default key on all servers, existing encrypted data can be migrated using a single migration operation against the shared database. Important: Complete default key activation on every server within the same maintenance window.
Create Key on Server A
↓
Export / Backup Key
↓
Import Key onto Server B, C, D, ...
↓
Verify identical thumbprint on all servers
↓
Make Default Key on each server
↓
Run migration once from a single serverNext Steps
This guide introduced the Encryption at Rest architecture, key management concepts, and the recommended deployment scenarios for new and existing Endpoint Data Protection environments. To begin implementing Encryption at Rest, continue with the Working with Encryption at rest, which covers key creation, backup and recovery, key activation, and migration procedures.