Notifications
Clear all
Topic starter
08/06/2026 4:58 pm
TL;DR: MongoDB users are created per authentication database and then granted roles across databases, which means access can span far beyond the user’s origin context; StrongDM’s guide highlights why scoping permissions tightly still matters when database access is distributed. The real issue is not user creation mechanics but the governance gap between provisioning convenience and durable least-privilege control.
NHIMG editorial — based on content published by StrongDM: How to Create a User and Add a Role in MongoDB (Safest Way)
By the numbers:
- Only 5.7% of organisations have full visibility into their service accounts.
- 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface.
- 71% of NHIs are not rotated within recommended time frames, increasing the risk of compromise over time.
Questions worth separating out
Q: How should security teams govern MongoDB users with roles across multiple databases?
A: Treat the user as a governed NHI entitlement, not just a database login.
Q: Why do MongoDB authentication databases not solve least-privilege risk on their own?
A: Because the authentication database identifies where a user was created, not the full extent of what that user can access.
Q: What breaks when MongoDB roles are granted broadly for convenience?
A: Broad roles create hidden access paths that outlive the original use case and expand the blast radius of compromise.
Practitioner guidance
- Map every MongoDB user to its role blast radius Document which databases each user can read or write, then separate single-database access from cross-database bundles so entitlement scope is visible during review.
- Recertify database roles against application purpose Tie each MongoDB role to a workload owner and a current business function, then remove permissions that no longer match the application’s live dependency set.
- Treat authentication databases as labels, not boundaries Assume the authentication database does not constrain privilege.
What's in the full article
StrongDM's full blog post covers the operational detail this post intentionally leaves for the source:
- Step-by-step MongoDB user creation syntax and role assignment examples for developers.
- Admin UI setup details for adding a MongoDB datasource and configuring gateway connectivity.
- Practical configuration notes for authentication database, username, password, and TLS settings.
- Implementation guidance for exposing MongoDB through StrongDM-managed access paths.
👉 Read StrongDM's guide to creating MongoDB users and assigning roles safely →
MongoDB user roles and least privilege: what IAM teams miss?
Explore further
08/06/2026 6:54 pm
MongoDB role sprawl is an authorisation problem disguised as a setup task. The article shows how a user created in one authentication database can be given roles across several databases, which makes access scope easy to expand quietly. That is not just an implementation detail, it is a governance pattern that turns convenience into durable overreach. Practitioners should treat every role grant as a reviewable entitlement, not a harmless configuration step.
A few things that frame the scale:
- Only 5.7% of organisations have full visibility into their service accounts, according to Ultimate Guide to NHIs.
- Another 97% of NHIs carry excessive privileges, which means broad role assignment is still the default pattern rather than the exception.
A question worth separating out:
Q: What should teams check before relying on MongoDB access controls in production?
A: Confirm that TLS is enabled, audit trails are reviewed, and each role still matches current application need. If any of those controls are missing, access may be encrypted and logged but still far too broad. The goal is to prove that database privileges are current, scoped, and defensible.
👉 Read our full editorial: MongoDB role-based access shows why least privilege still drifts
