> ## Documentation Index
> Fetch the complete documentation index at: https://docs.arc.cdata.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Encryption at Rest

> How CData Arc encrypts message data at rest with AES-256, including the EncryptionAtRestMode setting, its modes, and operational considerations.

export const siteNameShort = "Arc";

export const siteName = "CData Arc";

{siteNameShort} supports application-level encryption at rest for [message data](../activity#messages-tab). When enabled, all data files stored in {siteNameShort}'s internal storage directories are automatically encrypted using AES-256-GCM with streaming, providing cryptographic protection for data at rest without requiring changes to existing workflows. Encryption at rest addresses data-protection requirements for standards such as PCI DSS, HIPAA, GDPR, and SOX.

Encryption applies to message data in all of {siteNameShort}'s internal storage locations (the Send, Receive, Logs, Pending, and temporary directories) for all connectors.

<Warning>
  Message data encrypted at rest can only be decrypted with your master key. If you configure a [custom master key](../../installation/custom-master-key) and lose access to it, encrypted message data **cannot be recovered**. Implement secure key backup and recovery procedures before enabling encryption at rest.
</Warning>

The following objects are **not** encrypted by this feature:

* Configuration files: sensitive configuration values are encrypted separately by {siteNameShort}'s existing mechanism.
* The application database

Encryption is configured in the **Additional Settings** section of **Settings > Security**. It is disabled by default. To enable it, select one of the following modes:

| Mode              | Write behavior         | Read behavior                                              |
| ----------------- | ---------------------- | ---------------------------------------------------------- |
| **Disabled**      | Plaintext only         | Plaintext only                                             |
| **Compatibility** | Writes plaintext files | Reads encrypted and plaintext files                        |
| **Standard**      | Writes encrypted files | Reads encrypted and plaintext files                        |
| **Strict**        | Writes encrypted files | Reads encrypted files only; plaintext files cause an error |

* **Disabled** is the default. Encryption must be explicitly enabled.
* **Standard** is recommended for most users enabling encryption: it encrypts new files while still accepting existing plaintext files.
* **Compatibility** writes plaintext but reads both encrypted and plaintext files. It is a bridge mode for safely moving between other modes (see [Switching Modes in a Clustered Environment](#switching-modes-in-a-clustered-environment)). It never encrypts on its own: to start encrypting, use **Standard**.
* **Strict** is intended for high-security or compliance environments where plaintext files must never be accepted.

<Note>Restart {siteNameShort} for encryption mode changes to take effect.</Note>

## Migrating Existing Data

Enabling encryption does not retroactively encrypt files that are already on disk. In **Compatibility** and **Standard** modes, {siteNameShort} automatically detects whether each file is encrypted and reads existing plaintext files without modification; a file becomes encrypted only when {siteNameShort} next writes it.

Because **Strict** mode rejects any plaintext file, do not switch to **Strict** until no plaintext message files remain in {siteNameShort}'s storage directories. A typical migration path is:

1. Select **Standard** mode so new files are written encrypted while existing plaintext files are still accepted.
2. Allow existing plaintext files to be processed and cleared out of the Send, Receive, Pending, Logs, and temporary directories through normal operation.
3. Once only encrypted files remain, switch to **Strict** mode to enforce encrypted-only reads.

In a clustered deployment, follow the steps in [Switching Modes in a Clustered Environment](#switching-modes-in-a-clustered-environment) instead.

<Note>
  Switching to **Strict** mode while plaintext files still exist, or while an external system is still writing plaintext to an FTP/SFTP Server root directory, causes those files to error. See [FTP Server and SFTP Server Considerations](#ftp-server-and-sftp-server-considerations).
</Note>

## Switching Modes in a Clustered Environment

In a [clustered](../clustering) deployment, all nodes share the same configuration and message storage. Because a mode change takes effect only after a restart, you restart nodes one at a time to avoid downtime, and during that rollout the nodes temporarily run different modes. A node that meets a file it cannot read in its current mode fails with a hard error (a **Disabled** node reading an encrypted file, or a **Strict** node reading a plaintext file).

To avoid this, change the mode **one step at a time**, following this sequence: **Disabled**, **Compatibility**, **Standard**, **Strict**. Complete a full restart of every node at each step before the next. Do not skip a step.

**To enable encryption:**

1. Set **Compatibility** and restart all nodes. Every node can now read encrypted files but still writes plaintext.
2. Set **Standard** and restart all nodes. Nodes begin writing encrypted files, which every node can already read.
3. Wait until no plaintext files remain (see [Migrating Existing Data](#migrating-existing-data)).
4. Set **Strict** and restart all nodes.

**To disable encryption:**

1. Set **Standard** and restart all nodes.
2. Set **Compatibility** and restart all nodes. Nodes write plaintext again while still reading the encrypted backlog.
3. Wait until no encrypted files remain.
4. Set **Disabled** and restart all nodes.

<Note>
  On a single node there is no rollout window, so you can switch directly to the target mode. You still cannot select **Strict** while plaintext files remain, or **Disabled** while encrypted files remain.
</Note>

## Transparent Operation

* Encryption and decryption happen automatically; no changes are required to users and existing workflows.
* Files are encrypted while stored at rest inside {siteNameShort}, but are delivered to downstream connectors and trading partners in plaintext.
* Encryption uses {siteNameShort}'s existing [master key](../../installation/custom-master-key) mechanism, so additional key configuration is not required.
* Enabling encryption can have an impact on performance, but file-size overhead is negligible.

## FTP Server and SFTP Server Considerations

Encryption at rest applies to the root directory used by the [FTP Server](../../../connectors/ftp-server) and [SFTP Server](../../../connectors/sftp-server) connectors.

* In **Compatibility** or **Standard** mode, external SFTP and FTP clients can still write plaintext files to the Root Directory; {siteNameShort} accepts and processes them normally.
* In **Strict** mode, only encrypted files are accepted; external systems writing plaintext directly to the root directory encounter errors.

If you have external systems that write directly to an FTP or SFTP Server root directory, avoid using **Strict** mode.

## Key Management

Encryption at rest uses {siteNameShort}'s existing master key, the same key that already protects sensitive setting values, so a separate key setup is not required. See [Custom Master Key](../../installation/custom-master-key) for details on the master key.

### Rotating the Master Key

Rotating the master key does not re-encrypt your message data or make existing encrypted files unreadable. Encryption at rest protects files through a key hierarchy: the master key protects an internal data key, which in turn protects each file's encryption key. This means that a rotation re-wraps that internal key rather than rewriting every file. Files encrypted before a rotation remain readable afterward, and no bulk re-encryption step is required.

Rotate the master key using the procedure described in [Custom Master Key](../../installation/custom-master-key).