Encryption at rest with customer-managed keys is enabled by linking Atlas to your key management service and configuring the cluster to use your own key rather than a provider-managed one. This gives you control over key rotation and revocation, but also adds dependency on key availability. Monitor key access, rotation, and failover behaviour closely.
How Atlas uses your key management service for customer-managed keys
Atlas does not create a separate encryption model for customer-managed keys, it delegates key protection to the external key management service you connect. The practical question is whether Atlas can reach the key service reliably, authenticate to it correctly, and keep using the key for data encryption without interruption. That makes key custody, access policy, and availability part of the setup, not just post-setup housekeeping.
At a high level, you are choosing between provider-managed keys and your own key material. With customer-managed keys, Atlas still performs the encryption workflow, but the key source, rotation authority, and revocation decision stay under your control. That is useful when you need tighter governance over who can disable access or rotate keys, especially for regulated workloads or environments with stronger separation-of-duties requirements.
For practitioners, the important detail is that encryption at rest is only as dependable as the key management integration behind it. If the key service is unreachable, misconfigured, or revoked unexpectedly, the cluster may be unable to decrypt data as expected. Encryption Guide is a useful reference point for the broader encryption and key-custody model, while Cryptographic Key Management Guide covers the lifecycle issues that matter once Atlas depends on your external key source.
What to verify before you rely on customer-managed keys
Enablement is not just a console toggle. You should verify that the Atlas project, cluster configuration, and key management service are aligned on identity, permissions, and network reachability. The setup needs a key that is valid, accessible to Atlas, and scoped so that the right administrative team can manage it without exposing broader key authority than necessary.
You should also confirm what happens during rotation and revocation. Rotation should be a planned control action, not an emergency only, and revocation should be treated as a high-impact event because it can interrupt decryption until the new key path is working. If your operational model relies on a single region or a single KMS endpoint, the resilience risk is higher than the encryption benefit alone suggests.
Atlas users often underestimate how much of the control depends on routine evidence, not one-time configuration. Monitor successful key use, failed key access, and any changes in failover behaviour so you can distinguish a normal rekey from an access problem. Where the cluster spans multiple environments or accounts, keep the key ownership model simple enough that you can prove who can rotate, revoke, and recover the key at any time. Cryptographic Key Management Guide is especially relevant here because it treats key inventory and lifecycle discipline as operational controls, not just cryptography theory.
When encryption at rest becomes an operational risk
Customer-managed keys improve control, but they also create a dependency that can become a failure point. If the key management service is unavailable, access-controlled too tightly, or rotated without coordination, the encryption layer can turn into an availability issue. This is why the control must be tested under failure conditions, not only in a successful onboarding path.
The failure mechanism is usually one of three things: Atlas cannot authenticate to the key service, the key is no longer usable, or the integration path loses reachability during a maintenance or outage event. In each case, the consequence is the same from the application perspective, encrypted data becomes harder or impossible to use until the key path is restored. Database Security Guide is a good broader reference for understanding how encryption, auditing, and operational hardening fit together in a database environment.
Impact: the practical blast radius is larger than a single encryption setting. Mismanaged customer-managed keys can affect service continuity, incident response, backup recovery, and emergency access decisions, especially when the same operational team also controls rotation and revocation. That is why key loss, key suspension, and emergency change handling should be treated as recovery scenarios, not theoretical edge cases.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 addresses the attack surface, NIST SP 800-53 Rev 5, CSA Cloud Controls Matrix and CIS Controls v8 set the technical controls, and ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | SC-12 — Cryptographic Key Establishment and Management | Covers external key lifecycle and controlled key use for encrypted data. |
| SC-28 — Protection of Information at Rest | Directly applies to encrypting database data stored in Atlas. | |
| IA-5 — Authenticator Management | Applies where key-service credentials or tokens must be managed securely for Atlas access. | |
| Recommendation — Implement SC-12 to govern key establishment, rotation, revocation, and recovery for Atlas encryption keys. Use SC-28 to enforce encryption for stored Atlas data and protect it with controlled keys. Apply IA-5 to protect and rotate the credentials used for Atlas-to-KMS authentication. | ||
| ISO/IEC 27001:2022 | A.8.24 — Use of cryptography | Addresses cryptographic controls for stored data and external key management. |
| A.5.23 — Information security for use of cloud services | Relevant because Atlas is a cloud service depending on an external key-management integration. | |
| Recommendation — Use A.8.24 to define how customer-managed keys are selected, protected, and rotated. Apply A.5.23 to govern cloud-service responsibilities for Atlas key custody and availability. | ||
| CSA Cloud Controls Matrix | CEK — Cryptographic and Key Management | Cloud control domain for key custody, lifecycle, and cryptographic governance in Atlas. |
| IAM — Identity and Access Management | Relevant to controlling who can administer the external key service used by Atlas. | |
| Recommendation — Use CEK to define key custody, rotation, revocation, and recovery expectations for Atlas encryption. Apply IAM to restrict who can administer the key service and approve key changes. | ||
| CIS Controls v8 | 5 — Account Management | Supports secure control of the accounts that administer the key service and Atlas integration. |
| Recommendation — Use CIS-5 to inventory and tightly manage accounts that can change Atlas key settings. | ||
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | Customer-managed keys depend on protecting the secrets that authorize key-service access. |
| NHI-07 — Long-Lived Secrets | Key-service credentials and tokens should not be left with unnecessary long lifetimes. | |
| Recommendation — Use NHI-02 to prevent exposure of the secrets that let Atlas reach your key service. Use NHI-07 to shorten the lifetime of credentials that support Atlas key access. | ||
Practitioner Guidance
What to verify: Confirm the Atlas project can consistently reach the external key service from every environment where the cluster runs, and test rotation and revocation in a non-production workflow before you depend on it for live data.
Decision rule: If your organisation cannot tolerate temporary key-service unavailability, treat customer-managed keys as an availability-sensitive control and design explicit failover, monitoring, and recovery procedures before rollout.
What good looks like: You can show who owns the key, who can rotate or revoke it, how Atlas authenticates to the key service, and what the cluster does when the key path is delayed or unavailable.
Common mistake: Teams often prove encryption enablement once and then stop validating the key lifecycle. In practice, the risk sits in rotation, revocation, and outage handling, not in the initial checkbox.
Practitioner takeaway: Customer-managed keys give you stronger control over encryption at rest, but only if you manage them as a live dependency with tested recovery, not as a static configuration.
Related resources from NHI Mgmt Group
- When should organisations use customer-managed keys for application data instead of provider-managed encryption?
- What is the difference between customer-managed encryption keys and provider-managed encryption keys in SaaS PKI environments?
- How do you enable encryption for Azure managed disks?
- How do you enable database auditing in MongoDB Atlas?