> For the complete MongoDB documentation index, see www.mongodb.com/docs/llms.txt # Configure Security Features for Clusters **Note:** This page applies to both Atlas Infinite and Atlas Core. You can use Atlas securely out of the box. Atlas comes preconfigured with secure default settings. You can fine-tune the security features for your clusters to meet your unique security needs and preferences. Review the following security features and considerations for clusters. To learn about recommendations for Atlas network security, see [Recommendations for Atlas Network Security](https://www.mongodb.com/docs/atlas/architecture/current/network-security.md#std-label-arch-center-network-security-recs) in the Atlas Architecture Center. **Note:** The MongoDB Atlas Shared Responsibility Model defines the complementary duties of MongoDB and its customers in maintaining a secure and resilient data environment. Under this framework, MongoDB manages the security and operational integrity of the underlying platform, while customers are responsible for the configuration, management, and data policies of their specific deployments. For a detailed breakdown of ownership across security and operational excellence, see [Shared Responsibility Model.](https://www.mongodb.com/resources/products/fundamentals/shared-responsibility) **Important:** As a security best practice, don't include sensitive information in namespaces and field names. Atlas doesn't obfuscate this information. ## Preconfigured Security Features The following security features are part of the Atlas product: ### Encryption in Transit Atlas requires TLS (Transport Layer Security) to encrypt the connections to your databases. TLS (Transport Layer Security) certificates are: - Valid for 90 days from the day Atlas issues the certificate. - Rotated 42 days before the certificate's expiration date. To learn more about TLS encryption, see the [Atlas Security White Paper.](https://www.mongodb.com/resources/products/capabilities/mongodb-atlas-security?tck=docs) To configure SSL or TLS OCSP certificate revocation checking, see [OCSP Certificate Revocation Check.](https://www.mongodb.com/docs/atlas/setup-cluster-security.md#std-label-oscp-cert-check) ### Virtual Private Cloud All Atlas projects with one or more M10+ dedicated clusters receive their own dedicated VPC (Virtual Private Cloud) (or VNet if you use Azure (Microsoft Azure)). Atlas deploys all dedicated clusters inside this VPC (Virtual Private Cloud) or VNet. ### Encryption at Rest By default, Atlas encrypts all clusters storage and snapshot volumes at rest using Advanced Encryption Standard (AES)-256. On Atlas Core clusters, your cloud provider automates this disk encryption and manages the encryption keys. Atlas also supports [Encryption at Rest with Customer-Managed Keys.](https://www.mongodb.com/docs/atlas/security-kms-encryption.md#std-label-security-kms-encryption) ### FIPS (Federal Information Processing Standard Publication) 140-2 Atlas disables FIPS (Federal Information Processing Standard Publication) 140-2 Level 2 for all databases by default. If your environment requires that you enable it in Atlas, use MongoDB Atlas for Government. MongoDB Atlas for Government automatically enables FIPS (Federal Information Processing Standard Publication) 140-2 Level 2 for all databases. ## Required Security Features You *must* configure the following security features: ### Network and Firewall Requirements Make sure your application can reach your MongoDB Atlas environment. To add the inbound network access from your application environment to Atlas, do one of the following: 1. Add the public IP addresses to your IP access list 2. Use [VPC / VNet peering](https://www.mongodb.com/docs/atlas/security-vpc-peering.md#std-label-vpc-peering) to add private IP addresses. 3. Add [private endpoints.](https://www.mongodb.com/docs/atlas/security-configure-private-endpoints.md#std-label-private-endpoint) **See also:** [IP Access List](https://www.mongodb.com/docs/atlas/setup-cluster-security.md#std-label-security-ip-access-list) If your firewall blocks outbound network connections, you must also open outbound access from your application environment to Atlas. You must configure your firewall to allow your applications to make outbound connections to ports 27015 to 27017 to TCP (Transmission Control Protocol) traffic on the hostnames or IP addresses of your cluster. This grants your applications access to databases stored on Atlas. To obtain the current list of cluster IP addresses, use the [Return All IP Addresses for One Project endpoint](https://www.mongodb.com/docs/api/doc/atlas-admin-api-v2/operation/operation-getgroupipaddresses) of the Atlas Administration API. ```text curl --header "Authorization: Bearer " \ --header "Accept: application/vnd.atlas.2025-03-12+json" \ --request GET \ "https://cloud.mongodb.com/api/atlas/v2/groups/{GROUP-ID}/ipAddresses" ``` **See also:** [Add Project Access from a Project](https://www.mongodb.com/docs/atlas/configure-api-access.md#std-label-create-project-api-key) **Note:** By default, MongoDB Atlas clusters do not need to be able to initiate connections to your application environments. If you wish to enable Atlas clusters with [LDAP authentication and authorization](https://www.mongodb.com/docs/atlas/security-ldaps.md#std-label-ldaps-authentication-authorization), you must allow network access from Atlas clusters directly to your secure LDAP (Lightweight Directory Access Protocol). You can allow access to your LDAP (Lightweight Directory Access Protocol) by using public or private IPs as long as a public DNS (Domain Name System) hostname points to an IP that the Atlas clusters can access. If you are not using [VPC / VNet peering](https://www.mongodb.com/docs/atlas/security-vpc-peering.md#std-label-vpc-peering) and plan to connect to Atlas using public IP addresses, see the following pages for additional information: - [Can I specify my own VPC for my MongoDB Atlas project?](https://www.mongodb.com/docs/atlas/reference/faq/networking.md#std-label-faq-atlas-side-hostnames) - [Do Atlas cluster's public IPs ever change?](https://www.mongodb.com/docs/atlas/reference/faq/networking.md#std-label-faq-public-ip-changes) ### IP Access List Atlas only allows client connections to the cluster from entries in the project's IP access list. To connect, you must add an entry to the IP access list. To set up the IP access list for the project, see [Configure IP Access List Entries.](https://www.mongodb.com/docs/atlas/security/ip-access-list.md#std-label-add-to-access-list) For Atlas clusters deployed on [Google Cloud](https://www.mongodb.com/docs/atlas/reference/google-gcp.md#std-label-google-gcp) or [Microsoft Azure](https://www.mongodb.com/docs/atlas/reference/microsoft-azure.md#std-label-microsoft-azure), add the IP (Internet Protocol) addresses of your Google Cloud or Azure (Microsoft Azure) services to Atlas project IP (Internet Protocol) access list to grant those services access to the cluster. ### User Authentication or Authorization Atlas requires clients to authenticate to connect to the database. You must create database users to access the database. To set up database users to your clusters, see [Configure Database Users](https://www.mongodb.com/docs/atlas/security-add-mongodb-users.md#std-label-mongodb-users). Atlas offers many security features for [cluster authentication and authorization.](https://www.mongodb.com/docs/atlas/setup-cluster-security.md#std-label-db-deployment-auth) To access clusters in a project, users must belong to that project. Users can belong to multiple projects. **See also:** [Configure Access to the Atlas UI.](https://www.mongodb.com/docs/atlas/organizations-projects.md#std-label-atlas-access) ## Optional Security Features You *may* configure the following security features: ### Network Peering Connection Atlas supports peering connections with other AWS (Amazon Web Services), Azure (Microsoft Azure), or Google Cloud network peering connections. To learn more, see [Network Peering.](https://www.mongodb.com/docs/atlas/security-vpc-peering.md#std-label-vpc-peering) **Important:** If this is the first `M10+` dedicated paid cluster for the selected region or regions *and* you plan on creating one or more VPC peering connections, please review the documentation on VPC peering connections before continuing. ### Private Endpoints Atlas supports private endpoints on: - AWS (Amazon Web Services) using the [AWS PrivateLink](https://aws.amazon.com/privatelink/) feature - Azure (Microsoft Azure) using the [Azure Private Link](https://azure.microsoft.com/en-us/services/private-link/) feature - Google Cloud using the [GCP Private Service Connect](https://cloud.google.com/vpc/docs/private-service-connect) feature To use private endpoints, see [Learn About Private Endpoints in Atlas.](https://www.mongodb.com/docs/atlas/security-private-endpoint.md#std-label-private-endpoint-concepts) ### Unified AWS Access Some Atlas features, including [Data Federation](https://www.mongodb.com/docs/atlas/data-federation.md#std-label-atlas-data-federation) and [Encryption at Rest using Customer Key Management](https://www.mongodb.com/docs/atlas/security-kms-encryption.md#std-label-security-kms-encryption), use AWS (Amazon Web Services) [IAM roles](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use.html) for authentication. To set up an AWS (Amazon Web Services) IAM role for Atlas to use, see [Set Up Unified AWS Access.](https://www.mongodb.com/docs/atlas/security/set-up-unified-aws-access.md#std-label-set-up-unified-aws-access) ### Cluster Authentication and Authorization Atlas offers the following security features for cluster authentication and authorization. #### Database User Authentication or Authorization Atlas requires clients to authenticate to access clusters. You must create database users to access the database. To set up database users for your clusters, see [Configure Database Users.](https://www.mongodb.com/docs/atlas/security-add-mongodb-users.md#std-label-mongodb-users) #### Custom Roles for Database Authorization Atlas supports creating [custom roles](https://www.mongodb.com/docs/atlas/security-add-mongodb-roles.md#std-label-mongodb-roles) for database authorization in cases where the built-in Atlas [roles](https://www.mongodb.com/docs/manual/reference/built-in-roles.md#std-label-atlas-user-privileges) don't grant your desired set of privileges. #### Authentication with AWS IAM You can set up authentication and authorization for your AWS (Amazon Web Services) IAM (Identity and Access Management) roles. To learn more, see [AWS IAM Authentication.](https://www.mongodb.com/docs/atlas/security/aws-iam-authentication.md#std-label-set-up-pwdless-auth) #### User Authentication or Authorization with LDAP (Lightweight Directory Access Protocol) Atlas supports performing user authentication and authorization with LDAP (Lightweight Directory Access Protocol). To use LDAP (Lightweight Directory Access Protocol), see [Set Up User Authentication and Authorization with LDAP.](https://www.mongodb.com/docs/atlas/security-ldaps.md#std-label-security-ldaps) #### User Authentication with X.509 X.509 client certificates provide database users access to the clusters in your project. Options for X.509 authentication include Atlas-managed X.509 authentication and self-managed X.509 authentication. To learn more about self-managed X.509 authentication, see [Set Up Self-Managed X.509 Certificates.](https://www.mongodb.com/docs/atlas/security-self-managed-x509.md#std-label-self-managed-x509) #### Restrict MongoDB Support Access to Atlas Backend Infrastructure Organization owners can restrict MongoDB Production Support Employees from accessing Atlas backend infrastructure for any Atlas cluster in their organization. Organization owners may grant a 24 hour bypass to the access restriction at the Atlas cluster level. **Important:** Blocking infrastructure access from MongoDB Support may increase support issue response and resolution time and negatively impact your cluster's availability. To enable this option, see [Configure MongoDB Support Access to Atlas Backend Infrastructure.](https://www.mongodb.com/docs/atlas/security-restrict-support-access.md#std-label-restrict-access) ### Encryption at Rest using your Key Management Atlas supports using AWS (Amazon Web Services) KMS (Key Management Service), Azure Key Vault, and Google Cloud to encrypt storage engines and cloud provider backups. To use encryption at rest, see [Encryption at Rest using Customer Key Management.](https://www.mongodb.com/docs/atlas/security-kms-encryption.md#std-label-security-kms-encryption) ### Client-Side Field Level Encryption Atlas supports [client-side field level encryption](https://www.mongodb.com/docs/manual/core/security-client-side-encryption/), including [automatic](https://www.mongodb.com/docs/manual/core/security-automatic-client-side-encryption/) encryption of fields. All Atlas users are entitled to use MongoDB automatic client-side field level encryption features. To learn more, see [Client-Side Field Level Encryption Requirements.](https://www.mongodb.com/docs/drivers/security/client-side-field-level-encryption-guide/#requirements) **Note:** [MongoDB Compass](https://www.mongodb.com/docs/compass/current/), the [Atlas UI](https://www.mongodb.com/docs/atlas/atlas-ui.md#std-label-atlas-ui), and the [MongoDB Shell](https://www.mongodb.com/docs/mongodb-shell/) (`mongosh`) do not support decrypting client-side field level-encrypted fields. **See also:** - [Client-Side Field Level Encryption](https://www.mongodb.com/docs/manual/core/security-client-side-encryption/) - [Use-Case Guide for Client-Side Field Level Encryption](https://www.mongodb.com/docs/drivers/security/client-side-field-level-encryption-guide/) ### Database Auditing Atlas supports auditing all system event actions. To use database auditing, see [Set up Database Auditing.](https://www.mongodb.com/docs/atlas/database-auditing.md#std-label-set-up-database-auditing) ### Access Tracking Atlas surfaces authentication logs directly in the Atlas UI so that you can review successful and unsuccessful authentication attempts made against your clusters. To view your database access history, see [View Database Access History.](https://www.mongodb.com/docs/atlas/access-tracking.md#std-label-access-tracking) ### Multi-Factor Authentication for Atlas UI Access Atlas supports MFA (multi-factor authentication) to help you control access to your Atlas accounts. To set up MFA (multi-factor authentication), see [Manage Your Multi-Factor Authentication Options.](https://www.mongodb.com/docs/atlas/security-multi-factor-authentication.md#std-label-atlas-enable-mfa) ### Allow Access to or from the Atlas Control Plane If you use any of the following Atlas features, you might have to add Atlas IP addresses to your network's IP access list: - [Alert Webhooks](https://www.mongodb.com/docs/atlas/tutorial/third-party-service-integrations.md#std-label-third-party-integrations) - [Encryption at Rest using Customer Key Management](https://www.mongodb.com/docs/atlas/security-kms-encryption.md#std-label-security-kms-encryption) - [LDAP Authentication or Authorization](https://www.mongodb.com/docs/atlas/security-ldaps.md#std-label-security-ldaps) **Note:** If you enable the [Encryption at Rest](https://www.mongodb.com/docs/atlas/scale-cluster.md#std-label-scale-cluster-enable-encryption) feature, you must allow access from public IPs for all your hosts in your deployment, including [CSRS (Config Server Replica Sets)](https://www.mongodb.com/docs/manual/core/sharded-cluster-config-servers.md#std-label-replset-config-servers) if you are using [sharded clusters.](https://www.mongodb.com/docs/manual/reference/glossary.md#std-term-sharded-cluster) #### Fetch Atlas Control Plane IP Addresses Send a GET request to the `controlPlaneIPAddresses` endpoint to fetch the current Atlas control plane IP addresses. The [API endpoint](https://www.mongodb.com/docs/api/doc/atlas-admin-api-v2/operation/operation-listcontrolplaneipaddresses) returns a list of inbound and outbound Atlas control plane IP addresses in CIDR (Classless Inter-Domain Routing) notation categorized by cloud provider and region, similar to the following: ```json { "inbound":{ "aws":{ "":["", ...], ... }, "azure":{ "":["", ...], ... }, "gcp":{ "":["", ...] ... } }, "outbound":{ "aws":{ "":["", ...], ... }, "azure":{ "":["", ...], ... }, "gcp":{ "":["", ...], ... } }, "gateways":{ "aws":{ "":["", ...], ... }, "azure":{ "":["", ...], ... }, "gcp":{ "":["", ...], ... } } } ``` **Important:** The Atlas Administration API uses the terms `inbound` and `outbound` in relation to the control plane, not your network. As a result: - Your network's **inbound** rules must match the `outbound` CIDRs listed in the Atlas Administration API. - Your network's **outbound** rules must match the `inbound` CIDRs listed in the Atlas Administration API. The following diagram shows the relationship between `inbound` and `outbound` for the control plane and your network: ![A diagram showing that inbound traffic for the control plane reflects outbound traffic from your network, and outbound traffic for the control plane reflects inbound traffic to your network.](/images/ControlPlaneInboundVsOutbound.svg) To add the returned IP addresses to your cloud provider's KMS IP access list, see the prerequisites for managing customer keys with [AWS](https://www.mongodb.com/docs/atlas/security/aws-kms-over-public-network.md#std-label-aws-ksm-prereqs), [Azure](https://www.mongodb.com/docs/atlas/security/azure-kms-over-public-network.md#std-label-azure-kms-prereqs), and [GCP.](https://www.mongodb.com/docs/atlas/security-gcp-kms.md#std-label-gcp-kms-prereqs) **Important:** Atlas may update its control plane IP addresses over time. To ensure continued connectivity between Atlas and your KMS, periodically fetch the current control plane IP addresses and update your KMS access list. #### Required Access: `controlPlane.outbound` IP Addresses `controlPlane.outbound` lists the IP addresses of traffic coming from the control plane. Your network's **inbound** HTTP IP address list must allow access from the IP addresses listed in `controlPlane.outbound`. We recommend that you [use the Atlas Admin API](https://www.mongodb.com/docs/atlas/setup-cluster-security.md#std-label-atlas-fetch-control-plane-ips) to fetch the current outbound Atlas control plane IP addresses. #### Required Access: `controlPlane.inbound` IP Addresses `controlPlane.inbound` lists the IP addresses traffic coming into the control plane. If your network allows **outbound** HTTP requests only to specific IP addresses, you must allow access to the IP addresses listed in `controlPlane.inbound` so that Atlas can communicate with your webhooks and KMS (Key Management Service). We recommend that you [use the Atlas Admin API](https://www.mongodb.com/docs/atlas/setup-cluster-security.md#std-label-atlas-fetch-control-plane-ips) to fetch the current inbound Atlas control plane IP addresses. #### Required Access: `gateways` IP Addresses `gateways` lists the IP addresses of traffic routed through the Atlas Gateway. If you have IP restriction policies on services that Atlas connects to through the gateway, you must allow inbound access from the IP addresses listed in `gateways` in addition to the control plane IP addresses. Include all gateway IP addresses from all regions, regardless of where your clusters are deployed. We recommend that you use the [Atlas Admin API](https://www.mongodb.com/docs/atlas/setup-cluster-security.md#std-label-atlas-fetch-control-plane-ips) to fetch the current Atlas gateway IP addresses. **Important:** Atlas may update its gateway IP addresses over time. To ensure continued connectivity, periodically fetch the current gateway IP addresses and update your access list. ### Allow Access to Data Federation If your network allows outbound HTTPS requests only to specific IP addresses, you must allow access from the inbound IP addresses on TCP (Transmission Control Protocol) port 27017 so that your requests can reach the federated database instance. We recommend that you [use the Atlas Admin API](https://www.mongodb.com/docs/api/doc/atlas-admin-api-v2/operation/operation-listcontrolplaneipaddresses) to fetch the current inbound Atlas control plane IP addresses. ### OCSP Certificate Revocation Check If your network allows outbound requests to specific IP addresses only, to allow SSL (Secure Sockets Layer) or TLS (Transport Layer Security) OCSP (Online Certificate Status Protocol) certificate revocation checking, you must allow access to Atlas' CA (Certificate Authority) OCSP (Online Certificate Status Protocol) Responder servers that can be found in the OCSP (Online Certificate Status Protocol) URL (Uniform Resource Locator) of the SSL (Secure Sockets Layer) or TLS (Transport Layer Security) certificate. To disable OCSP (Online Certificate Status Protocol) certificate revocation checking, refer to the documentation for the [MongoDB driver](https://www.mongodb.com/docs/drivers/) version that your application uses. OCSP behavior depends on the certificate provider. Revocation checking occurs only when a certificate contains an OCSP responder URL (Uniform Resource Locator). **Note: Let's Encrypt OCSP Deprecation** [Let's Encrypt has ended OCSP support](https://letsencrypt.org/2024/12/05/ending-ocsp/) for newer certificates. As a result, certificates issued by Let's Encrypt might not include an OCSP responder URL (Uniform Resource Locator). This is expected and doesn't by itself indicate a problem with your Atlas cluster. If you see OCSP-related warnings after rotating to a Let's Encrypt certificate, first verify whether the new certificate includes an OCSP URL (Uniform Resource Locator).