OpenKM Adds Application-Level Encryption to Protect Document Repository Content

OpenKM Adds Application-Level Encryption to Protect Document Repository Content

Written by OpenKM on 18 september 2026

For a CISO, knowing that disks or cloud storage are encrypted is important, but it does not always answer two key questions: When is the document actually encrypted, and who can request its decryption?

A security manager may want to reduce the impact of malicious access to the backend. An IT manager may need to maintain the same level of protection regardless of whether documents are stored on a filesystem or in S3 storage. A records management professional needs any additional security measure to preserve the usual way authorized users access, search, and version documents.

OpenKM addresses these requirements with a new capability planned for OpenKM 8.2.9: application-level datastore encryption using AES-256-GCM

The difference is simple: OpenKM encrypts the content before sending it to the storage system.

What is application-level encryption?

A storage system may have its own encryption-at-rest mechanisms. In this model, the infrastructure protects the data while it is stored on disks, servers, or cloud services.

Application-level encryption introduces a different layer of protection. When this feature is enabled, OpenKM encrypts the content within the application itself before writing it to the datastore.

As a result, the backend — whether a filesystem or S3-compatible storage — receives an object that has already been cryptographically protected by OpenKM.

This separation is important because it decouples document protection from the specific technology used to store it.

Storage encryption and OpenKM encryption: different layers

Both mechanisms can coexist, but they do not perform exactly the same function.

Infrastructure-level encryption protects data within the storage environment. In some models, an application with the appropriate credentials and permissions can request the content and receive it in decrypted form.

OpenKM encryption acts earlier in the process. The application encrypts the document using AES-256-GCM and then sends the already protected content to the backend. Therefore, the storage system does not directly receive the original unencrypted document.

This does not mean that one mechanism replaces the other. On the contrary, both can form part of a defense-in-depth strategy, where different security layers reduce dependence on a single control.

What does AES-256-GCM provide?

AES is a widely used symmetric encryption standard. In its AES-256 variant, it uses a 256-bit key.

GCM — Galois/Counter Mode — adds an important capability: it is an authenticated encryption mode.

This means that its purpose is not only to protect the confidentiality of the information, but also to detect modifications to encrypted data before it is processed.

In the planned OpenKM architecture, each object has its own securely generated initialization vector.

The goal is to ensure that every cryptographic operation has the necessary elements to protect the content correctly, while the encryption key is controlled at the installation level.

What content can OpenKM protect?

This functionality is designed to protect document content stored in the datastore, as well as the text extracted for indexing and search.

This second element is particularly important.

An organization may thoroughly protect a contract, case file, or financial report without realizing that the indexing process can generate a textual representation of the same document.

That text may contain exactly the same names, amounts, identification numbers, clauses, or confidential information as the original file.

Protecting only the binary document would therefore leave a significant portion of the repository's managed content outside the encryption layer.

The scope is also expected to include documents and their versions, as well as emails managed as documents within OpenKM.

Transparent for authorized users

Encryption should be transparent to users, without requiring them to manually manage encrypted files.

The design ensures that encryption and decryption take place within OpenKM's internal workflows.

When an authorized user requests a document, OpenKM retrieves the stored object, performs the corresponding validation and decryption process, and delivers the content through the application's normal workflow.

Viewing, downloading, searching, and versioning documents are intended to continue working as usual.

From the user's perspective, document management continues to operate normally.

From a security perspective, the backend stores objects encrypted by OpenKM.

Checksums and document integrity

Encryption should not disrupt the mechanisms used to verify repository integrity.

For this reason, document checksums continue to be calculated on the original content.

This allows existing verification mechanisms to remain in place and makes it possible to confirm that the retrieved document matches the document originally added to the repository.

The architecture therefore separates two functions: encryption protects stored content, while checksums help verify document integrity.

The encryption key is critical

The encryption algorithm may be strong, but without proper key management, the encryption strategy remains incomplete.

The key used to protect the repository must form part of the organization's security, backup, and recovery procedures.

If the key required to decrypt the documents is lost, the encrypted content may become permanently inaccessible.

Its custody must therefore be planned before the feature is enabled.

The organization must determine who can access the key, where a protected recovery copy is stored, how that copy is secured, and how it will periodically verify that a full recovery remains possible.

Encryption is a technical decision. Ensuring that the key is available when it is actually needed is a business continuity decision.

What happens to existing documents?

Enabling encryption does not mean that previously stored content is automatically encrypted.

Existing documents may require a specific migration or rewriting process.

OpenKM includes tools for retroactively encrypting content stored before the feature is enabled, meaning that a complete deployment should cover both new and historical content.

For large repositories, this process should be planned like any other migration: with prior backups, error control, validation, recovery testing, and integrity checks.

Pay attention to caches and derived representations

Another key consideration is identifying exactly which types of content are covered by encryption.

The datastore is protected, but not every temporary or derived representation generated by the application will necessarily be protected in the same way.

PDF previews, SVG files, thumbnails, and certain resources used by viewers may require additional protection or cleanup policies depending on the version and configuration.

Therefore, before stating that “the entire repository is encrypted,” it is necessary to review the exact scope of the implementation being used.

It is equally important to define precisely which content is protected by this encryption layer.

Encryption does not mean absolute security

AES-256-GCM adds an important security layer, but it does not replace other controls.

An organization still needs authentication, document permissions, credential protection, network security, segmentation, auditing, server hardening, backups, and recovery procedures.

The purpose of application-level encryption is to reduce specific risks, particularly those resulting from direct access to the storage medium.

For this reason, the appropriate concept is defense in depth, not “total security.” Encryption protects one specific layer within a broader security architecture.

Protection that follows the document

The main difference introduced by this architecture can be summarized as follows: the document reaches the storage system already encrypted by OpenKM.

This means that protection does not necessarily depend on whether the backend is a filesystem, a cloud service, or S3-compatible storage.

For the CISO, this means introducing a barrier against direct access to stored content. For IT, it means maintaining a protection strategy that is relatively independent of the storage backend. For records management, it means preserving the usual experience for authorized users. And for business continuity, it introduces a new responsibility: ensuring that the cryptographic key is securely stored and can be recovered when required.

AES-256-GCM encryption is included in the planned evolution of OpenKM 8.2.9, but its deployment should be accompanied by a specific review of scope, historical content, caches, key management, and recovery procedures.

Contracts, case files, financial information, HR documentation, or other sensitive content? Contact the OpenKM team to determine how application-level encryption can be integrated into your document management architecture and to define an appropriate strategy for key management, migration, storage, and recovery.