Apache Superset NIS2 access control and MFA

Apache Superset for NIS2 access control and authentication: what it covers

If your organization is an essential or important entity under NIS2, you will need to show a national authority how you meet Article 21(2)(i) on access control and Article 21(2)(j) on multi-factor authentication. NIS2 issues no certificate of compliance. Authorities check compliance through inspections, audits, scans and information requests, and the technical detail comes from Commission Implementing Regulation (EU) 2024/2690, which sets out the access control and authentication expectations in its Annex. Apache Superset can support parts of that picture, but it does not satisfy the regulation on its own. Read the requirements as a set of controls your organization operates, with Superset as one system inside them.

Superset helps with the technical login and logging layer. Routing sign-in through an identity provider using OAuth2 or LDAP means each person authenticates with an identity you already manage, and AUTH_ROLES_MAPPING can map directory groups to Superset roles so access follows the group membership your identity team controls. Disabling the account at the identity provider stops new sign-ins, and the Superset user records and role assignments give you a register to reconcile against your joiner, mover and leaver records. Superset does not itself enforce MFA. That requirement sits with the identity provider, so confirm that MFA is enforced there for every route into Superset, including any local administrator login you keep. Verify whether your Superset version exposes the session and failed-login settings you need, and check the logs your deployment actually writes.

Superset does not run the review process. Periodic access reviews, approval of shared identities, need-to-know decisions for each dataset and role, and the separation of duties between data owners and administrators are governance tasks. Your team must own them, with exports of roles and users as the input. Plan for who signs off each review, how often it runs, and how evidence is kept. Before writing the control narrative, check the NIS2 Technical Implementation Guidance from ENISA, which gives examples of evidence for these points.

Which NIS2 access control and MFA requirements Superset configuration supports

This table maps each NIS2 access control and authentication requirement in Implementing Regulation 2024/2690 and Article 21(2)(j) to the Superset capability involved, the configuration needed and the party who owns enforcement. Read the owner column first, because many requirements are enforced by the identity provider or by your own process rather than by Superset alone. Confirm every Superset setting against the configuration documentation for the version you run.

Requirement	Superset capability and configuration	Enforcement owner
Need-to-know, least privilege and separation of duties (11.2.2)	Define Superset roles per job function with only the dataset, dashboard and SQL Lab permissions needed. Keep editing and admin roles separate from viewer roles.	Superset roles, reviewed by your access owners
Access register and planned review (11.2.3)	Export role and user assignments on a fixed schedule and retain each review as dated evidence. Superset does not run the review for you.	Your process, with exports from Superset
Identity life cycle and single person per identity (11.5.2)	Provision users only through the IdP so each Superset account maps to one named person. Disable local accounts used for daily work.	IdP for provisioning, your joiner and mover process
Shared identities only with approval (11.5.3)	Avoid shared Superset logins. If a service or shared account is unavoidable, record approval and restrict its roles.	Your approval process, confirmed in Superset user list
Prompt deactivation of unneeded identities (11.5.4)	Deactivate users when the IdP account is disabled, which blocks login through SSO. Confirm that group removal in the IdP also removes Superset role mappings after sign-in.	IdP offboarding, with Superset role sync to confirm
Credential changes, failed log-in blocking, session ending (11.6.2)	Password rules and lockout apply only to local accounts. For SSO users, rely on IdP policy for credential change, lockout and session timeout, and confirm Superset session lifetime settings.	IdP for most controls, Superset for session settings
Separate credentials for administrative accounts (11.6.2)	Keep Superset admin accounts distinct from daily user accounts, with a separate identity in the IdP where possible.	IdP and your privileged access process
Multi-factor or continuous authentication matched to asset classification (11.7.1, 11.7.2, Article 21(2)(j))	Superset does not add MFA itself when login is through SSO. Enforce MFA in the IdP for all users of dashboards that hold classified data, and confirm the IdP applies it to the Superset client.	IdP policy, set by classification owner
Strong authentication for privileged and system administration accounts (11.3.2(a))	Require MFA on the IdP accounts that can reach Superset admin roles or the metadata database. Restrict who can change AUTH_ROLES_MAPPING.	IdP and infrastructure team

Which login option carries MFA into Superset

When Superset delegates login to a provider such as Google or Azure, the sign-in step, including any second factor, happens at the provider. Superset receives an authenticated identity and a set of attributes, then applies its own role mapping. The MFA control therefore sits in the provider's tenant policy, and Superset's configuration can only show that login goes through that provider.

Where MFA is applied: The provider's conditional access or 2-step verification policy challenges the user before Superset receives any token.
Group to role mapping: Superset uses AUTH_ROLES_MAPPING to map group values from the provider's claims to Superset roles, so the group source must be controlled by the entity.
Provider policy to confirm: Check that MFA is required for every user who can reach Superset, that legacy authentication paths are blocked and that exceptions are documented.
Local accounts: Keep at least one local administrator for recovery, store its credentials under privileged account controls and test that it still works when the provider is unavailable.
Session behavior: Confirm how long provider sessions last and whether Superset sessions end when users are disabled at the provider.

Before sign-off, ask the provider administrator for a current export of the MFA policy and a list of excluded users.

How to configure Superset access for an NIS2 review

This sequence sets up Superset so that every user signs in through your identity provider, roles follow need-to-know and least privilege, and the access rights register and review records exist before an assessor asks for them. Each step is verified in staging before it touches production.

Deploy a production metadata database
Platform engineering deploys Superset with PostgreSQL or MySQL as the metadata database instead of the SQLite default used by quickstart and PyPI installs. Confirm the exact database versions against the supported range in the Superset configuration documentation before you provision anything. The step is done when Superset starts against the new database, the migration runs cleanly in staging, and the database backup routine has been tested once.
Set and document the secret key
The platform owner sets a user-specified SECRET_KEY, which Superset requires to start, and stores it in your secrets manager rather than in a configuration file in version control. Write down the rotation procedure using PREVIOUS_SECRET_KEY, including who approves a rotation and how sessions are handled during the change. The step is done when the key is injected from the secrets store, a staging rotation has been rehearsed, and the procedure is filed with the security policy.
Connect the identity provider for all logins
The identity team configures Superset authentication against your central identity provider, using OAuth2 or LDAP as your directory requires, so each person signs in with their own identity. Confirm that the protocol and the provider's multi-factor policy apply to Superset sign-ins, since Superset itself does not enforce the factors. The step is done when a test user completes a login that is traceable to a single named identity and the provider's audit log records it.
Map identity provider groups to Superset roles
The access owner defines AUTH_ROLES_MAPPING so that directory or OAuth groups assign Superset roles automatically, and removing someone from a group removes their analytics access. Build a role matrix that lists each role, the datasets and dashboards it may reach, and the business reason for it, keeping roles narrow enough to reflect need-to-know. The step is done when a test account in each group receives only the roles listed in the matrix in staging.
Disable or restrict local accounts
The platform owner turns off or tightly restricts local database accounts so that no user can bypass the identity provider with a password stored in Superset. Keep one break-glass path under separate control, recorded with its approver and its use logged. Confirm that the configuration reflects this choice by testing a local login attempt in staging, which should fail for ordinary users. The step is done when the local login path is closed or documented as the single exception.
Separate administrative roles from analyst roles
The security lead assigns Admin and other privileged roles to a small named group, separate from the people who build charts and dashboards, to support separation of duties. Privileged accounts should use their own credentials with strong authentication, which the identity provider must enforce for those accounts. The step is done when the list of privileged holders is approved, each holder has a separate administrative identity, and the list is saved for the access register.
Record the access register and schedule the first review
The compliance lead creates the register of access rights, listing each identity, its linked person, its roles, its approver and the date granted, and sets a planned review interval with a named reviewer. Export the role assignments from Superset and the identity provider on the same day so the two sources can be compared. The step is done when the register matches the exports, the first review is booked on the calendar, and the reviewer has confirmed the scope in writing.

Evidence Superset and the identity provider produce for NIS2 access control

Most of the evidence an auditor or competent authority will ask for sits outside Superset itself, in the identity provider, the exported role configuration and your review records. Superset and its metadata database add log and change evidence, but only what you confirm they record and retain.

Identity provider MFA policy and enrollment

Export the MFA policy that applies to the application in your identity provider, along with enrollment and sign-in reports showing which users have a second factor and which sign-ins used it. Article 21(2)(j) and point 11.7 of Implementing Regulation 2024/2690 expect multi-factor or continuous authentication matched to the sensitivity of the data accessed. Keep dated exports in the compliance store, and confirm with the identity team whether privileged admin accounts are subject to a stricter policy. Owner: identity team.

Role matrix and group-to-role mapping

Export the Superset roles, their permissions and the AUTH_ROLES_MAPPING entries that map identity provider groups to those roles. This is the artifact that shows least privilege and separation of duties in configuration. Version the export in Git so each change has an author and a date, and check that no user receives roles directly outside the mapped groups. Owner: platform team with the data governance lead signing off.

User register with owner and status

Maintain a list of every Superset user with the named person they belong to, the business owner who approved access, the groups they hold, their status and the last log-in date. Point 11.5 expects each identity linked to a single person and shared identities only with explicit approval, so flag any generic or service accounts and record who approved them. Reconcile this list against the identity provider each period. Owner: access management or IT operations.

Periodic access review sign-offs

Record each planned review of Superset access: the population reviewed, the reviewer, the decision on each account and the removals made afterwards. Point 11.2.3 requires access rights to be reviewed at planned intervals, and the signed review is what proves the review happened. Ask the reviewer to confirm that removals were carried out in the identity provider as well as in Superset, since a user disabled in one place may still log in through the other. Owner: data owner for each dataset group.

Superset and database log-in and change records

Collect authentication events from the identity provider, Superset application logs and the metadata database for log-ins, failed attempts and changes to users, roles and permissions. Confirm with your platform team which events your logging configuration records, where they are shipped and how long they are kept, rather than assuming completeness. Protect the logs from edit by administrators who manage Superset. Owner: security operations.

Change records for upgrades and secret key rotation

Keep change tickets for each Superset upgrade, including the metadata database backup taken beforehand, the staging test result and the review of UPDATING.md. Record each rotation of the secret key and the use of PREVIOUS_SECRET_KEY during the transition. These records show that authentication and session controls were changed under control and tested. Owner: platform team, with change approval from the service owner.

How role reviews and the access register become NIS2 evidence

Point 11.2.3 of Implementing Regulation 2024/2690 requires access rights to be recorded and reviewed at planned intervals, and point 11.5.4 requires unneeded identities to be deactivated without delay. Superset does not perform either step for you. It can supply the data that an entity's reviewers use, but the review decision, the review interval and the sign-off belong to the entity. Before the first review, confirm the interval with your own risk owners and write it into the access policy, because an assessor will ask for the schedule as well as the records.

A review works from two exports: the user list with each account's roles and authentication source, and the role definitions with their permissions and any row level security rules. Reconcile the user list against the identity provider's active directory, so that every Superset account links to one named person and every account that the identity provider has disabled is also disabled in Superset. Flag any account that is not tied to an individual, such as a generic analytics login, and require written approval for it, since point 11.5.3 allows shared identities only with explicit approval. Check that accounts belonging to leavers and to staff who moved to another team are gone or reassigned. Those checks produce the list of exceptions that the reviewer must resolve.

The outcome of each review should be recorded as a dated entry in the access register: who reviewed, what was checked, which access was kept, changed or removed, and when each removal was made. Removal dates are the figures that show deactivation without delay, so compare them with the leaver dates from HR. Keep the exported files, the reviewer's notes and the register entry together so that the next review starts from the last approved state. Confirm with your auditor or national competent authority what form of evidence they accept, because the Regulation supplies examples rather than a fixed template.

What Superset does not cover for NIS2 Article 21(2)(i) and (j)

Superset can enforce what happens after a user signs in, but several Article 21(2)(i) and (j) obligations sit with your identity provider, HR process, facilities team and communications stack. The cards below mark those boundaries so the evidence you assemble for an assessor comes from the right owners.

MFA enforcement and strength

Superset accepts the login that the identity provider gives it, so the multi-factor policy lives in the IdP. Implementing Regulation 2024/2690 expects authentication strength to match the classification of the asset accessed, and a dashboard on sensitive data may need a stronger method than a dashboard on public data. Confirm which factors your IdP enforces for each group that reaches Superset, and who owns the policy that sets them.

HR joiner, mover and leaver process

Background verification, termination procedures and disciplinary steps fall under Annex section 10, which is an HR and legal process. Superset only reflects it when accounts are deprovisioned in the IdP and roles are changed on transfer. Ask HR which system triggers a leaver event, how long that event takes to reach the IdP, and who signs off the role change when someone moves teams.

Physical access control under point 13.3

Point 13.3 covers physical access to the premises and facilities that house systems. A Superset deployment inherits whatever controls exist in the data center, cloud region or office that hosts its servers and database. Confirm who can reach the hosts, the metadata database and backup media, and record those controls in your asset inventory alongside the Superset components.

Secured voice, video, text and emergency communications

Article 21(2)(j) also asks for secured voice, video and text communications and secured emergency communication within the entity. These channels are outside Superset. If analysts share dashboard links or exported data through chat, email or conferencing, those channels need their own controls. Identify which tools staff use to discuss figures from Superset and confirm that they are covered by your own policy.

Kubernetes operator in alpha

The Apache Superset Kubernetes Operator is in alpha with a v1alpha1 API, and its custom resource schemas may change between releases. The Helm chart is marked deprecated for new deployments in the current development docs. If you plan to run Superset on Kubernetes, treat operator upgrades as a change with testing and a rollback path, and confirm the chart or operator version your team will standardize on before you write the evidence.

Session timeout and log-in blocking behavior

Annex point 11.6.2 expects inactive sessions to end and users to be blocked after a set number of failed log-ins. Superset and Flask-AppBuilder settings govern these behaviors, but the exact keys and defaults can differ by version. Confirm the session lifetime and failed-attempt handling in the version you run by testing them in staging, and document the result as evidence rather than assuming the default.

How NIS2 supervision and pending amendments affect this work

Your access control evidence for Superset will be judged by a national competent authority, not by NIS2 itself, because NIS2 creates no certificate of compliance. Authorities oversee compliance through inspections, security audits, security scans, information requests and administrative fines. In practice, that means the role register, identity provider configuration, access review records and log exports described in this topic must be producible on request, in a form an inspector can follow without a walkthrough from your team. The regime also depends on your classification. Essential entities face ex ante supervision, meaning authorities can check compliance before an incident occurs, while important entities face ex post supervision, which is triggered mainly by evidence of non-compliance. Both carry the same risk-management obligations under Article 21, so the difference is in timing and intensity of scrutiny, not in what must be done.

Two sources can help you decide what that evidence looks like. ENISA published non-binding technical implementation guidance for Implementing Regulation 2024/2690 on 26 June 2025, with examples of evidence and mappings to other frameworks. Use it as a reference for the kinds of records an inspector may expect, but do not treat its examples as a checklist that satisfies your national law. The European Commission's proposal COM(2026) 13, dated 20 January 2026, would amend NIS2 and add a small mid-cap category. It is still a proposal that needs approval by the European Parliament and the Council, so it does not change your obligations today. Plan your Superset access design around the rules in force, and record which proposed changes you are watching and when you will reassess.

Before you rely on any of this, confirm with counsel how your national transposition law implements Article 21 and which supervisory authority and expectations apply to your sector and entity type. Ask whether your authority has published its own evidence requirements, whether it expects specific retention periods for access logs, and how it treats third-party platforms that hold analytics data. Those answers decide how much detail your role reviews and logging need. DeployOpen can prepare the Superset configuration and evidence pack, but the legal interpretation of your obligations and your supervisory position remain your responsibility and that of your advisers.

How much work does NIS2 access control setup in Superset take?

What drives the cost and effort of NIS2 access control setup in Superset?

The main drivers are the number of identity sources, the complexity of the role model, how mature your identity provider already is, the number of data sources Superset must reach, and how much evidence the assessment will ask for. A single corporate IdP with clean groups and a handful of datasets is a small job. Several directories, unmanaged groups, and row level security across many business units multiply the design and testing work. Evidence scope matters too: a team that must show access reviews, deprovisioning records and log retention for several years needs more process design than one that only needs a working configuration. Ask the provider to show how each driver was counted in the written scope.

Which parts of NIS2 access control work are one-time and which recur?

One-time work includes the access design, the role matrix, the Superset authentication configuration (OAuth2 or LDAP with the group-to-role mapping), the SECRET_KEY and session settings, and the first test of login, failed-login blocking and deprovisioning. Recurring work includes periodic access reviews against the role register, credential and secret rotation, reviewing privileged accounts, applying Superset upgrades with a tested backup and staging run, and keeping log retention in line with your policy. Budget for the recurring part separately, because the access review and upgrade cycles continue after the project closes, and an audit will test whether they happened.

What does the entity need to provide before setup can start?

Setup needs administrative access to the identity provider so that SSO applications, groups and multi-factor policies can be configured, plus a way to test sign-in with real accounts. It also needs HR data or an agreed joiner, mover and leaver feed, because Implementing Regulation 2024/2690 expects access to change on termination or role change. Name an owner for each role, a person who approves access, and a register where access is recorded. Finally, decide whether local Superset accounts will exist at all, and if so, who holds them and how they are protected, since shared or unmanaged local accounts conflict with the requirement that each identity map to one person.

Can our own team set up NIS2 access control in Superset without a partner?

Yes, a team with Superset, identity provider and security skills can do the work alone, and many do. The questions to answer honestly are whether someone owns the identity provider configuration, whether the team has time to write the role matrix and review procedure, and whether anyone has tested Superset's authentication settings against the Flask-AppBuilder documentation. A partner adds most value when the scope is wide, when several identity sources must be unified, or when the evidence must be organized for an assessment. Whichever path you choose, the Superset upgrade documentation expects a metadata database backup and a staging test before each upgrade, and that work needs an owner too.

What should a written quote for NIS2 access control setup include?

A fixed-scope quote should list the systems in scope, including the Superset instances, the identity sources and the datasets or databases behind them. It should name each deliverable, such as the role matrix, the authentication configuration, the access review procedure, the test records and the operating runbook. Ask which tasks are one-time and which are retainers, what the provider needs from your team, what is excluded (for example, changes to the identity provider beyond Superset, or HR system integration), and how changes to scope are handled. Confirm who is responsible for assessment evidence and whether it is delivered in a form your auditor can read.

Does DeployOpen issue NIS2 certificates for Superset access control?

No. NIS2 does not create a certificate of compliance. National competent authorities oversee compliance through inspections, security audits, security scans, information requests and administrative fines. DeployOpen prepares systems, configuration and evidence, such as role registers, test records and access review logs, so that your organization can show how Superset access is controlled. Independent auditors and the relevant authorities make the assessment, and DeployOpen does not issue audit reports, attestations or certifications.

What does ongoing support look like after the NIS2 setup is finished?

After the initial build, most organizations need someone to run the access review cycle, process joiner, mover and leaver changes, rotate secrets and keys, and plan Superset upgrades. These tasks can stay with your team or move to a retainer. DeployOpen offers ongoing support, upgrades and continuous testing as retainers, and the scope of any retainer is agreed in writing. Ask for the review calendar, the named owner for each recurring task, and the records each cycle will produce, because those records are what an assessor will ask to see.

How DeployOpen scopes and delivers NIS2 access control configuration

DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure, and Apache Superset is one of them. For NIS2 access control and authentication, we configure Superset's login path, roles and evidence trail so your team can show how access decisions were made and reviewed.

How we scope

We confirm which Superset datasets, dashboards and roles fall under your Article 21 access control policy before any configuration starts.
We agree the identity provider, group-to-role mapping and MFA responsibilities in writing, with the owner of each decision named.
Engagements are fixed-scope, so deliverables, timelines and exclusions are recorded in the agreed statement of work before work begins.

How we build

We configure Superset login through your identity provider so local password accounts are removed or restricted to approved break-glass use.
We map identity provider groups to Superset roles, keeping administrative roles separate from analyst and viewer roles.
We test failed log-in lockout, session timeouts and role changes in a staging environment before any change reaches production.

How we hand over

We document the access model, role register, joiner, mover and leaver steps and the periodic role review procedure for your team to run.
We show your team how to export role and user assignments and where Superset and identity provider logs record authentication and permission changes.
We transfer configuration as code and runbooks so your engineers can reproduce, audit and change the setup without DeployOpen involvement.

How we support

Ongoing support, Superset upgrades and continuous testing are available as retainers, so access settings are retested after each release.
Upgrades follow the project's documented steps, including a metadata database backup and staging tests before production changes.
Support can cover periodic access review runs and evidence collection, while the review decisions and any audit remain with your organization and its auditors.

Apache Superset for NIS2 access control and authentication