NIS2 Access Control Requirements: What Organisations Must Implement

Article 21(2)(j) — The Explicit MFA Requirement

Article 21(2)(j) of NIS2 requires covered entities to use "multi-factor authentication or continuous authentication solutions, secure voice, video and text communications, and secured emergency communication systems within the entity, where appropriate."

The phrase "where appropriate" in this article applies to the communications systems listed — secure voice, video, text, and emergency communications — not to MFA itself. MFA is stated as an unqualified requirement for covered entities. Supervisors in early-transposing member states have been consistent on this point: MFA is not optional, and deploying it selectively without a documented justification leaves an organisation exposed.

What "appropriate" means in the broader Article 21 context is proportionality to risk. NIS2 does not mandate a specific technology or authentication method. It requires that the authentication controls deployed reflect the assessed risk associated with the access being protected. For remote access, administrative access, and access to critical or sensitive systems, MFA is the minimum. For lower-risk access, a risk-based argument for lesser controls may hold — but that argument must be documented, assessed, and maintained.

Continuous authentication — where user identity is verified throughout a session rather than only at login — is presented in Article 21(2)(j) as an alternative to MFA rather than an additional requirement. In practice, few organisations are deploying continuous authentication at scale; the operative requirement for most is MFA, deployed comprehensively and verifiably.

Least Privilege Under NIS2 — What Supervisors Consider Adequate

The principle of least privilege is embedded in Article 21(2)(i), which requires access control policies as part of a grouped obligation covering human resources security and asset management. ENISA's technical guidelines and the implementing acts being developed under Article 21(5) both reference least privilege as an expected component of adequate access control.

In practice, supervisors assessing NIS2 compliance on access controls look for three things. First, whether access rights are scoped to what is needed for the specific role — not to what was convenient to grant or inherited from a previous role. Second, whether access rights are reviewed at defined intervals and whether those reviews result in changes when circumstances change. Third, whether the organisation can evidence that the process is working — not just that the process exists.

The most common failure pattern is the accumulation of access rights over time. An employee who has moved between roles, acquired project access, or been added to distribution groups carries rights from each previous context. Those rights rarely get removed proactively. Under NIS2, an access control policy that does not address this accumulation problem — through regular recertification or role-based provisioning — does not meet the standard, even if the policy document describes least privilege in the right terms.

The connection between access control and asset management in Article 21(2)(i) is deliberate. Supervisors expect access rights to be linked to an asset inventory: access to what system, what data, what environment. An access review process that cannot connect rights to specific assets is of limited value for demonstrating compliance.

Service Accounts and Non-Human Identities — the Overlooked Obligation

Service accounts, application identities, automation credentials, and API keys are non-human identities that carry access rights and are subject to the same NIS2 access control obligations as human accounts. They are also the most frequently overlooked category in NIS2 implementation programmes.

The problem with non-human identities is that they are typically created for a specific purpose and then forgotten. A service account created to run a scheduled task may accumulate domain admin rights to handle an edge case. An API key issued for a one-off integration may still be valid two years later. An application identity may have access to production data that was never decommissioned after the application was retired.

Under NIS2's access control and asset management requirements, these are not exceptions — they are in scope. An asset inventory that does not include service accounts and non-human identities is incomplete. An access control policy that addresses only human users does not meet the standard. An access review process that does not include non-human identities will leave a population of high-risk, unmonitored access rights outside the compliance boundary.

Supervisors and auditors are aware of this gap. In post-incident examinations, compromised service accounts are a recurring finding — often with rights that would not have been granted had anyone assessed them in the previous twelve months. Organisations that can demonstrate active management of non-human identities — inventory, periodic review, decommissioning — are in a materially better position than those that cannot.

Third-Party Access Controls — the Supply Chain Requirement

Article 21(2)(d) requires covered entities to address security in the supply chain, including security aspects of the relationships between each entity and its direct suppliers or service providers. For identity and access management, this translates into specific obligations around how third parties are granted access to covered systems.

The most common control failures in third-party access are: shared credentials used by multiple supplier staff with no individual attribution; standing access that remains active outside maintenance windows or contract periods; absence of MFA on remote access granted to suppliers; and no process for reviewing or revoking access when a supplier contract changes or ends.

NIS2 does not prescribe specific technical controls for third-party access, but it requires that the risks be assessed and mitigated. Supervisors assessing supply chain security expect to see: a process for provisioning and deprovisioning third-party access; MFA required for supplier remote access as standard; individual attribution (no shared accounts); and evidence that third-party access is reviewed at defined intervals, not only when something goes wrong.

Supplier security questionnaires alone do not satisfy this requirement. The obligation is on the covered entity to manage the access risk, not to obtain a self-attestation from the supplier. Where a supplier holds privileged access to covered systems, the covered entity must be able to demonstrate active oversight of that access.

What a NIS2 Compliance Assessment for Access Controls Looks Like

A structured NIS2 compliance assessment of access controls should cover policy, technical implementation, and evidence — in that order, because gaps at any layer invalidate the others.

Policy review

The assessor will examine whether a documented access control policy exists, whether it addresses the categories required under Article 21(2)(i) — all user types, including privileged accounts, service accounts, and third parties — and whether it has been approved by the management body consistent with the Article 20 obligation. A policy that exists but has not been approved or reviewed in the last twelve months creates an immediate gap.

Technical implementation

The assessor will test whether MFA is deployed and enforced on remote access, administrative access, and access to systems in scope. Testing goes beyond reviewing configuration — it includes attempting access without MFA where possible, checking whether bypass paths exist, and reviewing whether all user populations are subject to the same controls or whether exemptions have been granted without documentation.

Privileged account inventory is tested by cross-referencing Active Directory, privileged access management tooling, and service account registers against systems in scope. The objective is to identify accounts with elevated rights that are not captured in the organisation's own inventory — these are a consistent finding.

Evidence and documentation

The evidence standard for NIS2 is that the organisation can demonstrate controls are operating effectively, not just that they exist. This means access review records, joiner/mover/leaver process logs, MFA enrolment data, and privileged account review sign-offs must be available and current. An organisation with good controls but poor evidence is in a weaker supervisory position than it should be. Documentation is not a bureaucratic overhead — it is what turns a control into a demonstrable compliance position.