{Event}  MongoDB is going on a world tour! Gather your team and head to your nearest MongoDB.local. Learn more >

MongoDB Client-Side Field Level Encryption

MongoDB’s Client-Side FLE provides among the strongest levels of data privacy and security for regulated workloads.

Encrypted document

How Client-Side Field Level Encryption Works

Your most sensitive data, such as PII, is automatically encrypted by the MongoDB drivers before leaving the application, and so the database server only ever works with it as ciphertext. Client-Side encryption protects data while it is in-use by the database, securing it against sophisticated exploits that target server memory.

The flow of a query submitted by an authenticated client using FLE

The flow of a query submitted by an authenticated client using FLE


Data is encrypted in-motion, in-memory, and at-rest


No need to modify your code


Index and query against encrypted fields in your documents

Inaccessible to Admins

The database only works with ciphertext and only you control the keys

Industry Standard

NIST-certified AES, integrated with leading KMS’. Open source crypto framework

How Client-Side Field Level Encryption Helps You

Client-side encryption dramatically reduces the risk of unauthorized access or disclosure of sensitive data. Fields are encrypted before they leave your application, protecting them everywhere: in-motion over the network, in database memory, at-rest in storage and backups, and in system logs.

Accelerate Your Move to the Cloud

Enforces a fine-grained separation of duties between those who use the database and those who manage it. Cloud vendor staff only ever see ciphertext

Comply with Right to Erasure Mandates

Makes it much easier to meet modern privacy regulations. Simply destroy the encryption key and the user’s PII is unreadable and irrecoverable

Ready to try out Client-Side Field Level Encryption?

Launch your Atlas database cluster for free, in minutes

MongoDB Client-Side Encryption FAQ

What data can I encrypt?

Client-Side FLE is highly flexible. You can selectively encrypt individual fields within a document, multiple fields within the document, or the entire document. Each field can be optionally secured with its own key and is decrypted seamlessly on the client.

What encryption algorithms and key management services are supported?

Client-Side FLE uses standard NIST FIPS-certified encryption primitives including AES at the 256-bit security level, in authenticated CBC mode: AEAD AES-256-CBC encryption algorithm with HMAC-SHA-512 MAC. Data encryption keys are protected by strong symmetric encryption with standard wrapping Key Encryption Keys, which can be natively integrated with external key management services backed by FIPS 140-2 validated Hardware Security Modules (HSMs). Client-Side FLE is available with Amazon KMS, Azure Key Vault and Google Cloud KMS. You can also use remote secure web services to consume an external key or secrets manager such as Hashicorp Vault.

What is the performance impact of Client-Side Encryption?

All encryption and decryption happen at the client so there is minimal performance impact to the database server itself.

The performance impact to the client depends on how many fields are being encrypted and on your specific workload. Latency overhead is as low as a few percent, or it can be higher if every single field in every document is being separately encrypted while being read and written in every operation. To give an indication of performance impact, a healthcare analytics provider saw a 10-15% overhead for multiple fields in heavily encrypted, high volume medical records.

Is data encrypted client-side still queryable in the database?

Client-Side FLE supports two modes of field encryption: deterministic and randomized.

By using deterministic encryption, you can perform equality queries on encrypted fields. You can query both top level document fields and fields nested in sub-documents and arrays. Regular find(), update(), and aggregation pipeline analytical queries are supported, and indexes can be used to efficiently access the encrypted fields.

Randomized encryption does not allow any read operations to match directly against the encrypted field.

Reads against fields in the document that are not encrypted client-side will evaluate as normal, as part of any query, search, or aggregation pipeline operation.

Which versions of MongoDB support Client-Side FLE?

As long as you are running MongoDB 4.2 and above with supported drivers, you can use FLE everywhere:

Client-Side FLE is supported on 20+ platforms and by multiple programming language drivers.

One difference in where you choose to use Client-Side FLE is that MongoDB Atlas and MongoDB Enterprise support automatic encryption of fields in read and write operations, while the community database requires the explicit encryption of fields in application code. The core cryptography libraries themselves are identical.

How does Client-Side FLE compare with network (in-flight) and storage (at-rest) encryption?

Client-Side FLE is best applied selectively to those fields of your documents that you classify as containing the most sensitive data, such as PII.

Using Client-Side FLE alongside in-flight and at-rest encryption gives you an end-to-end, complementary approach in building applications that provide a defense-in-depth security posture to address different threat models.

  • In-flight encryption protects all data traversing the network, but does not encrypt data in-memory or at-rest.
  • At-rest encryption protects all stored data, but does not encrypt data in-memory or in-flight.
  • With client-side encryption, your most sensitive data never leaves your application in plaintext. Fields that are encrypted client-side remain encrypted over the network, as they are being processed in database server memory, and at-rest in storage, backups, and logs.