How does Atlas encrypt my data?
Atlas protects customer data in transit with TLS. TLS is enabled by default and cannot be disabled; it encrypts data sent to Atlas and data transmitted between nodes of an Atlas cluster. Atlas also encrypts customer data at rest. Encryption at rest is always enabled using Advanced Encryption Standard (AES)-256.
Atlas Core: On an Atlas Core cluster, your cloud provider automates this disk encryption and manages the encryption keys. You can optionally enable database-level encryption using the WiredTiger Encrypted Storage Engine and bring your own key through AWS KMS, Google Cloud KMS, or Azure Key Vault.
Atlas Infinite: Atlas Infinite is currently in public preview. In Atlas Infinite, compute and storage are separate layers. Atlas Infinite always encrypts customer data at the database level, before it leaves the compute layer and reaches the storage layer, which is shared across multiple customers. This storage layer does not have the encryption keys and cannot decrypt customer data. In public preview, customer-managed keys are available through AWS KMS.
For more detail on encryption and Atlas security controls, see Technical and Organizational Security Measures.
How does Atlas Infinite keep each customer's data separate from other customers?
MongoDB Atlas Infinite clusters are deployed in a dedicated VPC that fully isolates customer data at the compute layer. Atlas Infinite keeps each tenant's data separate in the storage layer in two ways:
Every request your cluster makes to the storage layer is checked against your cluster's identity, so only your data is returned.
Atlas Infinite encrypts data before it reaches the storage layer. By default, MongoDB manages a unique encryption key for each Atlas organization and rotates it automatically every 90 days. Customer-managed keys add another encryption layer, and you can migrate between default and customer-managed encryption in either direction.
Which certifications cover Atlas?
For the current list of certifications and attestations that cover Atlas, see the MongoDB Atlas Shared Responsibility Model. Further, Atlas Infinite is in scope for the same certifications and attestations as Atlas Core.
Which controls can I configure with Atlas Infinite?
You can configure the same controls available in Atlas today:
Area | Controls |
|---|---|
Networking | |
Encryption | |
Backups | |
Support access | |
Region | |
Cluster configuration |
Where can my data be processed or stored in Atlas Infinite, and can I restrict this by region, jurisdiction, or cloud?
Consistent with Atlas Core, your application data in Atlas Infinite is only processed in the region(s) in which the cluster is located. Atlas gives you the ability to choose which cloud provider and the specific region(s) a cluster is located in.
What review and analysis has been done to confirm the system is secure?
Atlas undergoes regular reviews from both internal and external security teams. The Atlas production environment is subject to an external penetration test by an industry recognized security firm at least once per calendar year. Internally, Atlas undergoes periodic risk assessments, including technical vulnerability discovery and analysis of business risks and concerns. Further, MongoDB conducts regular scans of the underlying systems on which Atlas is deployed and of third-party code integrated into its products. For more details refer Technical and Organizational Security Measures.
Can I disable TLS on my deployment?
No.
What versions of TLS does Atlas support?
Atlas requires TLS connections for all Atlas clusters. Atlas supports TLS protocol versions 1.2 and 1.3.
IMPORTANT: Atlas no longer supports TLS 1.0 or 1.1. All clusters reject attempts to connect with TLS 1.0 or 1.1. Set the minimum TLS version of your clusters to 1.2 or higher.
You can read more about timing and reasons for the change from the Payment Card Industry (PCI) and the National Institute of Standards and Technology (NIST).
If you have questions about TLS support or cannot update your applications to support TLS 1.3, please contact Atlas MongoDB Support.
To open a Atlas support ticket:
In Atlas, go to the Support page.
If it's not already displayed, select your desired organization from the Organizations menu in the navigation bar.
Click the Support icon in the navigation bar.
Click View plan.
The Support page displays.
How do I know if my applications support TLS 1.3?
Applications whose underlying programming languages or security libraries predate TLS 1.3 may require updating to a more recent version to support TLS 1.3. You may also need to update the application host operating system to support TLS 1.3.
MongoDB and Atlas don't provide services to audit external applications for which versions of TLS support they support. Third party services, such as howsmyssl.com may provide the appropriate tooling. MongoDB doesn't endorse this service, and its reference is only informational. Use your organization's procedures for selecting the vendor or service for auditing your applications.
What do I have to do to update my clusters for TLS 1.3?
Conduct an audit of your applications for support of TLS 1.3.
Update all components of your technology stack that don't support TLS 1.3.
Modify your cluster configuration to use TLS 1.3.
If you have a custom TLS 1.2 cipher configuration, you must update the configuration to include the TLS 1.3 ciphers.
Which certificate authority signs MongoDB Atlas TLS certificates?
Atlas cluster nodes' TLS certificates are signed by either Google Trust Services or Let's Encrypt to improve high availability. Atlas uses both certificate authorities concurrently. You must add CA certificates for the GTS Root R1, GTS Root R2, GTS Root R3, and GTS Root R4 root Certificate Authority from Google Trust Services to your clients' trusted certificate stores, in addition to the ISRG Root X1 root Certificate Authority from Let's Encrypt to ensure seamless service continuity.
Atlas uses the GTS Root R3 and GTS Root R4 root CA certificates for TLS 1.3 support.
Note
Most application environments already have Let's Encrypt and Google Trust Services in their trusted Certificate Authority list.
To download the Certificate Authority certificates, see the Google Trust Services repository and ISRG Root X1.
Note
Atlas automatically rotates the certificates. You don't need to run the rotateCertificates command. Use the rotateCertificates command only if you want to rotate the certificates manually.
How often does an Atlas Cluster rotate TLS certificates?
TLS certificates are valid for 90 days from the day it is issued. Certificates are rotated 42 days before the certificate's expiration date.
Use the following command to check expiration of your TLS certificate of a node:
echo | openssl s_client -showcerts -connect $HOSTNAME:$PORT 2> /dev/null | openssl x509 -noout -enddateHard-coded Certificate Authority
We don't recommend hard-coding or pinning intermediate certificates because it introduces an operational burden and availability risk. If Let's Encrypt or Google Trust Services rotates or replaces your pinned intermediate certificate, your application might fail to connect, which results in an outage.
If you must pin a certificate, pin it to Certificate Authority certificates and not to any intermediate certificates.
Java Users
Let's Encrypt's ISRG root certificate and Google Trust Services root certificates are both available in the default trust store of Java version 7 after the 7u391 update and Java version 8 after the 8u381 update. Use a Java release after 18 July 2023.
Ensure your Java client software is up-to-date. Use the latest Java versions to leverage improvements beyond these new Certificate Authority requirements for our TLS certificates.
If you have your own trust store, add the Let's Encrypt and Google Trust Services certificates to it. To learn more, see Which certificate authority signs MongoDB Atlas TLS certificates?
Windows Server Users
The ISRG Root X1, GTS Root R1 and GTS Root R2 root Certificate Authority aren't included by default in Windows Server, but it is available in the Microsoft Trusted Root Program.
To configure Windows Server to download trusted root certificates, see Windows Documentation.
Amazon Linux AMI Users
Some versions of Amazon Linux AMI may not have both ISRG Root X1 and GTS Root R1 and R2 certificates. Please migrate to a newer version of Amazon Linux for required root certificates. After June 2025, we will require the support of ISRG Root X1, GTS Root R1 and R2 certificates for Atlas to avoid certificate compatibility issues.
If you must use an older Amazon Linux AMI, manually install the ISRG Root X1, GTS Root R1 and R2 root Certificate Authority.
Everyone Else
This change shouldn't impact you if you use a recent programming language and operating system version.
Why did my TLS configuration change fail with an UNSAFE_TLS_TRANSITION error?
Atlas prevents TLS configuration changes that could break communication between cluster nodes during a rolling update.
When you update TLS settings, Atlas applies the changes one node at a time. During this process, nodes running the old configuration must still be able to connect to nodes running the new configuration. If your proposed changes remove all shared TLS versions or cipher suites, the nodes can't communicate, which leads to a partitioned cluster and potential downtime.
To protect cluster availability, Atlas blocks these unsafe transitions and returns the UNSAFE_TLS_TRANSITION error.
UNSAFE_TLS_TRANSITION Error Causes
This error typically occurs in the following scenarios when there is no overlap between the current and proposed TLS configurations:
TLS version mismatch.
Example: Switching directly from TLS 1.2-only to TLS 1.3-only.
Result: Nodes using TLS 1.2 cannot connect to nodes requiring TLS 1.3.
Cipher suite mismatch.
Example: Replacing all existing cipher suites with a completely different set.
Result: Nodes have no shared cipher to negotiate a connection
UNSAFE_TLS_TRANSITION Error Solution
Make your TLS changes in phases, and ensure overlap between old and new settings:
For TLS versions:
Enable both TLS 1.2 and TLS 1.3.
Apply the change and allow the update to complete.
Remove TLS 1.2 in a follow-up update (if desired).
For cipher suites:
- Ensure at least one cipher suite is shared between the current and new configurations during the transition.
UNSAFE_TLS_TRANSITION Error Key Takeaway
Avoid "all-at-once" TLS changes. Always maintain temporary compatibility between old and new configurations to ensure a safe rolling update.
What is Atlas's support policy for community and unsupported drivers?
Atlas provides different levels of support for officially supported drivers, community drivers, and unsupported configurations.
Driver Categories
Officially Supported Drivers
MongoDB develops and maintains these drivers, which are listed on mongodb.com/docs/drivers. MongoDB's test matrix, release process, and support SLA cover these drivers.
Officially supported drivers include C, C++, C#, Go, Java, Kotlin, Node.js, PHP, Python, Ruby, Rust, Scala, and Swift.
Community Drivers
Third-party developers create and maintain these drivers, which implement MongoDB's published specifications or wire protocol. Examples include Zookzook (Elixir), Mango (Dart), mongolite (R), and mgo (Go).
Unsupported Configurations
Any officially supported or community driver used at an end-of-life version.
Support Levels
Officially Supported Drivers (Current Version)
The Atlas SLA covers these drivers. MongoDB provides standard troubleshooting and resolution, including investigation and fixes for connection issues.
Officially Supported Drivers (EOL Version)
MongoDB provides best-effort support. MongoDB investigates issues but might recommend upgrading to a current version.
Community Drivers
MongoDB provides best-effort, diagnosis-only support. Support helps you determine whether an issue originates from the platform or the driver. For driver-side issues, MongoDB provides available guidance and refers you to the driver maintainer. MongoDB does not debug or patch community driver code.
Responsibilities
What |service| Does
Atlas performs risk assessments for platform changes that affect the connection layer, including TLS version changes, certificate rotations, and authentication mechanism updates. Atlas assesses known fragility patterns even when the fragility originates in client-side code.
For high-risk platform changes, Atlas publishes guidance in release notes and pre-maintenance notifications when feasible.
What |service| Does Not Do
Atlas does not:
Test, certify, or guarantee the correctness of community drivers
Test all community drivers in all configurations
Commit to patching, reviewing, or maintaining community drivers
Community drivers must correctly implement TLS negotiation, authentication, wire protocol, and failover behavior. Any contributions MongoDB makes to community drivers are voluntary, not contractual obligations.
SLA Coverage
The Atlas SLA covers officially supported MongoDB drivers at current versions only. Outages caused by community driver bugs or unsupported driver configurations fall outside the SLA.
Use officially supported drivers at current versions for full SLA coverage and the best support experience.