IAM & NIS2: What Do Companies Really Need to Do?

Many security incidents do not begin with highly complex zero-day exploits, but with identities: compromised user accounts, overly broad permissions, lack of multi-factor authentication, uncontrolled service accounts, or inadequate offboarding processes. NIS2 requires appropriate and proportionate technical, operational, and organizational measures. These include, among other things, risk analyses, incident handling, business continuity, supply chain security, security measures during the acquisition, development, and maintenance of systems, as well as procedures for evaluating the effectiveness of cybersecurity measures. A robust IAM supports nearly every one of these points because it makes access to systems, data, admin rights, and sensitive processes controllable.

Companies should therefore stop viewing IAM merely as a directory service or user management tool. Under NIS2, IAM is a control system for digital trust relationships. It determines who is allowed to access what, under what conditions, with what level of traceability, and how quickly risky access can be revoked. Those who neglect this area create vulnerabilities precisely where NIS2 demands robust control.

The most common misconception: NIS2 is not merely a documentation project

Many organizations start with policies, Excel lists, and a gap analysis. This is necessary but not sufficient. NIS2 does not require mere paper compliance, but demonstrable effectiveness. Management bodies must approve cybersecurity measures, monitor their implementation, and can be held accountable for breaches of duty. This shifts the discussion from “Do we have a policy?” to “Does our security model actually work in everyday practice?”

For IAM, this means specifically: A company is not well-positioned simply because an authorization concept exists somewhere. What matters is whether privileged access is truly limited, whether Joiner-Mover-Leaver processes run smoothly, whether orphaned accounts are detected, whether admin sessions are monitored, and whether permissions are regularly recertified. NIS2 increases the pressure to make these points operational and verifiable.

What companies really need to do

1. Clearly determine scope and criticality

The starting point is not the technology, but classification. Companies must verify whether they fall under NIS2 as an essential or important facility. The directive significantly expands the scope of application and, in addition to traditional KRITIS sectors, also covers digital infrastructures, providers of public electronic communication services, data center services, postal and courier services, waste management, certain manufacturers of critical products, public administration, and other sectors. Those who misjudge their own exposure miss the mark when it comes to risk.

For IAM practice, this means: First, it must be clear which systems, applications, identities, and administrative domains fall within the scope. Without a scope definition, any access control remains piecemeal.

2. Inventory identities – comprehensively, not selectively

The second step is sobering but essential: Companies need transparency regarding all identities. This includes not only employee accounts, but also external service providers, partner accesses, machine identities, service accounts, API keys, local administrator accounts, and privileged technical users. It is precisely these technical identities that elude governance in many environments and therefore pose an above-average risk.

Anyone who takes NIS2 seriously must establish a robust identity inventory. This includes assigning owners, classifying identities by criticality, documenting permission scopes, and determining whether the identity is actually still needed. Without this foundation, neither least privilege nor recertifications nor forensic traceability can be meaningfully implemented.

3. Establish strong authentication as a minimum standard

NIS2 explicitly names multi-factor authentication and secure communication channels as appropriate measures. MFA is thus no longer an optional “best practice,” but is effectively the standard in many affected environments. This is particularly relevant for privileged accounts, remote access, cloud administration, VPN access, administration portals, and critical business applications.

Companies should therefore prioritize MFA on a risk-based basis. First, all administrative and externally accessible access points must be secured. This is followed by sensitive internal systems, identity providers, email access, and central business applications. It is important not only to enable MFA technically but also to strictly control exceptions and review them regularly. A single unprotected legacy access point can undermine the entire model.

4. Radically Reorganize Privileged Rights

Under NIS2, Privileged Access Management is not a luxury project, but the core of risk reduction. Admin rights, domain accounts, emergency access, root accounts, and highly privileged cloud roles must be treated separately. In many companies, these rights were historically granted, rarely documented, and hardly ever recertified. It is precisely this structure that is difficult to reconcile with NIS2.

Therefore, separate admin identities, consistent assignment based on the need-to-know and least-privilege principles, time-limited rights, approval processes for escalations, password or secret vaulting for technical accounts, and tamper-proof logging of privileged activities are necessary. Those who do not have privileged access under proper control will fail to pass audits or incident response effectively.

5. Automate the authorization lifecycle

NIS2 requires organizational and technical measures that remain effective in operation. This is precisely where manual authorization processes fail. If user permissions are not updated promptly upon onboarding, role changes, or departure, over-privileging and shadow access arise. This particularly affects large, heterogeneous, and globally distributed organizations.

Therefore, Joiner-Mover-Leaver processes should be technically supported or automated wherever possible. New employees receive only role-based initial permissions. Role changes lead to a reassessment, not to accumulated permissions. During offboarding, accounts, tokens, certificates, VPN access, and administrative rights are immediately revoked. This process discipline is not merely an HR interface, but a security-critical obligation.

6. Make recertifications and segregation of duties mandatory

Many companies do not know which departments actually grant which rights. They know even less about which critical combinations of permissions exist. Under NIS2, this lack of transparency is no longer acceptable. Companies must be able to demonstrate in a transparent manner that permissions are justified by business needs, regularly reviewed, and corrected as necessary.

Regular access reviews are therefore mandatory. Recertifications are particularly important for privileged accounts, highly sensitive business applications, and external access. In addition, companies should identify conflicts in terms of segregation of duties, such as when the same person can create, approve, and post orders, or simultaneously holds operational and supervisory rights. Such authorization conflicts are not only compliance risks but also real vectors for abuse and manipulation.

7. Integrate IAM with Monitoring and Incident Response

NIS2 contains specific requirements for reporting significant security incidents. Companies must establish early warning mechanisms, reporting channels, and response processes both organizationally and technically. In Germany, the BSI now provides a portal for this purpose; significant incidents must be reported there.

For IAM, this means: Identity-related events must be incorporated into security monitoring. These include suspicious login attempts, implausible travel profiles, unusual use of privileged accounts, mass changes to permissions, deactivation of MFA, suspicious token usage, or newly created shadow administrators. IAM must therefore not be operated in isolation but must be closely integrated with SIEM, SOC, incident response, and forensics.

What you need to understand now

NIS2 makes cybersecurity a management responsibility. This is not just rhetoric but an explicit governance requirement. Management bodies must approve measures, monitor their implementation, and complete training. For company leadership, this means: IAM deficiencies are not just technical debt, but governance risks.

That is why senior management should be able to answer three questions immediately: First, which identities have access to our critical processes? Second, how do we actually control privileged rights? Third, how quickly can we revoke risky access or detect abuse? Anyone who cannot answer these questions with confidence does not have a mature NIS2 program.

Conclusion: NIS2 does not require perfection, but it does require robust controls

Companies do not have to solve every IAM problem at once for NIS2. However, they must quickly transition from ad-hoc measures to a controlled, risk-based, and auditable access model. Key factors include clear responsibilities, full transparency regarding identities, strong authentication, consistent management of privileged rights, automated lifecycle processes, regular recertifications, and integration with monitoring and incident response.

IAM is thus not merely a support process for NIS2. It is one of the most effective levers for translating the directive’s requirements into operational reality, both technically and organizationally. Companies that merely formulate policies now will fail later under real-world conditions. Companies that systematically control identities, rights, and access, on the other hand, achieve precisely what NIS2 demands at its core: resilience.