MongoDB Atlas Credentials Security Guide

MongoDB Atlas runs on two separate credential planes, and teams that secure one while ignoring the other leave the data reachable. Database users authenticate to clusters and read or write documents, while service accounts and API keys drive the Atlas Administration API, which can create those database users, change network rules and restore backups. This guide explains how each plane works, which roles carry real privilege, how to move applications from long-lived passwords to federated or certificate authentication, and what to log and measure. It is written for platform engineers, database administrators and NHI owners who run Atlas in production. For engine-level hardening of self-managed MongoDB, see the MongoDB Security Guide.

Key takeaways

Two planes, two credential sets. Database users reach cluster data; service accounts and API keys reach the control plane, which cannot read documents directly but can create a database user that can.
Prefer secretless authentication for workloads. Atlas supports AWS IAM roles, OIDC Workload Identity Federation (MongoDB 7.0 and later) and X.509, so a static SCRAM password should be the exception in production.
Service accounts replace API keys. MongoDB documents API keys as the legacy method; service accounts issue one hour OAuth 2.0 tokens from a client secret that expires between 8 hours and 365 days.
Network controls are a second lock, not the first. The project IP access list, the API access list and private endpoints limit where a stolen credential can be used, but they do not replace credential hygiene.
Logging is opt-in and short-lived. Database auditing is off by default and unavailable on Free and Flex tiers, and Database Access History keeps only 7 days, so export logs if you want an investigation trail.

How identity and access work in MongoDB Atlas

Atlas has a hierarchy of organisation, project and cluster. Human Atlas users and programmatic identities get organisation and project roles that govern the Atlas UI and Administration API. Separately, each project holds a set of database users that applications use to connect to clusters with a driver, mongosh or Compass. The two sets do not overlap: per MongoDB's API authentication documentation, service accounts and API keys cannot log in to the Atlas UI and cannot read or write cluster data, but the Administration API can create and manage database users.

Credential	Plane	What it authenticates to	Lifetime	Main risk if leaked
Database user, SCRAM-SHA-256 password	Data	Clusters in the project (auth database `admin`)	Static until changed	Direct read and write of data from any allowed network
Database user, X.509 certificate	Data	Clusters (auth database `$external`)	Certificate validity	Private key theft (ATT&CK T1552.004)
Database user, AWS IAM role or user ARN	Data	Clusters (`$external`)	Short-lived AWS session credentials	Abuse of the cloud role that holds the mapping
Database user, OIDC Workload Identity Federation	Data	Clusters on MongoDB 7.0+ (`$external`)	IdP token lifetime	Compromise of the Azure managed identity or Google service account
Temporary database user	Data	Clusters	Expires within a configurable period of up to 7 days	Limited by expiry
Service account (client ID and secret)	Control	Atlas Administration API	Secret 8 hours to 365 days; access token 1 hour	Creation of new database users, network changes, persistence
Programmatic API key (public and private key)	Control	Atlas Administration API (HTTP Digest)	Static until deleted	As above, with no built-in expiry

The authentication method decides how much secret material sits in your application. MongoDB's database user documentation describes SCRAM as suitable for lower environments and points production users toward stronger patterns: AWS IAM roles for applications on AWS, Workload Identity Federation for applications on Azure or Google Cloud, and Workforce Identity Federation for people. If you cannot use any of them, fetch the SCRAM password at runtime from a secrets manager rather than baking it into a connection string. See the Workload Identity Federation Guide.

Scoping database users

Built-in roles are project wide: assigning a built-in role adds the user to every cluster in the project. Use Restrict Access to Specific Clusters, specific privileges or custom roles to narrow it.
One user per application and environment: a shared app user across services makes attribution and rotation impossible. Atlas allows up to 100 database users per project, which is a practical reason to separate environments into projects.
Manage users only through Atlas: users created directly with db.createUser() are rolled back; use the UI, Atlas CLI (atlas dbusers create), the Administration API or a supported integration such as Terraform.
Temporary users for people: break-glass and support access should use temporary users with the shortest expiry that fits the task.

Admin roles and privileged access

Atlas organisation and project roles decide who can mint credentials. Several look harmless but carry escalation paths, so map them as privileged access. See the Database Credential and Access Security Guide for the general model.

Role	Scope	Why it matters for credentials	Treat as
Organization Owner	Organisation	Root access; gets Project Owner on every project; creates service accounts and API keys; manages secrets of cross-project service accounts	Tier 0, 2 to 3 named people, phishing-resistant MFA
Project Owner	Project	Full project access including Data Explorer, database users and network access	Privileged
Project Access Manager	Project	No data access, but MongoDB warns it can raise its own privileges to Project Owner	Privileged, despite the name
Project Database Access Admin	Project	Creates database users and custom roles; no Data Explorer, but can create a user that reads everything	Privileged
Project Network Access Manager	Project	Edits IP access lists, peering and Private Link; can open the cluster to the internet	Privileged
Project Data Access Admin / Read/Write / Read Only	Project	Read or change documents through the Data Explorer in the UI	Data access, review quarterly
Project Backup Manager	Project	Can restore data to clusters	Privileged for integrity
Project Read Only / Organization Read Only	Either	Views settings, users and activity; no Data Explorer	Standard

Federate human access: use Atlas federated authentication with your IdP so joiner, mover and leaver events flow automatically, and enforce MFA at the IdP.
Restrict the UI separately: the project IP access list does not block the Atlas UI. Configure the organisation's UI IP Access List or IdP authentication policies if you need to limit where admins sign in.
Keep Organization Owner rare: Organization Owners must add themselves as Project Owner to manage project network access, so day-to-day work should run under project roles.

Integrations, API tokens and service accounts

Terraform, CI pipelines, backup tooling, monitoring and increasingly AI agents talk to Atlas through the Administration API. Every one is a non-human identity with an owner, a purpose and an expiry. See the Service Account Security Guide.

Service accounts versus API keys

Property	Service account	Programmatic API key
MongoDB status	Recommended	Legacy
Protocol	OAuth 2.0 Client Credentials, bearer access token	HTTP Digest with public and private key
Token or secret lifetime	Secret expires 8 hours to 365 days; token valid 1 hour, not refreshable	No expiry
Rotation	Generate a new secret, then revoke the old; the old secret is cut to 7 days after the new one is created	Create a new key pair, update clients, delete the old pair
Expiry warning	Alert "Service Account Secrets are about to expire"	None
Scope	One organisation, any number of its projects, by role	One organisation, any number of its projects, by role
Network restriction	API access list applies to token use	API access list applies

Inventory: list every service account and API key per organisation with its roles, projects, access list entries and owner. Atlas adds keys created from a project to the organisation as Organization Member, so check both levels.
Grant project roles, not organisation roles: a Terraform pipeline for one project needs Project Owner on that project at most, and often only Project Database Access Admin plus Project Network Access Manager.
Turn on the API access list requirement: enable Require IP Access List for the Atlas Administration API in Organization Settings (it is mandatory for organisations created in the UI). Calls from unlisted addresses get HTTP 403. Note that a token can be generated from anywhere; only its use is restricted.
Know the gaps: per MongoDB, access lists do not apply to the Atlas CLI or to delegated access granted through Atlas App Connections (partner apps, Compass and MCP clients). If all API traffic must come from fixed addresses, leave delegated app access disabled.
Migrate keys to service accounts: create the service account with matching roles, set a secret expiry that matches your rotation cadence (90 days is a common choice), switch the client, then delete the API key.
Cache tokens properly: reuse the one hour token rather than requesting one per call, and revoke tokens you no longer need.
Store secrets in a vault: the client secret is shown once. Put it in a secrets manager and inject it at runtime. See the Secrets Management Guide.

Remember the indirect path: a control plane identity with Project Database Access Admin can create a database user and then read data with it (ATT&CK T1098.001 Additional Cloud Credentials describes the same persistence pattern in cloud control planes). Alert on database user creation by programmatic identities outside your pipeline.

Network access: IP access lists and private endpoints

Atlas only accepts client connections from entries on the project IP access list, which applies to every cluster in the project and holds up to 200 entries. Private endpoints give a stronger boundary. See the Database Security Guide for the wider network model.

Option	What it does	Availability	When to choose it
IP access list entry (single IP or CIDR)	Allows public internet connections from listed sources	All tiers	Development, small teams, SaaS integrations with fixed egress IPs
Temporary access list entry	Same, expiring within up to 7 days	All tiers	Admin troubleshooting from a home or travel IP
AWS security group of a peered VPC	Allows members of a security group over VPC peering	AWS with VPC peering	Autoscaling workloads on AWS where IPs change
Private endpoint (AWS PrivateLink, Azure Private Link, Google Private Service Connect)	Private connectivity from your cloud network; needs a private endpoint aware connection string	Dedicated clusters M10 and above; not Free or Flex	Production data with regulatory or zero trust requirements

Private endpoints do not close the public path: MongoDB notes that IP access list entries and peering keep working alongside a private endpoint. Remove public entries once clients use the private connection string, or the cluster stays internet reachable.
Removing an entry does not cut sessions: connections from a removed address may stay open for a variable time. During an incident, also delete or change the password of the affected database user.
Avoid 0.0.0.0/0: an allow-all entry turns every leaked connection string into a working one. The MongoBleed (CVE-2025-14847) flaw showed why reachability matters: it let unauthenticated clients read server memory, which can hold credentials. MongoDB patched the Atlas fleet before disclosure, but tens of thousands of internet-exposed self-managed servers were left to patch and rotate on their own.
Multi-region clusters: a private endpoint is needed in each region with a node, and multi-cloud clusters need extra arrangements, so plan connection strings before you remove public access.

Logging and detection

Atlas has three relevant sources, each with limits you should plan around.

Source	What it records	Limits	Use for
Project and organisation Activity Feed	Creation, deletion and updates of database users and IP access list entries, including temporary ones	Comment edits on access list entries are not reported; an address change shows as delete plus create	Control plane changes, new users, network openings
Database Access History	Authentication requests via drivers, `mongosh` and Compass: timestamp, username, client IP, host, auth source, result with failure reason	7 days only; not on Free or Flex; Administration API key requests not logged; may drop data during log spikes	Quick triage of who connected from where
Database auditing	`authenticate` (failed logins by default), `authCheck` read and write failures, `createUser`, `dropUser`, `directAuthMutation`	Off by default; not on Free or Flex; auditing all authorisation successes can severely affect performance	Durable, exportable evidence for the SIEM

Enable database auditing with at least the default authentication and authorisation failure actions plus user management, using Advanced > Database Auditing or atlas auditing update. Retrieve logs through the Administration API logs endpoint or the documented export to S3, and forward Activity Feed events into the same pipeline.

Detections worth building

New database user or role change outside the infrastructure-as-code pipeline identity.
Network opening: any new access list entry with a prefix shorter than /24, and any 0.0.0.0/0 entry.
Authentication from a new source IP for an application database user, or failures followed by success (T1078.004 Valid Accounts: Cloud Accounts).
Service account secret generated or API key created by a person rather than the onboarding workflow.
Large reads by an interactive user through Data Explorer roles (T1213 Data from Information Repositories).

Metrics

Static secret share: percentage of production database users on SCRAM passwords versus IAM, OIDC or X.509. Target a falling trend.
Legacy key count: programmatic API keys remaining per organisation. Target zero.
Secret age: maximum and median age of service account secrets and SCRAM passwords against policy.
Exposure: number of projects with public access list entries on clusters that have private endpoints.
Ownership: percentage of database users and service accounts with a named owner.
Audit coverage: percentage of production clusters with auditing enabled and logs reaching the SIEM.

Hardening baseline

Roll out in phases so applications do not break.

Discover (week 1 to 2): export database users, roles, access lists, private endpoints, service accounts and API keys per project with the Atlas CLI or API. Assign an owner to each. Use the Service Account Inventory Template.
Control plane first: federate human Atlas users, cut Organization Owners to a small group, enable the API access list requirement, and replace API keys with service accounts with expiring secrets.
Turn on visibility: enable database auditing on dedicated clusters and stream logs before you change data plane credentials, so you can see which users are still in use.
Pilot a secretless application: move one non-critical service to AWS IAM or Workload Identity Federation. Run old and new database users in parallel, confirm in Database Access History that the old user is idle, then delete it. Roll back by restoring the old connection string, which still works until the user is removed.
Scope and split: restrict each database user to its clusters and databases, separate environments into projects, and remove shared users.
Close the network: move production to private endpoints, then remove public access list entries in a change window. Keep a temporary entry procedure for break-glass.
Codify: manage users, roles and access lists in Terraform or another supported integration so drift appears in review.

Choosing an approach by size

Small teams on shared or Flex tiers: private endpoints and auditing are not available, so lean on strong generated SCRAM passwords from a vault, narrow access list entries and a single service account per pipeline.
Larger estates on dedicated clusters: standardise on IAM or OIDC for applications, private endpoints for production, organisation-level federation and SIEM-fed auditing.
X.509 versus federation: X.509 suits environments with mature PKI or on-premises clients; note that Atlas-managed X.509 users cannot connect when LDAP authorisation is enabled. Federation suits cloud workloads that already have a native identity.

Common misconfigurations

Connection strings with embedded passwords in code and images: mongodb+srv://user:password@ strings in repositories, container images and CI logs are among the most common leaked database credentials (T1552.001 Credentials In Files).
0.0.0.0/0 left after a proof of concept: combined with a weak or reused password, the cluster is one guess away from exposure.
Organisation-level API keys with Organization Owner: a single CI secret that can create users and open networks in every project, with no expiry.
Treating Project Access Manager or Database Access Admin as low risk: both can reach data indirectly, by escalation or by creating a user.
Private endpoint added, public path kept: teams assume the cluster is private while access list entries still accept internet connections.
Relying on 7 day Access History: without auditing and export, a credential misused two weeks ago leaves no trace in Atlas.

Framework mapping

Control area	NIST SP 800-53 Rev 5	NIST CSF 2.0	CIS Controls v8.1	ISO/IEC 27001:2022 Annex A
Database user and service account lifecycle	AC-2, IA-5	PR.AA-01	5 Account Management	A.5.16, A.5.17
Role scoping and admin roles	AC-3, AC-6	PR.AA-05	6 Access Control Management	A.5.15, A.8.2
IP access lists and private endpoints	SC-7	PR.IR-01	12 Network Infrastructure Management	A.8.20, A.8.22
TLS and data protection	SC-8	PR.DS-01, PR.DS-02	3 Data Protection	A.8.24
Auditing and review	AU-2, AU-6	DE.CM-03	8 Audit Log Management	A.8.15, A.8.16

Practitioner checklist

Inventory every database user, service account and API key per project with an owner and purpose.
Move production applications to AWS IAM, Workload Identity Federation or X.509; vault any remaining SCRAM passwords.
Replace programmatic API keys with service accounts whose secrets expire, and alert before expiry.
Enable Require IP Access List for the Atlas Administration API and keep delegated App Connections off where not needed.
Treat Project Access Manager, Database Access Admin and Network Access Manager as privileged roles.
Restrict each database user to specific clusters and databases; use temporary users for human access.
Use private endpoints for production and remove public access list entries, especially 0.0.0.0/0.
Enable database auditing on dedicated clusters and export logs and Activity Feed events to your SIEM.
Alert on database user creation and network changes made outside your pipeline.

MongoDB Atlas Credentials Security Guide: Database Users, API Keys and Network Access