NIS2 Article 21 requires identity and access controls. We assess your Linux estate.
Years of sudo rules, SSH keys and service accounts have built paths to root across the Linux systems behind your essential or important services, and nothing in the standard stack maps them. Automation and AI agents now find and use those paths faster than any review. Article 21 asks for demonstrable control over exactly that access; our pilot maps every path and delivers the evidence before your next supervisory review.
Why NIS2 Makes Linux Identity Visible
- Privilege drift through undocumented sudo rules accumulates silently over time, leaving organizations unable to demonstrate the continuous control required by NIS2 Article 21(2)(a) risk analysis obligations.
- Orphaned accounts from former employees with active sudo configurations represent a direct compliance gap under NIS2 access management requirements, creating liability for both the organization and board members personally.
- Automation and AI agents authenticate as service accounts on those systems and inherit whatever reach the accounts have built up, so an unmapped path to root is used faster than any review cycle. Demonstrating control under Article 21 means knowing what each of those accounts can do on each host, continuously.
- NIS2 Article 21(2)(i) explicitly mandates identity and access management controls as a required cybersecurity measure for essential and important entities — Linux servers are the primary surface where these controls fail.
- NIS2 Article 20 introduces personal liability for board members who fail to implement adequate cybersecurity measures — unmanaged Linux privilege is a documented, reportable control failure.
- NIS2 (Directive (EU) 2022/2555) had to be transposed into national law by 17 October 2024; national implementing laws have taken effect on staggered dates since, and enforcement is now live across most member states. Member-state supervisory authorities are actively conducting compliance assessments, making immediate evidence of control effectiveness essential.
How the Founding Pilot Addresses NIS2 Article 21 Requirements
Every pilot finding is mapped to specific NIS2 Article 21 controls, so the evidence supports your NIS2 supervisory reporting.
| Article / Requirement | What It Mandates | How the Founding Pilot Covers It |
|---|---|---|
| Article 21(2)(i) | Identity and access management | Full inventory of users, groups, sudo rules, SSH keys, PAM configuration, and service accounts with privilege path mapping |
| Article 21(2)(a) | Risk analysis and information system security policies | Risk-scored findings mapped to exploit patterns, prioritised by likelihood and impact on essential services |
| Article 21(2)(d) | Supply chain security | Third-party and service account privilege assessment identifying vendor accounts with excessive access |
| Article 21(2)(j) | Multi-factor authentication and continuous access solutions | Assessment of authentication controls on privileged accounts including sudo and SSH key management gaps |
The two documents that define NIS2 evidence in practice
Article 21 says what must be managed. Two further documents say what the evidence looks like, and neither is about servers.
Commission Implementing Regulation (EU) 2024/2690
Adopted 17 October 2024 and in force since 7 November 2024, it lays down the technical and methodological requirements behind Article 21(2) for DNS, TLD, cloud, data-centre, CDN, managed service and managed security service providers, online marketplaces, search engines, social networks and trust service providers. Its Annex runs to thirteen sections; section 11 is access control, with 11.3 on privileged accounts and system administration accounts, and section 12 is asset management.
Read the sourceENISA Technical Implementation Guidance, version 1.0
Published 26 June 2025, it follows the Annex requirement by requirement and adds guidance, examples of evidence and mappings to standards. It is non-binding, and it is the most detailed EU-level description of what evidence a supervisor may expect to see.
Read the sourceNIS2 compliance is a property of an organisation, not of a server. No Linux host is “NIS2 compliant”; the entity demonstrates the measures across its systems. Linux hardening and Linux identity evidence are the layer beneath that demonstration: the access rights, privileged accounts and logs the Annex asks about are produced on the hosts, and that is where the pilot’s evidence sits.
Where the pilot’s evidence lands in the Annex
| Section | Requirement | What the pilot hands over |
|---|---|---|
| 11.2 | Management of access rights | Every account and group membership on each host, with the sudo rules and SSH keys attached; dormant and orphaned accounts flagged. |
| 11.3 | Privileged accounts and system administration accounts | Which identities can reach root on which host, ranked by risk; NOPASSWD and standing sudo grants surfaced. |
| 11.5 and 11.6 | Identification and authentication | Shared accounts and keys reused across hosts flagged; SSH keys graded for algorithm strength, reuse and whether they still belong to anyone. |
| 12.4 and 12.5 | Asset inventory; return or deletion of assets on termination of employment | The identity inventory per host, continuously updated; a leaver’s residual access — local accounts, keys, sudo — surfaced and removable behind an approval. |
| 3.2 | Monitoring and logging | Sudo, SSH and PAM changes detected in near-real-time and attributed to the identity that made them, recorded in a chain-hashed audit log. |
| 6.3 and 6.4 | Configuration management; change management | Sudoers, SSH and PAM configuration tracked against an approved baseline, so an undocumented change is a finding the same day. |
Where LinuxGuard sits among the Linux compliance tools you already run
Most estates in scope already run one or more of these for hardening and logging. Each closes part of the picture; none of them answers who can reach root on which host, or keeps that answer current. Read them as complements, which is how we deploy alongside them.
Open-source options
Lynis
A host-based security audit for Linux and Unix systems. It runs on the host itself, tests hundreds of hardening controls drawn from CIS, NIST and NSA guidance, and reports a hardening index with warnings and suggestions.
- Closes
- A point-in-time hardening audit of an individual host.
- Leaves open
- It does not inventory accounts, sudo rules or SSH keys across an estate, does not attribute a change to an identity, and does not watch between runs.
OpenSCAP with Ansible
SCAP content from the SCAP Security Guide, with CIS, DISA STIG and PCI DSS profiles. It evaluates a host’s configuration against a profile, produces HTML and ARF reports, and ships remediation content, including Ansible, to bring the host back to the baseline.
- Closes
- Configuration-baseline conformance and remediation at scale.
- Leaves open
- Who holds privilege on the host is not a benchmark rule: sudoers topology, SSH key ownership and service accounts sit outside the profile, and each scan describes one moment.
auditd
The userspace component of the Linux Auditing System. It writes audit records to disk according to the rules loaded from audit.rules, which is the event record that monitoring and logging requirements draw on.
- Closes
- A record of what happened on the host — logins, privileged commands, file access — as configured.
- Leaves open
- It records events; it does not assess configuration, inventory accounts or rank privilege. Rulesets drift between hosts, and the logs still need central collection and interpretation.
Ubuntu Pro (Ubuntu Security Guide)
Canonical’s subscription tooling for Ubuntu LTS. The Ubuntu Security Guide hardens a host to CIS or DISA-STIG profiles and generates audit reports; CIS profiles cover 20.04, 22.04 and 24.04 LTS, DISA-STIG 20.04 and 22.04.
- Closes
- Benchmark hardening and audit reporting on Ubuntu hosts.
- Leaves open
- Ubuntu only, by design. It reports benchmark conformance, not who can reach root or which keys and service accounts hold privilege, and it does not attribute change to an identity.
Commercial platforms
LinuxGuard
A Linux-native identity control plane. A continuous inventory of every account, group, sudo rule, SSH key and service account across the distributions you run, risk-scored, with sudo, SSH and PAM changes detected in near-real-time and attributed to the identity behind them, response actions behind an approval gate, and evidence exported per framework.
- Closes
- The access-rights, privileged-account and inventory evidence that the access-control and asset-management requirements ask for — continuously, rather than per scan.
- Leaves open
- It does not harden the operating system to a benchmark and does not replace auditd’s event record. It runs alongside both.
Ubuntu Pro is listed with the open-source tools because the Ubuntu Security Guide is the hardening route most Ubuntu estates already have; it is a Canonical subscription. LinuxGuard is Validated with Ubuntu under Canonical’s Software Partner Programme and is certified with Red Hat and SUSE.
What You Get
- Identity & Privilege Inventory — Every user, group, sudo rule, SSH key, and service account across your Linux estate, showing who can do what
- Risk-Scored Findings Report — Prioritised findings based on real exploit patterns, highlighting the privilege paths attackers would use first
- Compliance Evidence Package — Identity governance gaps mapped to NIS2 Article 21 controls with remediation guidance
- Prioritised Remediation Plan — Phased plan to reduce privilege drift and move toward least-privilege, with a zero trust alignment overlay where applicable
- Board-Ready Executive Summary — Executive summary for boards and a technical deep-dive for your security team
How the Founding Pilot Works
The Founding Pilot runs in four phases over 60 days — discovery and scoping, identity and privilege mapping with lightweight read-only collectors, a security and compliance assessment that maps findings to NIS2 Article 21 controls, and reporting with a prioritised least-privilege remediation roadmap. See the Founding Pilot for the full four-phase process, timeline, and deliverables.
Frequently Asked Questions
Does NIS2 apply to our Linux servers specifically?
What does Article 21 require for identity and access management?
How does LinuxGuard produce NIS2 compliance evidence?
What are the non-compliance penalties under NIS2?
How long does the NIS2 pilot take?
Related solutions
Financial entities must identify and document their ICT assets and access under DORA Article 8 — LinuxGuard assesses your Linux infrastructure.
Learn about the DORA Pilot
Zero-trust access controls and compliance posture for Linux infrastructure.
View Security & Compliance
Further reading: Linux access control evidence under NIS2, and how it compares with the equivalent UK framework.