How Apache Superset supports CMMC Level 2 access control over CUI
A defense contractor that puts controlled unclassified information (CUI) into Superset dashboards is taking on three CMMC Level 2 requirements directly: AC.L2-3.1.1 (authorized access), AC.L2-3.1.5 (least privilege) and AU.L2-3.3.1 (system auditing). Each is a NIST SP 800-171 Rev. 2 requirement, and Level 2 assessments test them against the assessment objectives in NIST SP 800-171A (June 2018). Superset does not satisfy these requirements by itself. It supports them through its identity integration, role model and logging, and the contractor must show that those settings, and the surrounding operating procedures, meet the objectives. AC.L2-3.1.1 is worth 5 points and AC.L2-3.1.5 is worth 3 points under the CMMC Scoring Methodology, so a NOT MET result on either is subtracted from the maximum score of 110, and 32 CFR 170.21(a)(2) does not allow either on a POA&M. Both must be fully MET. AU.L2-3.3.1 must also be MET, because its evidence must be in final form to count.
In practice, the work centers on three decisions. First, sign-in should run through a single identity provider so every user is a known, unique account, with group-to-role mapping (AUTH_ROLES_MAPPING) that is documented and reviewable. Second, roles and row level security should restrict CUI datasets to named job functions, and privileged roles such as Admin should be limited to named administrators, which is the evidence AC.L2-3.1.5 asks for. Third, Superset's event logging and the metadata database audit trail should be configured to record who viewed, exported and changed CUI content, and the retention period must be defined and met. Each of these must be tested and written down before the assessment, and the contractor should confirm with its C3PAO and the CMMC Assessment Guide which evidence the assessor expects. DeployOpen prepares the system, controls and evidence, but it does not issue certifications. Only a C3PAO can perform a Level 2 certification assessment.
The regulatory timeline also needs careful reading. On 13 July 2026 the Department of War suspended CMMC Phase II, the stage that would have required Level 2 C3PAO certification for applicable contracts, and started a 60-day review by a CMMC Reform Task Force. Phase I self-assessments, SPRS postings, annual affirmations and DFARS 252.204-7012 obligations remain in place. The Department also said it will enforce NIST SP 800-171 Rev. 2 in the interim, even though NIST withdrew Rev. 2 in favor of Rev. 3. Contractors should confirm the current requirements with their contracting officer and the DoW CIO About CMMC page rather than plan around a date from an older schedule.
Mapping AC.L2-3.1.1, AC.L2-3.1.5 and AU.L2-3.3.1 to Superset capabilities
This table maps each of the three CMMC Level 2 requirements to its NIST SP 800-171A assessment objectives, the Superset capability that supports it and the configuration to set. Each requirement is worth more points than a POA&M allows, so every row must be MET with final evidence before a Level 2 result is possible. Treat the configuration column as a starting point to verify against your own assessor's objectives.
| Requirement | Assessment objectives (NIST SP 800-171A) | Superset capability | Configuration to set and evidence to keep |
|---|---|---|---|
| AC.L2-3.1.1 Authorized access (5 points) | 6 objectives: identify authorized users, processes acting for them and authorized devices, then limit access to each group | Flask-AppBuilder users and roles, OAuth2 or LDAP login through the identity provider, AUTH_ROLES_MAPPING | Disable local password logins for workforce users, map IdP groups to Superset roles, and keep a dated export of user and role assignments as evidence |
| AC.L2-3.1.5 Least privilege (3 points) | 4 objectives: identify privileged accounts and security functions, then authorize access to each in line with least privilege | Admin and custom Flask-AppBuilder roles, dataset and database permissions, row level security filters | Restrict Admin role to named platform staff, grant dataset access by job function, apply RLS per facility or business unit, and record who holds each privileged role |
| AU.L2-3.3.1 System auditing (3 points) | 6 objectives: specify event types and record content, generate records with that content, and define and meet retention | Metadata database audit records and Superset event logging, retained outside the application | Define which logins, role changes, dataset changes and dashboard exports must be logged, forward records to a central store, and document the retention period your assessor will test |
| Scope of CUI storage | Assessed within your boundary, including the database and identity provider the dashboards query | Superset metadata database, caches and exports hold CUI when dashboards display it | Confirm the metadata database and any cloud hosting meet the CUI requirements in 32 CFR 170.17(c)(5) before loading CUI |
| Secret key and sessions | Supports the authentication and session objectives of the Access Control family in your System Security Plan | Required SECRET_KEY, with PREVIOUS_SECRET_KEY for rotation | Set a unique SECRET_KEY outside source control, record rotation dates, and confirm the metadata database is PostgreSQL or MySQL in a supported version |
| Upgrade and change control | Changes to access settings must be traceable to an authorized change record | superset db upgrade and superset init after each version change | Back up the metadata database, test in staging, review UPDATING.md, and keep the change record with the access configuration |
| Evidence form | A requirement is MET only when all applicable objectives have evidence in final form, not drafts | Role exports, IdP group lists, RLS definitions and log extracts | Store signed final versions of each export with the date and owner, and confirm the format your certified third-party assessor expects |
Where Superset sits in the CUI boundary
Superset has four architecture components, and each one decides where CUI can sit. The application (the Flask and React web tier) renders dashboards and returns query results to the browser, so it sees CUI whenever a user opens a chart. The metadata database stores dashboards, charts, datasets, users, roles and the database connection definitions, so it holds CUI-related metadata even when no result rows are stored. The optional caching layer holds query results, and the optional Celery workers and beat processes run scheduled work. Ask your assessor early whether each component falls inside your assessed boundary, and document the answer in your system security plan.
The optional components are the ones that quietly widen scope. According to the Superset architecture documentation, alerts and reports, async queries and dashboard thumbnails require the caching layer and worker components, and most installations use Redis and Celery for them. Each feature you enable therefore brings a cache store, a worker tier and their logs and images into scope. If you do not need scheduled delivery, turning those features off is the simplest way to shrink the boundary, and that choice should be recorded with the configuration that enforces it.
The metadata database must be PostgreSQL or MySQL. The architecture documentation says the SQLite default used by Quickstart and PyPI installs, and the PostgreSQL container in the Docker Compose setup, are not recommended for production. Confirm the database version against the supported list in the configuration documentation (PostgreSQL 10 to 17, MySQL 5.7 and 8.x) and confirm that its storage, backups and encryption sit inside the same boundary as the application. Because this database holds the access model itself, it is a high-value target and belongs in your access control and audit evidence.
Choosing an identity path for authorized users and processes
Superset is built on Flask-AppBuilder and supports OAuth2 providers such as Google and Azure, along with custom OAuth2 servers that use the code flow. With this path, the enterprise identity provider authenticates the user and Superset trusts the returned identity, so account existence, password policy and sign-in controls stay with the provider. For AC.L2-3.1.1, this is usually the strongest tie between a login and an authorized user, because access starts and stops in one directory.
- Single source of identity: Accounts are created and disabled in the identity provider, and Superset does not hold passwords for these users.
- Group to role mapping: Provider groups map to Superset roles through
AUTH_ROLES_MAPPINGin the configuration, so role assignment follows directory membership. - Evidence to request: Export of the provider's user and group membership, the Superset mapping configuration, and the deprovisioning record for a departed user.
- Open decision: Confirm whether the provider can enforce multi-factor sign-in and whether Superset sessions end when the provider session ends.
- Scope note: Confirm the exact OAuth2 flow and claim names with your provider and the Superset version you run.
Ask your provider team to show how a disabled account stops access to Superset, because that test is the one auditors most often repeat.
LDAP lets Superset validate credentials against an existing directory and map directory groups to Superset roles. It fits organizations whose user records live in a directory that is not exposed as a modern OAuth2 provider. Superset still depends on the directory for identity, but the login path, bind account and group search settings are configured in Superset, so those settings become part of the access control evidence.
- Bind account: Use a dedicated, least-privileged service account for directory queries, and document who owns its password.
- Group to role mapping: LDAP groups map to Superset roles through
AUTH_ROLES_MAPPING, so each group must be reviewed against the roles it grants. - Transport: Confirm that the directory connection uses encrypted transport and that certificates are validated.
- Evidence to request: Directory group listings, the Superset LDAP configuration with secrets removed, and a sample of accounts that were disabled in the directory and can no longer sign in.
- Open decision: Confirm how Superset behaves when a user is removed from a group that grants a role, and whether roles are refreshed at each login.
Test a removed group membership in a non-production instance before you rely on the mapping for audit evidence.
A local login stores Superset user accounts and their passwords in the Superset metadata database. It is the simplest path to set up, and it is sometimes used for a small administrative group or for break-glass access. The trade-off is that the identity record lives outside the enterprise directory, so provisioning, password rules and removal must be run by hand and recorded, which adds work at audit time.
- Account lifecycle: Each account is created, changed and disabled inside Superset, so you need a documented procedure that matches HR or access requests to Superset actions.
- Shared accounts: Prohibit shared logins for people, because a shared account cannot show which authorized user acted.
- Admin accounts: Keep local administrators few and named, and treat them as privileged accounts under AC.L2-3.1.5.
- Evidence to request: A user list exported from the metadata database, dated access reviews, and the record of each account removal.
- Open decision: Confirm the password policy you can enforce, since Superset does not replace an enterprise password standard on its own.
If you use local accounts at all, limit them to a documented exception list that a reviewer can check against every access review.
AC.L2-3.1.1 also requires limiting access to authorized devices and to processes that act for authorized users, including other systems. Superset's login settings do not cover these. Device trust, network placement and service-to-service credentials are controls that sit outside Superset, so they need their own owners, configuration and evidence. Treat this as a separate workstream that runs alongside whichever login path you choose.
- Devices: Confirm which endpoints may reach Superset through network controls, managed device policy or both, and record the rule set.
- Processes: Identify scheduled jobs, reporting services and API clients that use Superset credentials, and assign each an owner and a credential scope.
- Database connections: Confirm the database account Superset uses for each connection is limited to the datasets the process needs.
- Evidence to request: Device policy exports, firewall or access rules that reach the Superset host, and an inventory of service accounts.
- Open decision: Confirm which of these controls already exist in your environment and which must be built before assessment.
Ask your security team to map each device and process to a named control before the login design is finalized, since an identity path alone does not satisfy this part of the requirement.
Configuration sequence for a CUI-scoped Superset
This sequence settles hosting and boundary questions first, then builds identity, roles, data access, export limits and logging in the order an assessor will test them. Each step ends with evidence you can hand to a C3PAO or your own assessment team.
Confirm the boundary and hosting status
Before installing anything, define which systems, accounts, networks and people fall inside the CUI boundary, including the Superset web tier, metadata database, cache, workers and every warehouse connection. If Superset runs in a cloud service, confirm with the provider that the service is FedRAMP Authorized at the Moderate baseline or higher, or meets equivalent requirements, because 32 CFR 170.17(c)(5) sets that condition for storing or processing CUI in the cloud. Assign an owner for the boundary diagram. Done means a signed boundary document that lists every component and its hosting status.
Deploy with a supported metadata database
Install Superset in your own infrastructure and point it at PostgreSQL or MySQL, the two databases the project tests for metadata. Use the versions listed in the configuration documentation (PostgreSQL 10 to 17, MySQL 5.7 and 8.x), not the SQLite default used by quickstart and PyPI installs, and avoid the Docker Compose PostgreSQL container for production. The platform team performs the install and records component versions. Done means a running staging instance with a documented version inventory and a database that is backed up and access-restricted.
Set a SECRET_KEY and manage its rotation
Set a unique SECRET_KEY in the configuration, sourced from your secrets store rather than a file in the repository. Superset will not start without it, and the configuration documentation describes using PREVIOUS_SECRET_KEY to rotate it. Record who holds the key, where it is stored and the rotation procedure. Done means the instance starts only with the managed key, and the key custody record is part of the baseline evidence.
Configure SSO and AUTH_ROLES_MAPPING
Connect login to your identity provider through OAuth2 or LDAP, so every user has a unique, attributable account and no local password accounts remain for regular users. Map identity provider groups to Superset roles with AUTH_ROLES_MAPPING so that role assignment follows directory membership. Confirm that the mapping works for a test user in each group, and that a user removed from the directory cannot sign in. This step addresses authorized access under AC.L2-3.1.1. Done means a test matrix showing login results and assigned roles for each test account.
Define least-privilege roles and row-level security
Create roles that grant only the dashboards, datasets and database connections each job function needs, and remove or restrict default roles that are broader than that. Add row-level security filters for datasets that hold CUI so users see only the rows their function permits. Restrict admin roles to a small named group. This step addresses AC.L2-3.1.5 least privilege, including privileged accounts and security functions. Done means a role matrix that maps each role to its permissions, plus test results showing that out-of-scope users cannot read restricted rows.
Restrict export and SQL execution
Decide which roles may export CSV or Excel data, download chart results or run ad hoc SQL Lab queries, and turn off the rest in the role configuration. Limit query execution time and row counts, and grant database connection privileges to the warehouse only at the level the dashboards need. Confirm that exports and SQL queries are recorded in the logging step. Done means a documented export and SQL policy, with test accounts that confirm the restrictions hold.
Configure audit logging and retention
Enable Superset's event logging and forward logs from the web tier, workers, metadata database and identity provider to a central store inside the boundary. Define which event types you log (logins, failed logins, role changes, dashboard and dataset access, exports, SQL queries and permission changes), what each record contains, and how long records are retained. This step addresses AU.L2-3.3.1, which asks you to specify event types and content, generate the records and meet retention requirements. Done means a sample of each event type is found in the central store with the expected fields and a written retention rule.
Test in staging and document the baseline before upgrades
Run the full test set in staging: login and role mapping, RLS, export and SQL restrictions, log generation and a restore from backup. Keep the final evidence, since NIST SP 800-171A assessments count only final artifacts, not drafts. Before any Superset upgrade, back up the metadata database, run superset db upgrade and superset init in staging, and review UPDATING.md for breaking changes between versions. Record the baseline configuration and version so an upgrade can be compared against it. Done means a signed baseline package that a change under the upgrade process can be tested against.
Evidence auditors test and how to keep it in final form
An assessor applies the NIST SP 800-171A objectives to each requirement and accepts a requirement as MET only when the evidence is in final form, not drafts. The cards below cover the records that Apache Superset produces or that your team must keep for AC.L2-3.1.1, AC.L2-3.1.5 and AU.L2-3.3.1, and what to check in each before an assessment.
Role and permission export
A dated export of Superset roles and the permissions attached to each, taken from the running metadata database. It shows who can reach which dashboards, datasets and admin functions, which is the evidence for identifying authorized users and privileged accounts under 3.1.1 and 3.1.5. Check that the export is generated from production, that it is signed off by the data owner, and that custom roles are documented with their purpose. Keep one final version per review cycle, not working copies.
SSO configuration and group mapping record
The identity provider configuration for Superset login, along with the AUTH_ROLES_MAPPING entries that translate directory groups into Superset roles. This record shows that each user authenticates through an identified account and that role assignment follows group membership. Confirm that local password login is disabled where your policy requires it, that the mapping file matches the deployed configuration, and that the approver for each group is named.
Row level security definitions
The exported row level security rules that restrict which records a role can query, with the datasets and roles each rule applies to. These rules support least privilege under 3.1.5 by limiting data to the population a role needs. Check that every CUI dataset has a rule or a documented reason it does not, that rules are tested with a user from each role, and that test results are kept with the rule set.
Audit and event log set with retention
The Superset event and action logs, plus the web server, database and identity provider logs that show logins, permission changes and dashboard access. This set answers AU.L2-3.3.1 by showing which event types you chose to record, the content of each record, and how long you keep them. Write the retention period in a formal policy, confirm that logs are forwarded to storage outside the Superset host, and test that a sample event can be traced from login to query.
Upgrade and backup records
Records of each Superset upgrade and each metadata database backup, including the pre-upgrade backup, the superset db upgrade and superset init runs, the staging test results and the UPDATING.md review. These show that the security configuration survived change and can be restored. Confirm that a restore test was completed and that the backup covers the metadata database that holds roles, mappings and RLS rules.
Change tickets
Approved tickets for each change to roles, mappings, RLS rules, SECRET_KEY rotation, database connections and Superset versions. An assessor compares these tickets with the exports above to confirm that access changed only through approved work. Check that each ticket records the requester, approver, the before and after state, and the date the change was deployed, and that the tickets are closed rather than left in draft.
Versions, upgrades and the Rev. 2 baseline
Start by pinning the Superset version your CUI environment will run and recording why. The released versions named in the researched facts are 6.0.0, published December 18, 2025, and 6.1.0, published May 13, 2026. The GitHub releases page lists 7.0.0rc2 as a pre-release dated October 16, 2026, and a release candidate should not be the baseline for an assessed system. Confirm the version you choose against the apache/superset releases page on the day you freeze the baseline, and keep the version in your system security plan so an assessor can match it to the running build.
Every upgrade changes the system an assessor has tested, so plan it as a change under your configuration management process. The upgrade guide says to back up the metadata database, run superset db upgrade and superset init, test in staging first, and check UPDATING.md for breaking changes between versions. For CUI, add three steps: confirm the backup is encrypted and restorable, re-run your access tests (role membership, row level security filters and export settings) in staging, and record the before and after evidence. Ask your sponsor whether a significant change needs to be reported before it goes live.
The control text in this topic follows NIST SP 800-171 Rev. 2, which CMMC Level 2 incorporates. NIST withdrew Rev. 2 when it published Rev. 3 on May 14, 2024, yet the CMMC rule still incorporates Rev. Rev. 2 is the baseline assessors test against today, and the Department of War said on July 13, 2026 that it will enforce Rev. 2 in the interim. Because CMMC Phase II was suspended on the same date and the DoW CIO's About CMMC page describes the program as paused, confirm the current assessment guidance and any transition timing with your sponsor or contracting officer before you write requirement statements against either revision.
Questions buyers ask about Superset and CMMC Level 2
Does installing Apache Superset make our system CMMC Level 2 compliant?
No. Superset is an open-source analytics application, and CMMC Level 2 is assessed against the 110 requirements of NIST SP 800-171 Rev. 2 across the whole system that stores, processes or transmits CUI. Superset can support AC.L2-3.1.1, AC.L2-3.1.5 and AU.L2-3.3.1, but those requirements also depend on your identity provider, network boundary, database privileges, endpoint configuration, policies and evidence. Each requirement must be MET with final-form evidence, because AC.L2-3.1.1 and AC.L2-3.1.5 cannot be carried on a POA&M. Ask whether a given control is in your system security plan scope before assuming Superset covers it.
What does a CMMC Level 2 Superset implementation cost, and what drives it?
The cost depends on the written scope, which is agreed before work starts and then quoted. The main drivers are the number of data sources and CUI datasets, how many roles and row-level rules must be designed, the identity provider integration, the metadata database and hosting environment, the logging and retention design, and the evidence package you need for your assessor. Some work is one-time, such as design, build and evidence capture, while hosting, patching, access reviews and log retention recur. Ask for a quote that separates these items, names what you provide, and states which requirements the work targets.
How long does it take to get Superset ready for CUI, and what depends on us?
Duration depends mainly on how mature your identity provider, network boundary and data classification already are, and how quickly your team can review designs and approve changes. Schedules also depend on the number of datasets and dashboards that hold CUI and on your assessment date. Timing for CMMC itself is in flux: the Department of War suspended CMMC Phase II on 13 July 2026 and started a 60-day review, while Phase I self-assessments and DFARS 252.204-7012 obligations remain in place. Confirm current requirements with your contracting officer and assessor before setting a timeline.
Can our internal team implement Superset for CMMC Level 2 without a partner?
Yes, if your team has the skills and time, and the work is handled as a controlled change. The team needs experience with Superset's authentication settings, role and row-level security design, database connection privileges, and log handling, as well as the NIST SP 800-171 assessment objectives and CMMC evidence standards. Many teams underestimate the evidence work: each claim must be backed by final-form records such as role exports, access reviews and audit logs. Compare your internal capacity against the scope and ask a partner to review your design if you lack assessment experience.
What do we need to provide before a Superset engagement can start?
A written scope starts with the facts only you hold. Expect to provide your CUI data inventory, the systems that hold or transmit CUI, your current identity provider and group structure, the metadata database and hosting environment you intend to use, network and boundary diagrams, and the roles that should see each dataset. You will also need a named owner for approvals, access to staging for testing, and the policies that govern access reviews and log retention. Confirm the boundary and assessment scope with your assessor early, since those decisions shape the design.
Does DeployOpen certify our Superset environment for CMMC Level 2?
No. DeployOpen plans, implements, hardens and documents open-source platforms in infrastructure you control, and prepares systems, controls and evidence for compliance assessments. It does not issue audit reports, attestations or certifications. Under the CMMC program, Level 2 certification assessments are performed by C3PAOs authorized or accredited by the CMMC Accreditation Body, currently The Cyber AB, and self-assessments are performed by the organization itself. Ask your assessor or contracting officer which assessment path applies to your contract.
Which Superset engineering details would an assessor check for CUI access?
Assessors look for evidence that each access decision follows from a documented rule. For AC.L2-3.1.1, they check that only identified users, processes and devices can reach Superset and its data. For AC.L2-3.1.5, they check that privileged roles are limited and justified. For AU.L2-3.3.1, they check that the event types, record content and retention are defined and that records are generated. Before the assessment, confirm that the SECRET_KEY is user-specified, that authentication goes through your identity provider, that role mappings are exported and reviewed, and that logs are retained as your policy states. See the Apache Superset configuration documentation for the relevant settings.
What your team and your assessor need to provide
Before DeployOpen can scope a Superset build for CMMC Level 2, your team needs to provide the system security plan scope that states which systems store, process or transmit CUI and which are only connected to them. Superset itself, its metadata database, any Redis and Celery components, and every analytics database it queries should appear in that boundary or be explicitly excluded with a reason. Alongside the SSP, provide a CUI data flow showing where CUI enters, which datasets and dashboards expose it, where exports and scheduled reports go, and which backups hold copies. Without this map, the access control requirements for authorized users and least privilege cannot be tested, because the assessor needs to know which data each role can reach.
Next, name the identity provider owner and the people who run it. Superset's login, OAuth2 or LDAP group mapping through AUTH_ROLES_MAPPING, and account removal all depend on that system, so the owner must confirm which groups feed Superset roles and who approves changes. Also provide the list of Superset roles and the data owner who approves access to each dataset and row level security rule. Confirm with your team that these lists are current and in final form, since a requirement is met only with evidence in final form, not drafts. Plan for a named owner of the admin role, because privileged access falls under AC.L2-3.1.5.
Finally, decide early how your assessor relationship works. Level 2 certification assessments are performed by C3PAOs, and The Cyber AB is the current accreditation body for them, so you must select a C3PAO from its accredited or authorized population rather than from DeployOpen. DeployOpen prepares the controls, configuration and evidence, but it does not issue assessment results. Ask your C3PAO early which evidence formats and sampling they expect for AU.L2-3.3.1 audit records, and confirm the current status of Level 2 certification requirements, since the Department of War suspended Phase II in July 2026 and the assessment timing for your contracts should be verified with your contracting officer.
How DeployOpen scopes and delivers CMMC-aligned Superset configuration
DeployOpen plans, implements, hardens and documents self-hosted Apache Superset inside your own infrastructure, so that authorized access, least privilege and audit logging are configured and testable before an assessor arrives. Engagements are fixed-scope, with the controls, evidence and handover agreed in writing before work starts.
How we scope
- We confirm which Superset dashboards, datasets and databases hold CUI and which of them are in scope for AC.L2-3.1.1, AC.L2-3.1.5 and AU.L2-3.3.1.
- We map the user, process and device population that may reach Superset, and the roles each group needs, before any role is changed.
- The written scope names the hosting boundary, identity provider, metadata database, and whether any cloud service is involved, with its FedRAMP status confirmed by the client.
How we build
- We configure SSO through your identity provider, map groups to Superset roles, and remove local login paths that would bypass that control.
- We design row level security and dataset permissions around least privilege, then test them with accounts that should be denied as well as allowed.
- We set audit log retention and event coverage to match the requirement's objectives, and test that records contain the content an investigator would need.
How we hand over
- You receive a control-to-configuration map showing each setting, its owner, and the NIST SP 800-171A objective it supports.
- Test records are delivered as evidence in final form, with the role export, access test results and sample log entries kept for your assessor.
- Runbooks cover access reviews, role changes, secret key rotation and the upgrade steps in the Superset upgrade documentation, so your team can operate the system.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer, so role reviews and log checks continue after handover.
- When Superset releases a new version, we review its breaking change notes and retest the access and logging controls before the upgrade reaches production.
- We prepare systems and evidence for compliance assessments. Certification decisions rest with the independent C3PAO assessor, not with DeployOpen.
