mLab takes the security of mLab accounts and deployments seriously and is continuously working to provide features and tools that increase the safety of your account and data.

Database and network security

Securely accessing and communicating with an mLab database involves not just having the proper credentials but proper placement of all entities that connect to your database. Custom firewall rules can also be configured for select deployments, limiting the ability of non-trusted entities to gain access to your database.

Database authentication

All mLab database servers are run in “auth mode” (mongod run with the –auth flag). Before the database can be accessed, you will need to create a database user and password in order to authenticate against the database.

Deployments running with MongoDB release version 3.0 and above are using Salted Challenge Response Authentication Mechanism or SCRAM as their authentication mechanism (see MongoDB’s documentation on SCRAM-SHA-1).

Securing communications to your database

You should always try to place your application infrastructure and your database in the same local network (i.e., datacenter/cloud region), as it will be the most secure method of deployment and will minimize latency between your application and database.

When you connect to your mLab database from within the same datacenter/region, you communicate over your cloud hosting provider’s internal network. All of our cloud hosting providers provide a good deal of network security infrastructure to isolate tenants. The hypervisors used do not allow VMs to read network traffic addressed to other VMs and therefore no other tenant can “sniff” your traffic.

However, when you connect to your mLab database from a different datacenter/region, your communications are less secure. While your database does require username/password authentication (with credentials that are always encrypted on the network), the rest of your data is transmitted unencrypted over the open internet. As such you are potentially vulnerable to others “sniffing” your traffic.

Using MongoDB with SSL connections

Available for Dedicated plans only

To further secure communications to your database, mLab offers SSL for MongoDB connections on Dedicated plans. Even when using SSL, we still recommend placing your application infrastructure and your database in the same datacenter/region to minimize latency and add another layer of security.

Configuring custom firewalls

Available for Dedicated plans only

Dedicated plans offer the ability for you to define custom firewall rules so that your database only allows network access from your application infrastructure. Access can be limited to specific IP address ranges and/or to Amazon EC2 Security Groups (AWS only).

Whitelisting IP addresses

mLab can configure your firewall to limit access to only the IP address(es) (or address ranges) you specify. We use CIDR rules to define the allowable address(es) and secure access to your mLab-hosted Dedicated plan databases.

Follow these instructions to add an IP address:

  1. Log in to the mLab management portal.
  2. Navigate to the MongoDB deployment that you wish to secure.
  3. Click the “Networking” tab.
  4. Click the “Add IP rule(s)” button.
  5. Enter the IP address and an optional description for the rule. img-firewallip
  6. Click the “Add” button.

Whitelisting Amazon EC2 Security Groups (AWS only)

If you’re interested in AWS VPC Peering, please visit our documentation on our Private Environments feature.

If your Dedicated plan deployment is hosted in AWS, you may also allow access to a Security Group. If your deployment is in EC2-Classic, note that the Security Group that you allow must also be in EC2-Classic. If your deployment is in EC2-VPC, note that the Security Group that you allow must be in peered VPC.

To control access to your mLab-hosted database using your EC2 Security Group, you’ll need to provide your AWS account ID (a 12-digit number) and Security Group ID (begins with “sg-“).

Follow these instructions to add a Security Group:

  1. Log in to the mLab management portal.
  2. Navigate to the MongoDB deployment that you wish to secure.
  3. Click the “Networking” tab.
  4. Click the “Add Security Group rule” button.
  5. Enter your AWS account ID, Security Group ID and an optional description.
  6. Click the “Add” button.

Are you using Heroku Private Spaces? If so, you’ll be able to whitelist and/or set up VPC Peering between your Heroku Private Space and your mLab Environment.

Copying rules from another deployment

For convenience, you can use the “Copy existing rules” button to copy rules already added to another deployment in your mLab account. This saves you the effort of having to add each rule and/or Security Group one by one for all the deployments in your account.


Data security: Encryption at Rest

The content contained herein is correct for deployments created on or after February 2, 2017. mLab’s security policies and systems may change going forward, as we continually improve protection for our customers and their data.

Data disk encryption


Shared plans

On AWS Shared plans, mLab uses Amazon EBS encryption. Shared plan databases created before June 20, 2018 may not be hosted on encrypted disks.

To check whether your deployment’s disk(s) are encrypted, expand the deployment’s description on the mLab management portal Home page. In the set of details that appears, you will see “DISK: Encrypted” if the deployment is running on encrypted disk(s).

To migrate an existing Shared plan deployment to encrypted disks, contact for assistance.

Dedicated plans

On AWS Dedicated plans, mLab offers the option to use Amazon EBS encryption on EBS-backed Dedicated plans (i.e., Standard and High Storage lines). High Performance line plans using local SSDs might not support encryption at rest; contact for details.

For a new deployment, you must select the “Data Disk Encryption” option in the “Security Options” form to enable this feature.

For an existing deployment, follow the steps below but before you start, you may want to first read about mLab’s rolling node replacement process which is the process we will use to encrypt your disks:

  1. Log in to the mLab management portal.
  2. From your account’s Home page, navigate to the deployment whose disks you want to encrypt.
  3. Click the “Tools” tab.
  4. Under the “Initiate maintenance operation” header, select the “Encrypt disks” option.
  5. Select a failover option in the “Failover Preference” section.
  6. Click the “Encrypt disks” button and confirm that you want to proceed. This will automatically initiate a rolling node replacement to encrypt your disks.
    • If you choose the “Manual Failover” option, you will need to check email for maintenance updates after the operation starts which will indicate when to perform the failover. The emails will be sent to the user that initiated the request as well as the Technical Contact specified for your mLab account.

To check that your deployment’s disk(s) are encrypted, expand the deployment’s description on the mLab management portal Home page. In the set of details that appears, you will see “(encrypted)” at the end of the disk description.



On Dedicated plans running in mLab’s newer Azure offering, Azure 2, the disks are always encrypted. At this time, mLab’s other plans on Azure do not support encryption at rest.

Google Cloud Platform

On Google Cloud Platform, data is always stored encrypted at rest.

Backup encryption


When using mongodump:

When using block storage snapshot:

Restore considerations

For restores of backups taken using mongodump, whether the target for the restore is encrypted depends on whether the target has disk encryption enabled.

For restores of backups taken using block storage snapshots, the target of the restore will be encrypted if the volume from which the snapshot was taken was encrypted.

Web management portal security

The mLab management portal is run entirely over HTTPS.

Account-level security settings

The mLab management portal offers a number of security-related settings that determine what users can or cannot do in terms of securing their user profiles and other mLab features. In this section we provide instructions on how to set these global security options as well as an explanation for each of the available options.

Adjusting the account-level security settings

The Admin User of an account is the only user who can adjust the account-level security settings. All users on the account, including the Admin User, are subject to these settings.

To adjust the account-level security settings, the Admin User can follow these instructions:

  1. Log in to the mLab management portal.
  2. Click “Account” in the upper right-hand corner to open the Account Settings page.
  3. Click the “Security” tab to display the Security Settings page.
  4. Make changes to each of the available options as desired.
  5. Click the “Save changes” button to save any updates.


Account-level security settings explained

Two-factor authentication

Username recovery

Password reset

Data API access

The mLab Data API is no longer available for new and inactive users.

Two-factor authentication

Available only for accounts created via

Two-factor authentication provides an extra layer of security for your mLab account and can be enabled on a per-user basis. Each account user who has activated the feature will be prompted for more than just a password when logging in to A second piece of information is also required (hence, two-factor) which in mLab’s case is an authentication code that can be retrieved from an application that the user installs on a mobile phone or device. Requiring two separate pieces of information (a password and an authentication code) helps protect your mLab account from unauthorized access.

Even though it is an optional feature, we strongly recommend that you enable it for your mLab account.

Enable two-factor authentication

Before you follow the instructions below, if you do not already have an authenticator application installed on your mobile phone/device, you will need to install one. Any application that supports the Time-based One-Time Password (TOTP) protocol should work, for example the Google Authenticator which works on iOS, Android, and Blackberry devices or Authenticator for Windows Phone 7 which works for Windows Phone devices.

  1. Log in to the mLab management portal.
  2. Click your username (not the account name) in the upper right-hand corner to open your account user profile.
  3. In the section titled “Two-Factor Authentication”, follow the instructions to activate this setting.
  4. Check your inbox to confirm you have received an email reporting successful enablement of two-factor authentication.
  5. Set up a fallback SMS number (required for Admin Users, optional for non-admin users).

It is important to keep your fallback SMS number up-to-date. Without a valid and accessible fallback number, then you will permanently lose the ability to access your mLab account if your authenticator application is also deleted, lost, or stolen. You would then need to manually migrate your data to a new account which will probably entail significant downtime for your application.

Fallback SMS number

If you do not have access to your authenticator application, a fallback SMS number is a secondary mechanism by which mLab can deliver the authentication code to you. This feature is mandatory for Admin Users who have enabled two-factor authentication for their user login. For non-admin users, this is an optional though strongly recommended feature.

To use this feature, add your fallback SMS number to your account profile, as part of the two-factor authentication setup process. If you set the fallback SMS number correctly, you will receive an SMS message confirming that the number has been configured as your fallback number. If you do not receive the confirmation message, this means that you will not receive a code via SMS.

For international numbers, please be sure to include your country code up front. For example, if your country code is 55, you would set the fallback SMS number as +551155256325.

Once your fallback SMS number is set up and confirmed, you can request an authentication code at any time by clicking the “Send the code via SMS” link that appears on the screen where you would typically enter your authentication code.

API security

Connecting to your database via our API is secured via HTTPS and an API key.

Be sure to read this section on API authentication to learn more about security as it relates to mLab’s RESTful Data API.