What NIS2 requires for open source SSO multi-factor authentication
If your organization is an essential or important entity under NIS2, the short answer is that you need a workforce login layer that uses multi-factor or continuous authentication where appropriate, as Article 21(2)(j) asks, and that meets the access control points of Commission Implementing Regulation (EU) 2024/2690 for privileged and administration accounts. For most organizations that means one identity provider, such as a self-hosted Keycloak or ZITADEL deployment, with a written MFA policy and separate controls for administrator accounts. NIS2 does not issue a certificate of compliance. National competent authorities oversee compliance through inspections, security audits, security scans, information requests and administrative fines, so your job is to produce configuration, policy and access review evidence that holds up when someone asks for it.
Two parts of the rules shape the design. The Annex to Regulation 2024/2690 requires policies for privileged and system administration accounts, including dedicated admin accounts used only for administration, individualized privileges, and separate credentials for privileged accounts. It also requires authentication strength to match the classification of the asset accessed, and periodic review of privileged access rights with documented results. Confirm with your national competent authority and your legal team which entity category you fall under, because Articles 32 and 33 apply different supervision regimes to essential and important entities. Also confirm how your Member State has transposed NIS2, since transposition is national and Article 5 allows stricter national rules.
Treat the regulation as the baseline, not the final word. The Commission's February 2026 proposal (COM(2026) 13) would amend NIS2, including a new small mid-cap category, but it still needs approval by the European Parliament and the Council, so do not design around it yet. ENISA's non-binding technical implementation guidance from June 2025 gives examples of evidence that auditors and regulators already use as reference. Before choosing Keycloak, ZITADEL or authentik, ask your candidate partner to map each requirement in the Annex to a configuration setting, an exported report or a documented procedure, and to show which items remain manual.
How Article 21(2)(j) and Regulation 2024/2690 map to SSO configuration
This table maps each NIS2 and Implementing Regulation 2024/2690 requirement relevant to workforce login to what the identity provider must do and where Keycloak or ZITADEL settings deliver it. Read each row as a control, the configuration that supports it, and the evidence an assessor will ask for. Confirm the final mapping with your national competent authority and your qualified assessor, because the regulation applies through national transposition.
| Requirement | What the function must do | How to configure Keycloak or ZITADEL |
|---|---|---|
| Article 21(2)(j): MFA or continuous authentication where appropriate | Require multiple factors or continuous authentication for workforce access where risk justifies it, and document where it is judged not appropriate. | Keycloak: set realm browser flow to require OTP or WebAuthn for the workforce group. ZITADEL: set the login policy to require a second factor and enable passkeys. Export the flow or policy as evidence. |
| Points 11.7.1 and 11.7.2: strength matched to asset classification | Assign each application a classification and require authentication strength at or above that level, with step-up for higher-value assets. | Keycloak: create conditional authentication flows keyed to client or role, with step-up to WebAuthn for classified clients. ZITADEL: apply per-application or organization policies with a second factor requirement for sensitive projects. |
| Point 11.3 and 11.3.2: privileged account policy and dedicated admin accounts | Require strong identification, MFA and authorization for privileged accounts, dedicated accounts used only for administration, and individualized admin privileges. | Keycloak: create separate admin users, bind them to required MFA in a dedicated authentication flow, and grant roles per user rather than shared groups. ZITADEL: create separate human users for administration in a dedicated organization with its own login policy. |
| Point 11.4: administration systems separated and protected | Use administration systems only for administration, logically separated from other applications, and protected by authentication and encryption. | Keycloak: place administration consoles in a separate realm, such as an admin realm, with its own clients, flows and session limits. ZITADEL: use a separate instance or organization for administration. Restrict network paths to the admin realm. |
| Point 11.3.3: access reviews for privileged accounts | Review privileged access at planned intervals, adjust after organizational changes, and record review results. | Keycloak: export role mappings and admin user lists per realm on a schedule and keep signed review records. ZITADEL: export user grants and role assignments through the management API. Confirm the review interval with your policy owner; it is not set by the regulation text supplied here. |
| Point 11.6.2: credential changes and lockout | Require credential change at first use, at set intervals and on suspected compromise, block accounts after a set number of failed logins, and use separate credentials for privileged accounts. | Keycloak: enable brute force detection in the realm, set required actions for password update and reset, and set a separate password policy on the admin realm. ZITADEL: set lockout and password change rules in the login policy and password complexity settings. |
| Point 11.6.2: session ending for inactive sessions | End inactive sessions and limit session lifetime, with shorter limits for privileged access. | Keycloak: set SSO session idle and max lifetimes per realm, and shorter values on the admin realm. ZITADEL: set session lifetime and inactivity settings in the instance or organization policy. Record the values in the configuration export. |
Which open source identity platforms fit NIS2 MFA requirements
NIS2 does not name a product, but the Implementing Regulation 2024/2690 expects MFA matched to asset classification, separate privileged credentials and documented reviews. The platforms below differ in protocols, directory support, licensing and how much of the MFA and privileged-account story is included in the free edition.
Keycloak for broad protocol coverage
Keycloak is Apache-2.0 licensed and supports OpenID Connect, OAuth 2.0 and SAML 2.0, with LDAP and Active Directory user federation. Its Operator manages Keycloak and client resources on Kubernetes, and the project documents three high availability designs, all of which depend on a synchronously replicated database. Confirm which MFA methods and admin role separation your policy requires, then test them in a staging realm before rollout. Current release: 26.8.1.
ZITADEL for passkeys and tenancy
ZITADEL is AGPL-3.0 licensed and lists SSO, MFA, passkeys (FIDO2 and WebAuthn), SAML 2.0, SCIM and multi-tenancy in its README. Passkeys support phishing-resistant login for administrators, and SCIM supports automated provisioning and deprovisioning from a source directory. Check the AGPL-3.0 obligations with your legal team if you modify the code and expose it to users, and confirm which passkey and admin policies are in the version you deploy.
authentik with a split license
authentik's core code is MIT licensed, but the authentik/enterprise directory uses a separate enterprise license. Its pricing page places mTLS client certificate authentication, privileged access management and enhanced audit logging in the Enterprise tier, so a NIS2 design that relies on those controls needs a paid subscription. Since 2025.10 authentik runs on PostgreSQL without Redis, which simplifies the stack but raises connection counts after upgrade. Confirm the feature set against your written requirements.
FreeIPA for Kerberos-centric estates
FreeIPA suits Linux and Windows estates that already authenticate through Kerberos and LDAP, combining a directory, certificate authority and host identity in one stack. It fits organizations that need MFA on SSH and host logins close to the directory, but its web SSO and SAML coverage for modern SaaS apps is narrower than Keycloak or ZITADEL. Confirm the MFA integration path, the replication topology and how privileged group membership is reviewed before choosing it as the primary login source.
midPoint for access reviews
midPoint is an identity governance platform licensed under EUPL 1.2 or later, and it is a companion rather than a login provider. Point 11.3.3 of the Annex to Implementing Regulation 2024/2690 requires privileged account rights to be reviewed at planned intervals and the results documented, which is the job midPoint's certification workflows support. Pair it with your SSO platform and confirm how it reads role changes from your HR source. The 4.8 Curie long-term support release is supported until October 17, 2028.
Ory as a non-fit for admin login
Ory Kratos and Ory Hydra are Apache-2.0 components aimed at building customer-facing login and OAuth 2.0 services inside applications. They do not provide a workforce administration console, directory federation for staff or a built-in privileged access model, so they are a weak fit as the sole identity provider for employees. Use them where your engineering team builds the login experience, and pair them with a workforce platform for administrators.
How Keycloak or ZITADEL enforces MFA and privileged account separation
The configuration pattern is an MFA step that cannot be skipped for the populations NIS2 cares about, plus a separate administrative plane for privileged accounts. In Keycloak, that usually means a required OTP or WebAuthn authentication step in the browser flow, with a conditional step scoped to administrator roles or to high-classification client applications so that authentication strength follows the asset being accessed. ZITADEL expresses the same idea through its login policy, where MFA can be enforced for an organization and passkeys (FIDO2 and WebAuthn) can be offered as a factor. Whichever product you choose, confirm in the exact version you deploy which authentication flow, condition and policy objects exist and how they are exported, because flow and policy names have changed across releases.
For privileged accounts, the common pattern is a dedicated realm in Keycloak (or a separate organization in ZITADEL) that holds only administrators, with no self-registration, its own password and MFA policy, and a short session lifetime. Administrators then sign in with their own named admin accounts, separate from their everyday identity, and those accounts should be restricted to administration clients. Lockout after a set number of failed log-ins, idle session timeouts and forced credential changes are configured per realm or policy, and the values you choose should be recorded in the configuration export you keep as evidence. Confirm how each setting is named and enforced in your version, and test each one with a real failed log-in, an expired session and a privileged sign-in before you rely on it.
This is configuration work, not a compliance claim. Setting these options does not by itself satisfy Article 21(2)(j) or the access control points of Implementing Regulation 2024/2690, and whether your settings meet the classification of each asset is a decision for your risk owners and assessors. Plan the deliverables as a written authentication standard, exported realm and policy configurations under version control, test records for each control, and a schedule for reviewing privileged access rights. For the current release line, check the release notes for Keycloak or ZITADEL before you pin a version.
How an NIS2 MFA rollout runs from scoping to evidence
The sequence turns NIS2 authentication obligations into a scoped, tested and documented workforce login design, with each phase producing evidence an assessor or national authority can review. It starts with scope and ends with records that show MFA and privileged account controls operate as described.
Scope applications and administration systems
The team lists every application, directory and administration system that workforce users reach, including VPN, email, remote desktop and cloud consoles. It records which applications support SAML, OpenID Connect or LDAP and which do not, because legacy systems often need a separate control. The output is a signed inventory with an owner for each entry. It is done when the inventory reconciles with the asset register the organization already uses for its risk assessment.
Classify assets for authentication strength
Working with the risk owners, the team assigns each asset a classification and a required authentication strength, since Implementing Regulation 2024/2690 expects strength to match the classification of the asset accessed. Administration systems are tagged separately so that privileged rules apply to them. The output is a mapping table from asset class to login policy. It is done when each entry has an approved owner and a documented rationale.
Deploy a supported identity provider release
The platform team installs a supported Keycloak or ZITADEL release inside the organization's own cloud account, data center or isolated network, using a highly available design. Documented Keycloak designs require a synchronously replicated database, so the database topology is confirmed before go-live. Operator updates should be approved manually rather than applied automatically. The output is a tested environment with a recorded version, configuration baseline and restore test.
Enroll multi-factor authentication in phases
Staff are moved to the identity provider in waves, starting with a pilot group and then the applications graded highest in the classification table. Each wave defines enrollment steps, recovery paths and help desk procedures for lost tokens. Failed-login lockout, session timeouts and forced credential changes are configured to match the authentication procedure rules in the Annex. The output is an enrollment report per wave showing coverage and exceptions. It is done when every in-scope user is enrolled or has a documented, time-limited exception.
Separate and review privileged accounts
Administrators receive dedicated accounts used only for administration, with individualized privileges and separate MFA. Administration systems are restricted so that these accounts connect only to administration tools. The access rights are reviewed at planned intervals and after organizational changes, and each review is recorded. The output is a privileged account register and the first signed review record. It is done when no shared or general-purpose account holds administrative rights.
Test failure modes and recovery
The team tests what happens when the identity provider, its database or a cluster node fails, and confirms that emergency access and recovery steps work as written. Upgrade paths and database migration steps are rehearsed in a non-production copy. The output is a dated test record with observed results and corrective actions. It is done when the test results are accepted by the system owner and the gaps are tracked to closure.
Assemble the compliance evidence pack
The team gathers configuration exports, policy documents, MFA enrollment reports, privileged account registers, review records, log samples and test results into one evidence pack mapped to the relevant Annex points. NIS2 creates no certificate, so the pack supports inspections and information requests rather than a badge. An independent assessor decides whether the evidence is sufficient. The output is an indexed pack with an owner and a review date for each artifact.
Evidence auditors and authorities ask for from SSO and MFA
This table lists the evidence each NIS2 access control requirement tends to draw from a self-hosted SSO and MFA platform, the component that produces it, and what to confirm before an assessment. Read each row as a question the assessor will ask, then check whether your deployment can answer it with an export, a log or a test record. DeployOpen prepares these systems, controls and evidence for assessment, but does not issue audit reports, attestations or certifications; independent auditors and national authorities make those determinations.
| Evidence item | Component that produces it | What to confirm before an assessment |
|---|---|---|
| Realm and authentication flow exports | Keycloak realm export or configuration-as-code; ZITADEL instance and login policy settings | Exports are versioned, taken after each change and show which flows require MFA for which clients |
| MFA enrollment and policy records | Keycloak required actions and conditional authentication; ZITADEL MFA and passkey policy | Enrollment counts by group, who has not enrolled, and how exceptions are approved and expired |
| Privileged account inventory and dedicated admin account list | Directory or identity store export, such as FreeIPA or Keycloak users filtered by admin roles | Each admin account is separate from a daily user account and is tied to a named owner |
| Access review records under point 11.3.3 | Review tickets or identity governance output, such as midPoint certification campaigns where used | Reviews happen at planned intervals, role changes are applied, and results are signed off and stored |
| Lockout and session configuration | Keycloak brute force detection and session settings; ZITADEL lockout and session policy | Failed-login thresholds, session idle timeouts and forced credential changes match the written policy |
| Admin event and login audit logs | Keycloak admin events and login events; ZITADEL audit events | Events are enabled before go-live, include the actor and target, and are forwarded off the identity server |
| Retention and log integrity | A SIEM such as Wazuh, which can collect identity logs and hold them on separate storage | Retention period set by your policy and legal counsel, with tests that old logs can still be retrieved |
| Change and upgrade records | Git history for configuration, Keycloak Operator update approvals, and change tickets | Each Keycloak or ZITADEL upgrade has a test result, an approver and a rollback plan on file |
| High availability and backup test records | Database backup jobs, restore test logs and failover test reports for the identity cluster | Restores were tested into a separate environment and failover results include the date and the outcome |
What SSO and MFA tooling alone does not satisfy under NIS2
An identity provider with MFA handles authentication, but Article 21 and Implementing Regulation 2024/2690 also expect controls around accounts, reviews, governance and reporting. The cards below cover the areas that sit outside the login flow and need their own owners, records and checks.
Legacy apps without SAML or OIDC
Applications that only accept local passwords, LDAP binds or header-based trust cannot send a Keycloak or authentik login through the standard flow. Each one either needs a gateway in front of it, a connector, or a documented exception with compensating controls. Inventory these apps first, then confirm whether the vendor can enable federation, since a local login that bypasses the identity provider still needs MFA or a compensating control under the authentication requirements of Annex point 11.6.2 and the multi-factor requirements in point 11.7.
Shared and emergency accounts
Shared operator IDs, break-glass accounts and service logins sit outside the per-person model that SSO assumes. Point 11.3.2 requires dedicated administration accounts, individualized admin privileges and credential changes on suspected compromise. Document who holds each shared credential, where it is vaulted, how use is logged and how it is rotated after each use, and test the emergency path before an incident forces it.
Access reviews and joiner-mover-leaver processes
Point 11.3.3 requires privileged and administration access to be reviewed at planned intervals, adjusted after organizational changes, and recorded. An SSO tool does not decide who should have access or remove it when someone changes role. Identity governance platforms such as midPoint can drive provisioning and certification campaigns from an authoritative HR source. Confirm which system is the source of truth, who signs off each review, and how removals reach every connected application.
Policy and governance documents
Article 21 measures and the access control policies in Implementing Regulation 2024/2690 must exist as approved, versioned documents with owners and review dates. A working MFA configuration does not prove that a policy was written, approved by management and enforced. Map each technical setting, such as lockout thresholds, session timeouts and MFA scope, to a named policy clause, and keep the approval record with the configuration export.
Incident reporting and supplier obligations
Article 23 sets reporting deadlines for significant incidents, and identity compromise is often the first sign of one. Login failures, impossible-travel alerts and admin-account changes must reach a team that can classify an incident and report it within the deadlines set by the competent authority. Supplier access to the identity platform, including vendor support accounts and managed services, also falls within supply chain risk. Confirm how identity logs flow to the monitoring system and who holds the reporting decision.
Pending national and proposal changes
NIS2 is a directive, so obligations reach a given entity through its national transposition law, which may add or raise requirements under Article 5. The Commission's January 2026 proposal COM(2026) 13, which would add a small mid-cap category, still needs approval by the European Parliament and the Council. Confirm your national implementing law, your classification as essential or important, and whether the proposal changes your scope before you fix the MFA design.
Questions buyers ask about NIS2 MFA and open source SSO
Does NIS2 name a specific MFA product that we must buy?
No. NIS2 does not name products. Article 21(2)(j) asks for multi-factor or continuous authentication where appropriate, and Implementing Regulation 2024/2690 sets the outcomes in more detail, including authentication strength matched to the classification of the asset accessed. Keycloak, authentik, ZITADEL and other platforms can meet those outcomes, but the choice is yours. Confirm the obligations that apply to your entity with your national competent authority and your legal team, because national transposition laws shape how the directive applies in each Member State. The NIS2 Article 21 text is the starting point for that review.
What drives the effort of an open source SSO rollout?
The main drivers are the number of applications to integrate, how many of them can speak SAML or OIDC, and how many directories must be federated. Legacy applications without modern protocols often need a proxy, a custom connector or a retirement decision, and that work usually takes longer than the identity provider itself. Other drivers are high availability design, the separation of administrator accounts from everyday accounts, MFA enrollment for every user group, and the audit logging you must retain. Ask a partner to inventory each application and directory before estimating, and to show how each item is counted in the scope.
Can our own team run Keycloak or ZITADEL without a partner?
Many teams can, provided they have staff who understand identity protocols, Kubernetes or virtual machine operations, PostgreSQL administration and certificate management. The ongoing work includes realm and client configuration, MFA policy, user lifecycle, backups, monitoring and upgrades, and that work continues after go-live. Plan for a named owner, a documented runbook and a test environment that mirrors production. A partner can fill gaps in the first rollout, while your staff keep operating the platform. Whichever route you pick, write down who responds when the identity provider is unavailable.
How are Keycloak upgrades handled without breaking logins?
Keycloak plans four minor releases a year, and since Keycloak 26.0 breaking changes in a minor release are opt-in, according to the project's October 2024 release update. The Keycloak Operator documentation strongly recommends manual approval mode for operator updates so that upgrades do not happen unintentionally. Database schema migration runs automatically at startup by default, but administrators can apply the SQL themselves, which the upgrading guide suggests for large deployments. Keep a staging environment, read the upgrading guide for each target version, and back up the database before each change. The current release at the time of writing is 26.8.1, so confirm which version your partner targets and how long it will be supported.
What are the cost components of self-hosted SSO for NIS2?
Keycloak and ZITADEL are open source and carry no license fee for the core product, so the costs are infrastructure, database, integration labor, MFA rollout, testing, documentation and ongoing operations. Infrastructure and database costs recur, while integration, design and rollout are mostly one-time. Costs rise with application count, high availability requirements, the number of user populations and the number of audit evidence items you need. Paid editions, such as the authentik Enterprise tier that lists privileged access management and enhanced audit logging, add subscription fees that recur per user or per year. The authentik pricing page lists Enterprise at $5 per user per month billed annually, plus $0.02 per external user per month, so compare that figure against your headcount.
What should a quote for NIS2 MFA SSO include?
A useful quote lists the scope in writing: the applications and protocols in each phase, the directories to federate, the MFA methods and enrollment approach, the privileged account design, the high availability topology and the database. It should also state the test plan, the rollout waves, the documentation and evidence deliverables, the training, and the handover to your operations team. Ask what is excluded, such as legacy applications that will not be integrated, and what happens when scope changes. DeployOpen works from a fixed scope agreed in writing before work starts, and does not publish a price list, so the quote follows from that scope.
Does DeployOpen issue a NIS2 certificate for our SSO?
No. NIS2 creates no certificate of compliance, and DeployOpen does not issue audit reports, attestations or certifications. National competent authorities oversee compliance through inspections, audits, scans, information requests and fines. DeployOpen can plan, implement, harden and document a self-hosted identity platform and prepare the configuration exports, access reviews and logs that your assessors may ask for. Independent auditors and certification bodies make the assessment decisions, so confirm with them early which evidence they expect.
Where to read the regulation and platform documentation
Start with the legal text, then the technical detail. Article 21 of NIS2 sets out the risk-management measures, and paragraph 2(j) is where multi-factor or continuous authentication appears, applied where appropriate. Read the article in the EUR-Lex text of Article 21, then open Commission Implementing Regulation (EU) 2024/2690 and go to the Annex. The points that matter for workforce login are 11.3 (privileged and administration accounts), 11.4 (administration systems), 11.6.2 (authentication procedures) and 11.7 (authentication strength matched to asset classification). Your compliance lead should map each point to a named login policy, admin account standard or review record in your own environment. For evidence examples, read the ENISA NIS2 technical implementation guidance, published in June 2025. It is non-binding, but it shows what an assessor may ask to see and how the measures map to frameworks such as ISO/IEC 27001:2022 and NIST CSF 2.0. Use it to decide which exports you will keep, such as realm authentication flow settings, required action records and admin role assignments. Confirm with your national competent authority and your transposing law how these requirements apply to your entity, because Member States may add or keep stricter rules under Article 5. For the platform side, the Keycloak documentation answers the operational questions. Read the Keycloak high availability overview to choose between the single cluster design and the multi-cluster options, noting that both supported designs depend on a synchronously replicated database. Then read the Keycloak upgrading guide before you pick a version, and test every minor upgrade against your MFA flows and admin roles. Ask your partner to show the test plan in writing.
How DeployOpen scopes, delivers and supports NIS2 SSO and MFA
DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted open-source identity platforms inside the client's own infrastructure. For NIS2 workforce MFA, we start from the written scope of which applications, administrator accounts and assets need which authentication strength, then build and hand over the identity platform and the evidence that supports a compliance assessment.
How we scope
- Inventory which workforce applications, networks and administration systems sit behind the identity provider
- Map each asset classification to the MFA strength and session rules agreed with your compliance lead
- Agree in writing the deliverables, exclusions and timeline before any build work starts
How we build
- Deploy Keycloak or ZITADEL in your cloud accounts, data centers or air-gapped network with a production database
- Configure MFA, separate credentials and dedicated accounts for privileged and administration access
- Test failed-login lockout, credential change, session termination and high availability failover before go-live
How we hand over
- Document configuration exports, access review procedures and the evidence each control produces
- Provide runbooks for enrollment, recovery, privileged account reviews and identity provider outages
- Train your administrators on operating the platform and preparing evidence for assessors
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer after handover
- Test each Keycloak or ZITADEL upgrade in staging before applying it to production
- Keep the identity platform and its MFA controls documented as your scope and applications change
