Envelope encryption
Every sensitive field that lands in MongoDB is sealed with AES-256-GCM. A fresh random data encryption key (DEK) is generated per field and wrapped by the active key encryption key (KEK). This page explains the model, what is encrypted, and what appears on disk.
KEK rotation
Rotate the key-encryption-key without downtime, even across a multi-replica cluster. The fleet-aware rotation is the headline feature in 1.4.x.
KEK providers
A KEK provider wraps and unwraps data-encryption keys. CertAutoPilot ships two: env (software, KEK bytes in environment variables) and pkcs11 (hardware, KEK lives in a PKCS#11 HSM). The choice is made at install time and is immutable thereafter.
Fleet readiness
A KEK rotation only works if every running process has already loaded the new version. The fleet-readiness check is what guarantees that. Each process heartbeats into MongoDB every 30 s reporting its loaded versions and current version; kek verify --target=N refuses to ready-up if any live process is missing the target key material.
PKCS#11 setup
The pkcs11 provider stores the KEK inside a Hardware Security Module. CertAutoPilot never sees key material — only opaque HSM handles and the wrapped DEK blobs. This page walks through preparing a token, running the capability probe, and completing the install-lock.
PKCS#11 vendors
Per-vendor notes for supported (and unsupported) HSMs. CertAutoPilot's requirements are CKM_AES_GCM + CKM_AES_KEY_GEN — any FIPS-approved HSM from the last decade qualifies. We validate via the capability probe before committing. See the setup flow for the generic procedure.
Changing KEK provider — fresh install required
CertAutoPilot's KEK provider (env vs pkcs11) is chosen at install time and locked immutably in the MongoDB kek_install singleton. There is no in-place migration path: changing the provider requires a fresh install against a new MongoDB. This page explains why, and walks through the migration procedure.