Editor’s note: This post is the first in a four-part series exploring how MongoDB Atlas Resource Policies help you strengthen database security and enforce consistent guardrails across your organization. Future posts will cover topics like defense-in-depth, blocking wildcard IP access, and restricting access by cloud provider or region.
Picture this: Your development team spins up a new MongoDB cluster for a critical application. To get things working quickly, the team adds overly permissive IP access rules. That might mean allowing their entire office network’s /16 CIDR block, or perhaps skipping careful validation of which specific IPs truly need access. That cluster goes into production. Six months later, during a security audit, you discover your database has been accessible from far more locations than anyone realized, with no clear documentation of who added which IP addresses or why.
Scenarios like this aren’t uncommon—and highlight why customers rely on MongoDB Atlas’ IP Access Lists to enforce clear, least-privilege network boundaries. IP Access Lists are a critical defensive layer in a defense-in-depth approach to security.
What if you could define exactly which IP addresses are allowed to access your databases and make it technically impossible for anyone to deviate from that approved list, at scale? That’s exactly what MongoDB Atlas Resource Policies are designed to do. They turn security best practices into enforceable guardrails that no one can bypass.
MongoDB Atlas IP access lists
Before diving into enforcement, let’s establish what IP access lists are and why they're your first line of defense.
An IP access list is a security feature that controls which IP addresses or CIDR blocks can connect to your MongoDB Atlas clusters. Think of it as a bouncer at an exclusive club; only addresses on the list get through the door.
Every MongoDB Atlas project maintains an IP access list that applies to all clusters within that project. You can add individual IP addresses (e.g., 203.0.113.42), CIDR-notated ranges (e.g., 198.51.100.0/24), or AWS security groups for VPC peering connections.
MongoDB Atlas supports up to 200 IP access list entries per project, giving you granular control over who can access your data.
The problem: Human error at scale
Manual IP access list management has inherent weaknesses that compound as organizations grow. Configuration drift becomes inevitable. What starts as a secure configuration degrades over time as teams add “just one more” convenience entry. Security teams often lack visibility into insecure IP access lists until an audit or incident forces a review, by which time the damage may already be done.
The challenge intensifies when different teams interpret security policies differently, resulting in wildly inconsistent implementations across projects. Traditional security controls detect problems after they occur rather than preventing them, creating a perpetual game of catch-up. Meanwhile, developers who feel blocked by security requirements find creative workarounds that often create even bigger security gaps than the original policy was designed to prevent.
Organizations need a way to enforce IP access list policies automatically, consistently, and across every corner of their infrastructure. And they need to implement these guardrails without creating friction that drives teams to circumvent security entirely.
The solution: Resource policies for automated IP access list enforcement
Enter MongoDB Atlas Resource Policies. These policies transform IP access list management from reactive to proactive. Instead of documenting best practices and hoping teams follow them, you codify security requirements as enforceable policies.
Resource policies for IP access lists operate at the Atlas Organization level and automatically apply to all projects and clusters. They act as intelligent guardrails that prevent insecure configurations before they’re deployed.
IP Access list resource policies: Real-world examples
Let’s explore the specific policies you can implement to secure your MongoDB Atlas infrastructure.
Policy #1: Enforce an IP address allowlist
Take a zero-trust approach by specifying exactly which IP addresses are permitted for database access.
Cedar policy code
What it does
This policy ensures that only the specified IP addresses can be added to the access list. Any attempt to add an IP address outside this approved list is automatically blocked.
How it impacts your business
An IP allowlist policy is particularly valuable for regulated industries where you must document and control all access points. It simplifies compliance audits by providing preapproved IP address documentation that’s automatically enforced. The policy prevents unauthorized access points from being added while creating a traceable security architecture that risk management teams can confidently present to auditors and regulators.
When to use this
This approach is ideal for production environments where you know exactly which systems need database access. Consider this policy when you have application servers with static IP addresses, corporate VPN exit points with known IPs, partner integrations from specific known networks, or ETL and analytics systems with fixed infrastructure. The allowlist model works best when your access patterns are predictable and well-documented.
Policy #2: Require empty IP access lists (private network only)
For maximum security, prohibit all public network access by requiring the IP access list to remain empty. This forces all traffic through private endpoints or VPC peering.
Cedar Policy Code
What it does
This policy prevents anyone from adding entries to the IP access list, ensuring that all cluster access must occur through private networking paths, such as VPC peering or private endpoints.
How it impacts your business
By requiring an empty IP access list, you eliminate public internet exposure completely and force architecture best practices where private networking takes precedence over public access. This approach meets the highest security standards for regulated data while reducing your attack surface to zero for external threats. It also simplifies network security by removing public access as an option entirely, making it impossible for teams to accidentally expose databases to the internet.
When to use this
This represents the gold standard for production environments handling sensitive data. Financial services systems processing payment data, healthcare applications storing protected health information or personally identifiable information, government systems with classified or controlled data, and enterprise software-as-a-service (SaaS) applications with stringent security requirements all benefit from this approach. The policy makes sense when you’ve committed to private networking as your standard architecture pattern and want to enforce it consistently across all production workloads.
Architecture note
Before implementing this policy, ensure you have private networking configured with VPC peering or private endpoints for your cloud provider.
The result: Zero public internet exposure for production databases, significantly reduced attack surface, and simplified compliance with PCI DSS requirements.
Key benefits of automated IP access list enforcement
Resource policies fundamentally shift security left in the development process. Security becomes part of the infrastructure deployment workflow rather than an afterthought that’s discovered during audits. Developers receive immediate feedback when they try to create insecure configurations, learning the rules through experience rather than documentation.
The enforcement of resource policies is absolute. Unlike documentation or training, resource policies are applied with 100% consistency across every project, cluster, and team member. There’s no variation based on who’s deploying or what time of day it happens. This consistency makes security frameworks like SOC 2, ISO 27001, and HIPAA significantly easier to achieve because resource policies provide both the control mechanism and the documentation in code form.
Resource policies help reduce security teams’ workloads dramatically. They no longer need to constantly audit IP access lists searching for violations or send emails asking teams to fix configurations. Resource policies prevent violations automatically, freeing security professionals to focus on strategic initiatives rather than tactical firefighting. MongoDB Atlas also generates activity feed events whenever policies are created, updated, or deleted, providing complete auditability for compliance purposes without additional work.
Perhaps most importantly, developer velocity actually increases within these guardrails. Teams maintain self-service capabilities for infrastructure deployment while staying within security boundaries. The dreaded cycle of deploying infrastructure, waiting for security review, making changes, and waiting again disappears entirely. Developers receive clear, immediate feedback about what’s allowed and can make compliant choices from the start.
IP access list best practices
When implementing IP access list policies, start with the strictest policy your architecture can support. It’s far easier to loosen restrictions later than to tighten them after teams become accustomed to more permissive controls. The initial discipline pays dividends in security posture.
Documentation plays a crucial role in long-term success. Maintain clear records of which IP addresses are in your allowlist and the business justification for each one. This documentation simplifies compliance audits and proves invaluable during troubleshooting sessions when you need to understand why specific addresses were approved.
For production workloads, the use of private networking solutions like VPC peering, AWS PrivateLink, and Azure private endpoints provides superior security compared to IP access lists alone. While IP access lists control which addresses can connect, private networking ensures traffic never traverses the public internet at all. The combination creates defense-in-depth that significantly reduces risk.
Before rolling out policies organization-wide, test them thoroughly in a separate organization or nonproduction environment. Understanding the impact on your teams and workflows prevents surprises during production rollout and helps you refine policies based on real-world feedback.
Take control of your database security today
IP access list misconfigurations are one of the most common—and most preventable—database security risks. MongoDB Atlas Resource Policies give you the power to eliminate this risk automatically and permanently. You don’t have to choose between security and developer productivity. With resource policies, you can enforce security requirements that are impossible to bypass while giving teams the self-service capabilities they need to move fast.
Begin by logging into MongoDB Atlas with Organization Owner privileges and navigating to Organization Settings, then Resource Policies. Implement your first IP access list policy—choose the allowlist or empty access list policy based on your architecture. Audit noncompliant resources to understand what needs remediation, then expand to comprehensive security policies as you build confidence in the approach. IP access list resource policies are included with all MongoDB Atlas deployments at no additional cost, making this a zero-friction way to dramatically improve your security posture.
Additional resources
Next Steps
Ready to close your biggest database security gap? Start your free MongoDB Atlas trial and implement IP access list policies in minutes.