NIS2 in Practice: Implementing MFA, Access Control, and Audit Trails with Authentik in a GDPR-Compliant Way

Table of Contents

• Six months of the NIS2UmsuCG: where implementation stands in June 2026
• What NIS2 actually requires: access control and MFA in Section 30(2) BSIG
• Implementing multi-factor authentication under Section 30(2) no. 10 with Authentik
• Access control under Section 30(2) no. 9: RBAC, groups, and application-bound policies
• Audit trails and the documentation obligation: events, retention, and forwarding
• GDPR-compliant and sovereign: Art. 32, hosting in Germany, and the DPA
• The honest limits: what an IAM delivers for NIS2 and what it does not
• Step by step: NIS2-relevant identity building blocks in Authentik
• authhost: Managed Authentik on German infrastructure
• Conclusion
• Sources

Six months of the NIS2UmsuCG: where implementation stands in June 2026

The NIS2 implementation act (NIS2UmsuCG) was promulgated in the Federal Law Gazette on December 5, 2025, and entered into force without a transition period on December 6, 2025 [1]. As of June 6, 2026 it has thus been in effect for half a year. The German transposition significantly broadens the circle of affected entities: instead of the few thousand critical-infrastructure operators under the old framework, around 29,500 companies now fall under the amended BSIG [1]. According to a projection in the government draft of December 2023, these are expected to split into roughly 8,250 essential and 21,600 important entities across 18 sectors; this split is an estimate from the explanatory memorandum, not an officially recorded actual figure [2].

Practice is lagging behind the obligation. Within three months of entry into force, affected entities had to register with the BSI under Section 33(1) BSIG, that is by March 6, 2026; the reporting and information portal had been available since January 6, 2026 [1]. According to the half-year review BDO published in early June 2026, only around 11,500 companies were registered by the deadline, about 38.5 percent. By early April the rate rose to around 15,500 entities, just over 50 percent [1]. These figures are a BDO analysis, not an audited BSI statistic, but they show the scale of the gap.

For decision-makers this matters because a missed registration can have supervisory consequences regardless of whether an incident ever occurs. Anyone catching up on registration needs robust risk management in parallel. This is exactly where the technical minimum measures come in.

What NIS2 actually requires: access control and MFA in Section 30(2) BSIG

Section 30(2) BSIG lists ten minimum measures that essential and important entities must implement according to the state of the art. Two of them are directly identity topics [3]:

These two numbers transpose Article 21(2) of the NIS2 Directive (EU) 2022/2555 into German law. There, point (i) corresponds to personnel security and access-control concepts, and point (j) to multi-factor or continuous authentication as well as secured voice, video, and text communication [4][5].

The reading matters: the law requires a concept for access control and the use of MFA, not a specific product or technology. It is not a checkbox you tick by buying software, but an implemented, documented, and verifiable architecture. An identity provider is the tool with which this architecture can be mapped technically; the concept behind it you must formulate yourself.

Other numbers from Section 30(2) BSIG are touched by an IAM only marginally: incident handling (no. 2), assessing the effectiveness of the risk-management measures (no. 6), and cryptography (no. 8) [3]. We return to those under the limits.

Implementing multi-factor authentication under Section 30(2) no. 10 with Authentik

In Authentik, MFA is not a global setting but a stage in a flow. The Authenticator Validation stage checks a second factor at a defined step of the login flow. Supported are TOTP, WebAuthn/FIDO2/passkeys, static recovery codes, SMS, email, and Duo [8]. Which of these methods are permitted at a concrete step is controlled by the stage's device-class configuration. This lets you enforce that privileged roles use only phishing-resistant passkeys, while TOTP remains permissible for other groups.

This aligns with the BSI's assessment: in its NIS2 info package on multi-factor authentication, the BSI recognizes passkeys as very secure, phishing-resistant authentication based on cryptographic key pairs and recommends two factors from different categories for higher protection levels. Passkeys, however, are mentioned neither in the NIS2 Directive nor in the BSIG and are not mandatory [7]. Authentik gives you the freedom to stagger this in a risk-based way instead of prescribing one factor for everyone.

Authentik catches brute-force attempts with throttling: repeated failures are delayed with exponential back-off, following the formula delay_seconds = factor * 2^(n-1) [8]. This protection already applied to TOTP and static codes; with version 2026.5, released on May 22, 2026, it was extended to email and SMS OTP [11][12]. WebAuthn and Duo are not throttled, and a factor of 0 disables the throttling [8]. Anyone running an existing Authentik instance should update to at least 2026.5 for the NIS2 implementation to gain this extended protection.

How Authentik fares against the large US providers on MFA is shown in our Authentik vs. Entra ID comparison and our comparison with the Okta alternative Authentik.

Access control under Section 30(2) no. 9: RBAC, groups, and application-bound policies

In Authentik, access control covers two distinct layers that should be kept cleanly apart.

The first layer is internal administration via RBAC. Roles bundle permissions and are assigned to groups or users; they control who may manage which objects within Authentik, such as creating users, editing flows, or connecting applications. Authentik distinguishes between global and object-level permissions here [9]. With version 2025.12 the project unified the model: permissions are since then granted exclusively via roles, direct user permissions are removed and were migrated into automatically created roles [13]. This makes the permission model more consistent and therefore more auditable, a practical plus for documentation.

The second layer is application access. Which user can reach a connected application at all is governed by application-bound policies and group membership. A policy can, for example, check whether a user is in the "Finance" group before the accounting software is released. This produces a traceable access-control concept that matches exactly what Section 30(2) no. 9 BSIG and Article 21(2)(i) of the NIS2 Directive require as an access-control concept [3][4].

For regulated entities, separating these two layers matters: the question "who may administer Authentik itself?" is different from "who may access the ERP application?". A good access concept documents both separately. How this compares against self-hosted alternatives is examined in the comparison Authentik vs. Authelia vs. Keycloak.

Audit trails and the documentation obligation: events, retention, and forwarding

NIS2 and GDPR require not only that measures exist but that their effectiveness is verifiable. That calls for audit trails. Authentik logs every event and strips credentials from the stored data in the process; it records, among other things, the user involved, the timestamp, and the action performed [10]. Logins, failed logins, permission changes, and administrative interventions thus land in a searchable event log.

The default retention is 365 days and can be adjusted in the system settings [10]. For documentation over longer periods a single IAM log rarely suffices, though: events can be forwarded via notification transport to local targets, email, or webhook and thus fed into a central SIEM that handles audit-proof long-term retention [10].

This audit trail feeds directly into GDPR Art. 32(1)(d), which requires a procedure for regularly reviewing, assessing, and evaluating the effectiveness of the technical and organizational measures [6]. Anyone who logs who accessed what and when can demonstrate that effectiveness. In an emergency, the event log also provides the basis for the incident analysis that feeds into a NIS2 report. How a concrete incident can be contained with Authentik is described in our article on the immediate response with Authentik Account Lockdown.

GDPR-compliant and sovereign: Art. 32, hosting in Germany, and the DPA

NIS2 and GDPR overlap on the topic of security of processing. GDPR Art. 32(1) requires technical and organizational measures appropriate to the risk: among them pseudonymization and encryption (point a), ensuring confidentiality, integrity, availability, and resilience (point b), rapid restoration after an incident (point c), and the already mentioned procedure for regularly reviewing effectiveness (point d) [6].

An identity provider processes particularly sensitive data: identities, credentials, and complete access logs. Where this data resides is therefore not a side issue. An Authentik instance on infrastructure in Germany keeps identity and audit data in an EU-sovereign environment, beyond the reach of the US CLOUD Act. On the organizational side, a data processing agreement (DPA) belongs to this, regulating the obligations between the entity and the host.

To stay honest, though: GDPR compliance is not purely a product property. Hosting in Germany and a DPA address the technical and organizational measures, but the record of processing activities, the legal bases for processing, and safeguarding data-subject rights remain your responsibility. A sovereign infrastructure is a necessary, not a sufficient, condition.

The honest limits: what an IAM delivers for NIS2 and what it does not

This classification is the core of the article: a cleanly configured Authentik hosted in Germany addresses Section 30(2) no. 9 and no. 10 BSIG as well as the audit expectation from GDPR Art. 32 technically. But it does not replace a compliance program.

Concretely, an identity provider does not cover the following measures [3]:

• Incident handling (no. 2) beyond pure account containment: playbooks, roles, and escalation paths are organizational.
• Assessing effectiveness (no. 6) as a process: the event log supplies data; the assessment itself is a recurring management process.
• Cryptography (no. 8), backup and crisis management, supply-chain security, and training: their own technical and organizational measures.

On top of this come the reporting obligations under Section 32 BSIG: an initial report or early warning without undue delay, at the latest within 24 hours, a follow-up report within 72 hours, and a final report within one month [2]. That is a process topic, not a product feature. And finally, under the BSIG management bears personal responsibility for the risk-management measures; in case of violations, essential entities face fines of up to EUR 10 million or 2 percent of worldwide annual turnover under Section 65 BSIG, important entities up to EUR 7 million or 1.4 percent [2].

The message is not that an IAM delivers little, but that it delivers the right thing: it maps two of the ten minimum measures cleanly in technical terms and provides the audit basis for a third. That is a solid, clearly delimited building block in a larger risk-management framework.

Step by step: NIS2-relevant identity building blocks in Authentik

Anyone who wants to translate the theory into a concrete configuration proceeds in this order:

1. Make MFA mandatory. Add an Authenticator Validation stage to the authentication flow and use the device classes to define which methods are permitted, for example only passkeys for administrators [8].
2. Stagger factors by risk. Separate privileged roles from standard users and enforce phishing-resistant methods for the former, as the BSI recommends for higher protection levels [7].
3. Clean up RBAC. Grant administrative permissions exclusively via roles and groups; from 2025.12 this is the only way anyway [13].
4. Bind application access via policies. Tie access to every connected application to group membership or a policy instead of opening it up broadly [9].
5. Configure audit retention and SIEM forwarding. Check the 365-day retention and set up a notification transport via webhook into your SIEM [10].
6. Update to 2026.5. This gives you, among other things, the extended OTP throttling and current conditional-access signals [11].

Each of these steps is documentable and therefore part of the concept required under NIS2. Anyone comparing Authentik with other open-source solutions finds further decision aids in the Auth0 alternative Authentik and the Keycloak alternative Authentik.

authhost: Managed Authentik on German infrastructure

Handling licensing, updates, and audit-proof audit logs yourself is demanding for SMBs without their own SOC, especially under the time pressure of the NIS2 implementation. authhost runs your dedicated Authentik instance as a managed service on infrastructure in Germany and keeps it on the current release. Identity and audit data stay in an EU-sovereign environment, a data processing agreement (DPA) is included, which addresses the technical and organizational measures under GDPR Art. 32. What every instance includes is shown in the feature overview; plans start at EUR 34.90 per month (plans and pricing).

To stay honest: authhost isn't the right choice for everyone, and a managed IAM is not a NIS2 certificate. It covers access control and MFA technically and provides the audit basis, but it does not replace your compliance program of registration, reporting, and management duties. Anyone who already has their own ops with the necessary update discipline does not need a managed service for this. The trial runs for seven days and requires a credit card.

→ View plans and pricing | → Start a 7-day trial

Conclusion

Six months after the NIS2UmsuCG entered into force, the implementation gap is large: by the deadline on March 6, 2026, only around 38.5 percent of the roughly 29,500 affected companies had completed their BSI registration, according to BDO. Among the ten minimum measures from Section 30(2) BSIG, access control (no. 9) and multi-factor authentication (no. 10) are the two identity topics that a cleanly configured Authentik can map technically, complemented by audit trails that feed into GDPR Art. 32.

What is decisive is the honest delimitation: an IAM is a solid, clearly delimited building block, not a complete NIS2 program. Backup, supply chain, training, the reporting under Section 32, and management duties remain separate tasks. Anyone who wants to implement the two identity measures cleanly without their own licensing and operational effort gets them as Managed Authentik on German infrastructure, with a DPA and EU-sovereign data residency.

Start Managed Authentik now →

Sources

1. BDO: Six months of the NIS-2 implementation act, NIS-2 in Germany (half-year review, registration rate 38.5%): bdo.de
2. OpenKRITIS: NIS2 implementation act in Germany (sectors, categories, Sections 28/30/32/65, fines): openkritis.de
3. Section 30 BSIG (2025): risk-management measures, no. 1 to 10: gesetze-im-internet.de
4. Article 21 NIS2 Directive (EU) 2022/2555, risk-management measures points (a) to (j): buzer.de
5. NIS2 Directive (EU) 2022/2555, EUR-Lex CELEX:32022L2555 (original text): eur-lex.europa.eu
6. Article 32 GDPR, security of processing (technical and organizational measures): dsgvo-gesetz.de
7. BSI: NIS-2 info package on multi-factor authentication and continuous authentication: bsi.bund.de
8. Authentik: Authenticator Validation stage (MFA methods, device classes, throttling): docs.goauthentik.io
9. Authentik: About access control / RBAC (roles, permissions, groups): docs.goauthentik.io
10. Authentik: Events / audit logging (recorded fields, 365-day retention, forwarding): docs.goauthentik.io
11. Authentik Release Notes 2026.5 (throttling email/SMS OTP, Account Lockdown, conditional access): docs.goauthentik.io
12. Authentik Blog: Version 2026.5 is here (release date May 22, 2026): goauthentik.io
13. Authentik Blog: Version 2025.12 (RBAC, permissions exclusively via roles): goauthentik.io