Encryption

MongoDB offers encryption at several layers, each protecting against a different threat. Understanding what each one actually guards against — and what it doesn't — matters more than enabling all of them blindly.

TLS in Transit

TLS encrypts data moving between the client and the server (and between cluster members). It protects against network eavesdropping and man-in-the-middle attacks — it does nothing for data sitting on disk.

Bash

# mongod.conf
net:
  tls:
    mode: requireTLS
    certificateKeyFile: /etc/ssl/mongodb.pem
    CAFile: /etc/ssl/ca.pem

Bash

mongosh --tls --tlsCAFile ca.pem "mongodb://host:27017/shop"

Note

Atlas enforces TLS on every connection by default — you cannot disable it. Self-hosted deployments must configure it explicitly, and requireTLS should be the target for any production deployment.

Encryption at Rest

Encryption at rest protects the data files on disk — if someone steals a physical drive or an unencrypted backup file, the data is unreadable without the encryption key. It protects against disk/media theft; it does nothing against someone who already has an authenticated connection to a running server.

Atlas encrypts all data at rest by default (AES-256), with an option to bring your own encryption key (KMIP-compatible KMS: AWS KMS, Azure Key Vault, Google Cloud KMS).
Self-hosted WiredTiger supports native encryption at rest (Enterprise edition), configured with a local keyfile or an external KMIP server.
Cloud provider disk-level encryption (e.g. EBS encryption) is a reasonable substitute if the storage engine option is unavailable, though it protects at a different layer.

Bash

# mongod.conf — Enterprise, encryption at rest via local keyfile
security:
  enableEncryption: true
  encryptionKeyFile: /etc/mongodb/encryption-keyfile

Client-Side Field Level Encryption (CSFLE)

CSFLE encrypts specific fields on the client, before the data ever leaves your application — the server (and anyone with database access, including a DBA or an attacker who compromises the server) only ever sees ciphertext for those fields. Decryption happens only on authorized clients holding the data encryption key.

const encryptedFieldsMap = {
  "shop.customers": {
    fields: [
      {
        path: "ssn",
        bsonType: "string",
        keyId: dataKeyId
      }
    ]
  }
}

const secureClient = new MongoClient(uri, {
  autoEncryption: {
    keyVaultNamespace: "encryption.__keyVault",
    kmsProviders: { local: { key: localMasterKey } },
    encryptedFieldsMap
  }
})

// Writes/reads through secureClient transparently encrypt/decrypt "ssn";
// a plain client (or anyone querying directly) only ever sees ciphertext
await secureClient.db("shop").collection("customers").insertOne({
  name: "Alice",
  ssn: "123-45-6789"   // encrypted automatically before leaving the app
})

Warning

With deterministic CSFLE, equality queries on the encrypted field work, but range queries and sorting do not (the server never sees plaintext, so it cannot compare or order encrypted values). Plan your query patterns around this before choosing which fields to encrypt.

Queryable Encryption

Queryable Encryption is MongoDB's newer approach to the same problem CSFLE solves, but with structured encryption that supports equality queries (and, in newer versions, range queries) on encrypted fields — without the server ever seeing the plaintext or the query predicate in the clear. It uses specialized encrypted index structures instead of exposing a deterministic ciphertext pattern.

const encryptedFieldsMap = {
  "shop.customers": {
    fields: [
      { path: "ssn", bsonType: "string", queries: { queryType: "equality" } }
    ]
  }
}
// Query as normal — the driver handles encrypting the query predicate
await secureClient.db("shop").collection("customers").findOne({ ssn: "123-45-6789" })

What Each Layer Protects Against

Mechanism	Protects Against	Does NOT Protect Against
TLS in transit	Network eavesdropping, MITM	Data at rest, a compromised server
Encryption at rest	Stolen disks/media, unencrypted backup leaks	An attacker with an authenticated live connection
CSFLE	Server-side/DBA visibility, a compromised database server	A compromised application server holding the key
Queryable Encryption	Same as CSFLE, plus supports queries without server-side plaintext exposure	A compromised application server holding the key

Tip

Layer these — TLS and encryption at rest should be table stakes for every deployment; add CSFLE/Queryable Encryption specifically for the small set of genuinely sensitive fields (SSNs, payment details, health data) where even privileged database access should not reveal plaintext.

Summary

TLS protects data in transit; encryption at rest protects data on disk — neither protects against a live, authenticated attacker reading through the database.
CSFLE encrypts specific fields client-side so the server never sees plaintext, at the cost of limited query capability.
Queryable Encryption extends the same guarantee to support equality (and increasingly range) queries on encrypted fields.
Use all four layers together for defense in depth — they protect against different threat models, not the same one.