If you see unexpected databases or collections, missing data, unusual IPs or login attempts, or configuration changes you don’t recognise in MongoDB Atlas, use this checklist to limit further impact and review what happened.
You might suspect unauthorised activity if you notice things like:
New or unexpected databases or collections, especially with odd or unfamiliar names
Sudden or unexplained data loss (for example, dropped collections or missing documents)
Connections or logins from IP addresses, locations, or times you don’t expect
Alerts from your SIEM, SOC, or security tooling that mention Atlas or MongoDB
Unexplained configuration changes in Atlas, such as IP access list edits, new users or role changes, or restore events
MongoDB Atlas provides security controls and visibility, but you control how they are configured and how credentials are managed. The steps below focus on what you can do directly in your Atlas project and surrounding environment.
Before you change anything, note the approximate time window in UTC when you first noticed the issue, and take screenshots or exports of your current IP access list, database users, and any Atlas API keys. This helps you and your security or operations team compare “before vs after” and avoid losing useful evidence.
1. Immediate containment steps
Tighten network access
In your Atlas project, go to Network Access and review your Project IP access list.
Remove broad entries like 0.0.0.0/0 or large CIDR ranges that are not strictly required.
Restrict access to:
Known corporate or VPN egress IPs
If possible, temporarily restrict access to one or a small set of known IPs (for example, your VPN egress) while you investigate, then widen it again only as needed.
For details on managing IP access lists, see: Configure IP Access List Entries.
If you rely on dynamic IPs (for example CI/CD, serverless, or PaaS platforms), consider moving to private networking or using automation to add and remove specific IPs instead of keeping broad ranges open.
Rotate credentials and remove unused access
Rotate passwords and keys for privileged database users, Atlas Admin API keys, and any application or CI/CD secrets that connect to Atlas (for example, connection strings in environment variables, secret managers, or pipelines).
Disable or remove any unknown, unused, or generic high‑privilege users or API keys before you rotate the remaining ones.
Make sure remaining users follow the principle of least privilege.
2. Review what changed and from where
Use Atlas tools to understand what happened around the time you noticed the issue.
Activity Feed and events
Use the Project and Organisation Activity Feed to see configuration and administrative actions (IP access list changes, user changes, restores, etc.).
For API‑level visibility, please refer to the Events API documentation.
Focus on IP access list changes, new or removed users or roles, restore events, and any other changes that line up with the time window you recorded.
Database Access History (Access Tracking)
Use Database Access History to review:
Source IP addresses
Target clusters or hosts
Authentication source and result (success or failure)
Timestamps
Look for unfamiliar IPs, usernames, or bursts of failed logins.
Cluster logs (mongod / mongos)
Download recent logs from the Atlas UI as described in MongoDB logs in Atlas. Atlas only keeps recent logs (typically around 30 days), so download them as soon as possible, especially if the suspicious activity might be older or still ongoing.
Search for:
New or unexpected connections
Repeated authentication failures
Administrative commands such as dropDatabase, drop, createUser, grantRolesToUser, or unexpected restore operations
Metrics, storage history, and database statistics
Use Atlas metrics and storage views to check for sudden spikes or drops in:
Connections
Operations
Network traffic
Data size per database or collection
On specific databases, you can run db.stats() in mongosh to see high‑level counts and sizes:
use myDatabase
db.stats()
Comparing the output of the db.stats() over time (if you record them) can help you see which databases changed and when.
3. Improve logging and visibility
Atlas database auditing
If you use Atlas database auditing, it can record:
Authentication and authorization events
Administrative actions
Selected CRUD operations (depending on your filter)
For more details on this subject please refer to the following documentation: Atlas database auditing and Guidance for Atlas Auditing and Logging.
If auditing wasn’t enabled when the suspicious activity occurred, those historical audit events won’t be available. In that case, focus on Database Access History, cluster logs, and the Project and Organisation Activity Feed for past activity, and consider enabling auditing now so future events are captured.
Export logs for longer‑term analysis
Atlas keeps logs for a limited retention period. Many teams export them to their own environment for longer retention and correlation with SIEM tools.
You can send logs to external destinations (for example AWS S3) using push‑based log export , then ingest them into your SIEM or long‑term storage.
4. Harden your Atlas security
After your initial investigation, we recommend strengthening your configuration to reduce the risk of future incidents.
Authentication and identity
Review the multi‑factor authentication (MFA) options for privileged Atlas users and admins as described in Atlas MFA options.
Where possible, use your identity provider’s SSO instead of local Atlas passwords by configuring federated authentication.
Prefer phishing‑resistant methods (for example, hardware security keys or WebAuthn‑based authenticators) where your IdP supports them.
Encryption and data protection
Ensure encryption at rest is configured appropriately using Atlas‑managed keys or your own KMS; see Encryption at rest using customer key management.
For highly sensitive fields, consider Client-Side Field Level Encryption so data is encrypted before it reaches Atlas.
For an overview of Atlas data encryption options, see Atlas data encryption.
Network guardrails and resource policies
Prefer private connectivity (VPC peering or Private Endpoints) between your applications and Atlas instead of exposing clusters directly to the public internet.
Use Atlas Resource Policies to:
Block wildcard IPs such as 0.0.0.0/0 (and equivalent /0 CIDRs) in IP access lists
Enforce minimum security requirements in specific environments
Periodically review non‑compliant resources reported by these policies and bring them into alignment.
GitHub Actions and similar CI/CD runners use large pools of IP addresses, so instead of opening Atlas to 0.0.0.0/0 , use the documented runner or cloud-provider egress IP ranges in your Atlas IP access list, within the Atlas entry limits.
For other dynamic IP workloads (for example AWS Lambda, Heroku, or other PaaS/serverless platforms), either rotate IPs using the Atlas Administration API or use private networking / static egress (VPC peering, Private Endpoints, NAT gateways, or static-IP add-ons), and only use 0.0.0.0/0 as a short-term last resort with strong credentials.
Use Atlas UI IP access lists and your identity provider’s policies to limit who can access the Atlas UI and project settings.
5. If you still have concerns
If you still have concerns after going through the checks above:
Use the Atlas chat (the chat icon or Support option in the Atlas UI) to contact Atlas Basic Chat support.
If your organization already has a MongoDB Support plan, you can also follow your usual internal process to open a support case through your existing support channels.
When you reach out, it helps to have ready:
Atlas organization and project names
Affected cluster names
Approximate time window in UTC
A short summary of the suspicious activity
Any suspicious IP addresses, usernames, or database names
6. More information
For broader background on Atlas security and responsibilities, please refer to the following links:
If you have strict security or compliance requirements and would like a deeper review of your Atlas architecture and controls, consider engaging MongoDB Professional Services, MongoDB Consulting or Flex Consulting.