NIS2 starts with a question: who has access to what?

As Inero Software, we have spent years delivering IAM solutions to enterprise clients and smaller companies. We design and implement directory integrations, SSO, multi-factor authentication, roles and mechanisms for managing administrator accounts. Experience has shown us that enabling a sign-in mechanism is rarely the hardest part of an IAM implementation. The greater challenge is bringing order to ownership, exceptions and access rights that have accumulated across systems over many years.

This is particularly important for organisations that may fall within the scope of NIS2. On one side, they see regulations, guidance and new deadlines. On the other, they see their existing architecture: multiple user directories, local accounts, SaaS applications, legacy systems, supplier access and dependencies that are not always documented. Between those two views, it is easy to miss the technical details that determine whether an access control really works.

In practice, NIS2 requirements therefore lead quickly to specific questions about users, administrators, authentication, account lifecycle and logs. The answers can – and should – be verified not only in policies, but also in the configuration of real systems.

Consider an organisation that states it has Active Directory, SSO, MFA, a VPN, a security policy and centralised logging. On an architecture slide, the environment looks mature. A technical review, however, raises simpler questions: who can actually access production, who approved that access, whether administrators use separate accounts, whether former employees can still sign in, and where authentication logs are sent.

This is where regulatory requirements meet real infrastructure. NIS2 does not require a particular IAM product, nor does it say that an organisation should use Keycloak. It does require appropriate technical, operational and organisational risk-management measures. Article 21 of the Directive includes access control, asset management, human resources security and, where appropriate, multi-factor or continuous authentication. The primary legal source is Directive (EU) 2022/2555.

NIS2 is not only a documentation exercise

Much of the NIS2 discussion focuses on entity classification, incident reporting and documentation. These subjects matter, but an access-control policy alone will not tell you whether a former administrator’s account still works on a firewall.

Polish context and legal status as at 22 September 2026. This article focuses primarily on organisations operating in Poland. Poland’s amendment to the Act on the National Cybersecurity System, implementing NIS2, entered into force on 3 April 2026. Entities that met the statutory criteria on that date generally have until 3 October 2026 to apply for entry in the KSC register and until 3 April 2027 to implement the new obligations. The current timetable is published by the Polish Ministry of Digital Affairs. The exact duties depend on the entity’s status and sector. This article presents a technical IAM perspective, not legal advice or a complete compliance map.

Moving from the law to implementation means building an information security management system, selecting controls based on risk, assigning ownership and retaining evidence that the controls work. IAM is one of the areas where those tasks quickly become concrete.

A simple question: who has access to what?

Mature access management should make it possible to answer eight questions:

1. Who has an account?
2. In which systems can that account be used?
3. Which roles and permissions are assigned to it?
4. Who granted the access, and on what basis?
5. Why does the user still need it?
6. When were the permissions last reviewed?
7. How is the account authenticated?
8. Are sign-ins and administrative changes recorded?

The answers are often distributed among HR, Active Directory or Entra ID, application configuration, source-code platforms, VPN systems, databases and the knowledge of individual administrators. A list of users in one identity provider is not necessarily a list of all access.

For management, the issue is not merely technology selection. Process owners must also be named. Who approves a role? Who owns a service account? Who initiates deprovisioning? Who reviews exceptions? Without these decisions, even a well-configured IAM platform will reproduce organisational ambiguity.

Identity sprawl: one person, several identities

Enterprise environments usually grow organically. Some applications use the corporate directory, newer systems connect to Keycloak, operational tools retain local accounts, and SaaS platforms have their own users and roles. An external supplier may receive another identity for VPN access.

The essential question is: which system is the source of truth for who should have access?

Central SSO reduces the number of sign-in paths, but it does not by itself solve the account lifecycle. Federation with LDAP or Active Directory can centralise authentication, but the source of roles and groups still needs to be defined. SCIM, a standard for exchanging user and group information, can support automated provisioning and deprovisioning in SaaS services. Systems without such integration need a controlled procedure for local accounts, ownership and expiry.

The objective is not always one directory for everything. It is a consistent accountability model, as few exceptions as practical and the ability to establish quickly the complete access of a person or service.

For organisations at the start of this process, our guide explains how to prepare for implementing an IAM system.

MFA does not close the authentication topic

MFA reduces account-takeover risk only in the flows where it is actually enforced. A review should also establish:

• whether MFA covers administrators, VPN access and other remote access;
• whether a local sign-in path bypasses the central identity provider;
• whether password reset or account recovery relies on weaker verification;
• whether active sessions and tokens are revoked after a password or privilege change;
• whether session, access-token and refresh-token lifetimes match the application’s risk;
• whether emergency access is controlled, tested and logged.

Secure sign-in does not automatically mean secure account management. If the service desk can remove a second factor following a brief phone call, recovery becomes an alternative attack path. Similarly, a multi-day administrative session can reduce the benefit of strong authentication performed only at the start.

The configuration of a second factor is covered in more detail in our step-by-step guide to MFA in Keycloak.

Privileged accounts need a separate model

Accounts used to administer IAM, infrastructure, databases and CI/CD have a different risk profile from ordinary office accounts. The same applies to root accounts, service accounts, machine integrations and supplier access.

In practice, we encounter environments where the same identity is used for email and administration, service accounts have no named owner, and supplier access remains active after work has ended. Shared accounts also make it impossible to attribute an operation reliably to an individual.

Good practice includes separating administrative identities from daily work, individualising accounts, enforcing strong authentication, limiting roles to the required scope and using time-bound access where possible. Privileged access should be reviewed more frequently, and administrative operations should leave a useful audit trail.

For specified categories of entities, the detailed technical requirements are set out in Commission Implementing Regulation (EU) 2024/2690. They cover, among other matters, dedicated administration accounts, strong authentication, planned reviews of privileged access and documented review results. The Regulation does not automatically apply to every NIS2 entity, but it is a valuable design reference.

Joiner, Mover, Leaver: an account has a lifecycle

Onboarding is usually the most structured part of the process. More problems arise when an employee changes position, temporarily supports another team, completes a project or leaves the organisation.

The Joiner–Mover–Leaver model covers three stages:

• Joiner: create the identity and grant the minimum set of roles based on an approved request;
• Mover: remove old permissions, grant new ones and check for accumulated roles after a position change;
• Leaver: disable the account, terminate sessions, revoke tokens and keys, remove local access and record completion.

The process should cover employees, contractors, suppliers and machine identities. Automation reduces omissions, but it needs an authoritative source of data and clearly defined exceptions. Temporary access without an expiry date and technical accounts without a business owner are particularly risky.

NIS2 and IAM: from requirement to mechanism

The table below is not a complete compliance map. It illustrates how risk-management areas translate into operational questions and IAM mechanisms.

ENISA’s NIS2 Technical Implementation Guidance distinguishes requirements, implementation guidance and examples of evidence. It addresses entities covered by Regulation 2024/2690, but its structure is useful more broadly: configuration, process and proof of operation should be designed together.

Keycloak as part of an architecture supporting NIS2

Keycloak can serve as a central IAM layer. It supports SSO, OpenID Connect, OAuth 2.0 and SAML, LDAP/Active Directory federation, roles and groups, configurable authentication flows, TOTP, WebAuthn and passkeys, session management and event logging. The current feature set is described in the Keycloak Server Administration Guide.

This does not make Keycloak “NIS2-compliant”, and installing it does not make an organisation compliant. It can be one technical element in an architecture supporting the implementation of NIS2 requirements. The outcome depends on configuration, integrations, patching, availability, monitoring and organisational procedures.

We previously examined the broader points of contact between the platform and the regulation in our article on Keycloak integration challenges in the context of NIS2.

Nor does Keycloak automatically become a complete Identity Governance and Administration platform. Organisations requiring advanced access-certification campaigns, segregation-of-duties analysis or comprehensive provisioning across many SaaS systems may need additional tooling and processes. Standard LDAP/AD federation should not be confused with SCIM.

What would we review in an existing Keycloak deployment?

A practical review can be divided into four groups.

Maintenance and administrative surface

1. Keycloak version: is it supported, and do known vulnerabilities affect the deployment?
2. Updates and security fixes: who monitors releases, tests upgrades and sets remediation times?
3. Admin Console: from which networks is it reachable, and how is it protected?
4. Administrators: how many accounts exist, which roles do they have and do they use separate administrative identities?

These points indicate whether the central authentication component has itself become an uncontrolled privileged asset.

Authentication and account recovery

5. MFA: for whom is it mandatory, how is step-up authentication used, and which exceptions exist?
6. Password policy: does it match the identity source and the actual sign-in paths?
7. Reset credentials and recovery: who can initiate the flow, how is the person verified, and is the event logged?
8. WebAuthn and passkeys: can they replace weaker methods for higher-risk groups?

MFA must be assessed as an end-to-end flow, including factor enrolment, account recovery and lost-device handling.

Clients, tokens and sessions

9. OIDC clients: do the client type and permitted grants fit the application architecture?
10. Redirect URIs: are they precise and free from unnecessarily broad wildcards?
11. PKCE: do public clients use Proof Key for Code Exchange to protect the authorisation code?
12. Sessions: are idle and maximum limits proportionate to the risk?
13. Access-token lifetime: does a short lifetime limit the effect of token leakage without destabilising the application?
14. Refresh-token lifetime and rotation: for how long can access be renewed, and how does revocation work?

There is no single safe timeout for every application. An administrative console, an employee application and a public portal require different decisions.

Machine identities, events and federation

15. Service accounts: does each account have an owner, minimum roles and a controlled secret or key?
16. User events: are successful and failed sign-ins, credential resets and sign-outs recorded?
17. Admin events: are changes to clients, roles, groups and authentication flows recorded?
18. SIEM integration: are events sent to a central system with sufficient context and an agreed retention period?
19. LDAP/AD: what are the synchronisation mode, failure behaviour and handling of deleted or disabled users?
20. Roles and groups: who owns the model, how often is it reviewed and how are changes documented?

This checklist is not a pass/fail compliance test. Its purpose is to expose decisions, exceptions and dependencies that should follow from risk assessment.

The practical aspects of centralising and analysing these events are explored further in our article on integrating Keycloak with SIEM systems.

Auditability: show that the control works

In cybersecurity, stating that a control exists is increasingly insufficient. The organisation should be able to demonstrate that it is used. IAM evidence may include:

• an approved access-control policy;
• a current list of privileged accounts and their owners;
• MFA configuration and a list of exceptions;
• a history of role grants and removals;
• successful and failed sign-in logs;
• Keycloak admin events;
• a periodic access-review report;
• a completed case showing access removal after an employee’s departure;
• a record of an account-compromise exercise, including session revocation.

Evidence should be reproducible, have an owner and follow an agreed retention period. A log that nobody analyses is not yet monitoring. A report generated once before an audit is not a substitute for an operating access-review process.

10 questions to ask before an IAM audit

1. How many systems still maintain local accounts?
2. How many users have administrative privileges?
3. Do all administrators use MFA and separate accounts?
4. Are there shared accounts, and if so, why?
5. Can we identify accounts belonging to former employees and suppliers?
6. How long do sessions and refresh tokens remain active?
7. Do we log and review administrative changes?
8. Are authentication logs sent to a central system?
9. How often do business owners confirm that access is still needed?
10. Can revocation of one person’s access be initiated centrally and verified?

NIS2 is not reducible to implementing IAM, MFA or Keycloak. Identity management is, however, one of the areas where regulatory requirements quickly meet the reality of IT architecture.

A useful first question is therefore not “do we have an IAM system?” but a simpler one: can we say who has access to our systems today, why they have it and whether they still need it?

At Inero, we design, review and integrate IAM systems, with a particular focus on solutions based on Keycloak.