Skip to main content
supports application-level encryption at rest for message data. When enabled, all data files stored in ‘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 ‘s internal storage locations (the Send, Receive, Logs, Pending, and temporary directories) for all connectors.
Message data encrypted at rest can only be decrypted with your master key. If you configure a 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.
The following objects are not encrypted by this feature:
  • Configuration files: sensitive configuration values are encrypted separately by ‘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:
  • 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). 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.
Restart for encryption mode changes to take effect.

​
Migrating Existing Data

Enabling encryption does not retroactively encrypt files that are already on disk. In Compatibility and Standard modes, automatically detects whether each file is encrypted and reads existing plaintext files without modification; a file becomes encrypted only when next writes it. Because Strict mode rejects any plaintext file, do not switch to Strict until no plaintext message files remain in ‘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 instead.
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.

​
Switching Modes in a Clustered Environment

In a clustered 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).
  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.
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.

​
Transparent Operation

  • Encryption and decryption happen automatically; no changes are required to users and existing workflows.
  • Files are encrypted while stored at rest inside , but are delivered to downstream connectors and trading partners in plaintext.
  • Encryption uses ‘s existing 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 and SFTP Server connectors.
  • In Compatibility or Standard mode, external SFTP and FTP clients can still write plaintext files to the Root Directory; 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 ‘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 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.