<!-- llms-explorer concept facts · https://llms-explorer.com/tree/atlas-iam-compliance-mapping/ · pack 2026-10-24 · ~2187 tokens -->

# Atlas IAM Compliance Mapping

> Source-anchored research for Atlas IAM Compliance Mapping. Run status: COMPLETED.

Parent: [MongoDB Atlas IAM and RBAC](https://llms-explorer.com/tree/mongodb-atlas-iam-and-rbac/) · 4 facets · 20 facts · page: https://llms-explorer.com/tree/atlas-iam-compliance-mapping/

## How it works

- Atlas applies all roles from a user's mapped IdP groups at login. Removing a group removes its mapped role when the user next logs in, and removal of the last Organization Owner fails. An access review must account for aggregated roles and login-time updates. (low confidence) (verified as of 2026-10-14) — [source](https://www.mongodb.com/docs/atlas/security/manage-role-mapping.md)
- The independent How to Harden Atlas guide maps database least privilege to NIST AC-6, console MFA to IA-2(1), and both controls to SOC 2 CC6.1. The guide’s console MFA mapping differs in label and scope from Mondoo’s separate organization MFA check, which tags the check to NIST SP 800-53 Rev. 5 IA-2 and SOC 2 CC6.6.3. Record each publisher and scope when comparing these crosswalks. (low confidence) (verified as of 2026-10-11) — [source](https://howtoharden.com/guides/mongodb-atlas/)
- Mapped permissions accumulate across all of a user's matching IdP groups. Atlas applies mappings at login, can fall back to a default role when mappings are absent or yield no role, and blocks removal of the last Organization Owner. Access reviews must therefore evaluate effective permissions and fallback behavior. (low confidence) — [source](https://www.mongodb.com/docs/atlas/security/manage-role-mapping.md)

## Problems, failure modes and limitations

- Mondoo's privileged-access check allows at most three Organization Owners and maps the check to NIST AC-6 and PCI DSS 7.2.2. The three-owner threshold is its executable policy choice; the mapping does not establish a universal regulatory owner limit. (low confidence) (verified as of 2026-10-23) — [source](https://github.com/mondoohq/cnspec/blob/main/content/mondoo-mongodbatlas-security.mql.yaml)
- Treat a configured-federation check as configuration evidence. Mondoo tests whether federationSettings is nonempty; Duo documents authentication bypass policies. Together these show why federation presence alone cannot prove that every login satisfies MFA. (high confidence) — [source](https://github.com/mondoohq/cnspec/blob/main/content/mondoo-mongodbatlas-security.mql.yaml)
- MongoDB places authentication and RBAC under DORA ICT risk management guidance. Mondoo tags its MFA and privileged-owner checks to DORA Article 9. This provides a concrete route from broad resilience guidance to testable IAM controls. (medium confidence) — [source](https://www.mongodb.com/docs/atlas/architecture/current/compliance/dora.md)

## Comparisons and alternatives

- Map IAM by both identity type and target resource: human versus application, and Atlas UI versus database versus Administration API. MongoDB documents separate authentication paths and distinguishes Atlas management roles from granular database roles; a UI SAML configuration therefore cannot serve as evidence for every access path. (high confidence) — [source](https://www.mongodb.com/docs/atlas/architecture/current/auth/authentication.md)
- For PCI DSS Requirement 7, MongoDB explicitly links business-need-to-know restrictions to Atlas authentication and RBAC guidance. A defensible implementation crosswalk pairs job functions with least-privilege organization/project roles and fine-grained database roles; this is implementation evidence rather than proof that the requirement is fully satisfied. (high confidence) — [source](https://www.mongodb.com/docs/atlas/architecture/current/compliance/pcidss.md)
- For federated Atlas UI users, MongoDB places MFA configuration in the identity provider. Duo supports MFA and application policies but documents bypass statuses, Skip MFA/Bypass 2FA policies, and remembered-device behavior. A compliance review must inspect effective IdP policy and exceptions instead of treating SAML integration as sufficient MFA evidence. (high confidence) — [source](https://www.mongodb.com/docs/atlas/architecture/current/auth/authentication.md)
- MongoDB recommends restricting Organization Owner and Project Owner privileges, using service accounts for provisioning/governance and controlled emergency access. Mondoo independently checks owner sprawl and privileged API credentials. Together these support a privileged-access review, rather than assigning owner roles to routine users. (medium confidence) — [source](https://www.mongodb.com/docs/atlas/architecture/current/auth/authorization.md)

## Facts and statements

- An Atlas IAM evidence matrix should distinguish UI, Administration API, and database authentication, then record whether each tested setting belongs to the organization or project. MongoDB separates authentication by resource; Mondoo separates organization and project findings. (high confidence) — [source](https://www.mongodb.com/docs/atlas/architecture/current/auth/authentication.md)
- Mondoo's Atlas MFA check tests multiFactorAuthRequired == true and tags it to NIST SP 800-53 IA-2, PCI DSS 8.4.2, and HIPAA 164.312(d). These are Mondoo's control mappings. (low confidence) (verified as of 2026-10-23) — [source](https://github.com/mondoohq/cnspec/blob/main/content/mondoo-mongodbatlas-security.mql.yaml)
- Atlas can map identity-provider groups to organization and project roles. MongoDB specifies the SAML memberOf attribute, and Cisco Duo documents configuring the corresponding Atlas role mapping and Duo group association. Preserve the IdP group identifier, assigned roles, target scope, and approval as review evidence. (high confidence) — [source](https://www.mongodb.com/docs/atlas/security/manage-role-mapping.md)
- MFA evidence for federated access must include effective IdP policies. MongoDB places federated security policy enforcement in the IdP; Duo's Atlas integration documents Bypass, Bypass 2FA, Skip MFA, and policies permitting unknown users without MFA. (high confidence) (verified as of 2026-07-30) — [source](https://www.mongodb.com/docs/atlas/architecture/current/auth/authentication.md)
- MongoDB's HIPAA guidance links access control to authentication and job-based RBAC for ePHI. Its PCI DSS guidance similarly links Requirement 7, business need to know, to authentication and authorization for cardholder data. These are feature-to-requirement mappings, which need deployment-specific IAM evidence. (high confidence) — [source](https://www.mongodb.com/docs/atlas/architecture/current/compliance/hipaa.md)
- MongoDB documents mapped-role removal after a group change at the user's next login. Do not infer immediate termination of existing sessions from that behavior; an offboarding control needs an explicit test of session and token revocation as well as group removal. (low confidence) — [source](https://www.mongodb.com/docs/atlas/security/manage-role-mapping.md)
- Duo's Atlas UI integration guide instructs administrators to turn Bypass SAML Mode OFF to require Duo SSO. This is a separate enforcement step from configuring the provider or optional group mappings; the guide also offers application ownership and regulatory-framework metadata. (low confidence) (verified as of 2026-07-30) — [source](https://duo.com/docs/sso-mongodb-atlas-uia)
- Mondoo's original Atlas policy maps its organization MFA check to PCI DSS 8.4.2, HIPAA 164.312(d), NIST SP 800-53 IA-2, and ISO 27001:2022 A.8.5. Its executable predicate is multiFactorAuthRequired == true; these are Mondoo's crosswalk tags, not regulator-issued determinations of compliance. (low confidence) (verified as of 2026-10-23) — [source](https://github.com/mondoohq/cnspec/blob/main/content/mondoo-mongodbatlas-security.mql.yaml)
- Evidence collection must preserve scope: Mondoo separates organization posture such as federation and MFA from project posture such as database users and roles, matching MongoDB's distinction between management authorization and database authorization. An audit should retain org/project identifiers and independently inspect effective access. (medium confidence) — [source](https://github.com/mondoohq/cnspec/blob/main/content/mondoo-mongodbatlas-security.mql.yaml)
- MongoDB's authentication guidance prefers OAuth 2.0 service accounts over legacy Digest API keys for programmatic administration, citing short-lived tokens and credential rotation. Mondoo's policy examples still use Digest API keys; their example transport should not be mistaken for MongoDB's preferred credential architecture. (medium confidence) (verified as of 2026-10-14) — [source](https://www.mongodb.com/docs/atlas/architecture/current/auth/authentication.md)
