The audit email lands on a Tuesday morning. Your auditor wants evidence of privileged access controls across your Linux estate — who had root, when, what changed, and how you know. You open your SIEM dashboard. You check your IGA platform. Neither has what you need. This is the Linux compliance gap, and it is costing security teams across finance, utilities, and manufacturing weeks of frantic manual work every audit cycle.
This guide exists because three major EU regulatory regimes now converge on the same operational obligation: prove that privileged access on your Linux infrastructure is controlled, monitored, and evidenced. NIS2 is now fully enforced across 160,000+ EU organisations. DORA has been in active application since 17 January 2025. The EU AI Act's high-risk obligations — now delayed to 2 December 2027 following the Digital Omnibus provisional agreement of 7 May 2026 — are approaching fast, and the infrastructure work cannot wait. Auditors across all three regimes are asking for Linux access control evidence. Most organisations have no automated way to produce it.
Why Linux Is the Compliance Blind Spot
The Gap Between What Auditors Want and What Your Tools Actually Surface
Enterprise security stacks are largely built around identity platforms, SIEM tools, and IGA solutions. These tools are excellent at governing Active Directory identities, aggregating Windows event logs, and managing cloud entitlements. On Linux, they leave a significant visibility gap.
The problem is structural. Linux identity lives in /etc/passwd, /etc/sudoers, PAM configuration files, SSH authorized_keys files, and cron jobs — none of which are natively ingested by SIEM or IGA platforms without extensive custom integration work. When an auditor asks for a list of every account with sudo-to-root access across your server estate, your SIEM cannot answer that question. It aggregates log events after the fact; it does not inventory what privileges exist at this moment.
IGA platforms face the same limitation. IGA governs what it has been connected to — everything outside that perimeter drifts. Orphaned accounts accumulate. Sudo rules expand and are never reviewed. SSH keys are shared across teams, and no one tracks which key maps to which person. When an auditor requests a comprehensive list of privileged access across the organisation, the absence of that inventory is itself a compliance finding.
The practical consequence: security teams facing NIS2, DORA, PCI DSS, SOX, or AI Act audits must manually SSH into servers, parse text files, and reconcile spreadsheets — a process that takes weeks and produces evidence that was already stale by the time it was gathered. A single unified evidence architecture that continuously captures access state across the Linux estate is no longer a nice-to-have. Under the convergence of these three major regimes, it is now table stakes.
What NIS2 Article 21 Specifically Requires from Linux Access Controls
The Ten Mandatory Cybersecurity Measures
NIS2 Directive (EU) 2022/2555 Article 21 is the operational core of the directive. It mandates that all covered essential and important entities implement "appropriate and proportionate technical, operational and organisational measures" to manage cybersecurity risk. Ten specific requirement areas are defined under Article 21(2).
The provisions that bite hardest for Linux access controls are:
- Article 21(2)(a): Risk analysis and security policies — organisations must document and maintain policies covering all ICT assets, including Linux servers
- Article 21(2)(e): Security in network and information systems acquisition, development and maintenance — covering configuration management and change control
- Article 21(2)(g): Basic cyber hygiene practices and cybersecurity training — for Linux, this means enforcing least privilege, removing unused accounts, and managing sudo rules
- Article 21(2)(i): Human resources security, access control policies and asset management — the most directly relevant clause; it requires organisations to maintain a clear inventory of all critical assets, restrict access to authorised users only, and implement identity lifecycle controls
- Article 21(2)(j): Multi-factor authentication and secured communications — MFA is now mandatory where feasible, with alternative authentication measures required where MFA cannot be applied
What This Means in Practice for Linux Teams
Under the proactive supervision model for essential entities, NIS2 transforms the compliance posture from "be ready when something goes wrong" to "be ready at all times". Documented policies must be operationally implemented, evidence must be readily available, and key personnel must be able to demonstrate compliance during an unannounced inspection.
For a Linux estate, this translates into specific operational requirements: every sudo rule must be documented and justified, every SSH key must be traceable to a named individual, every privileged account must have a defined and regularly reviewed scope, and access must be revoked promptly upon role change or departure. Failure to demonstrate these controls carries penalties up to €10 million or 2% of global annual turnover, with personal executive liability for management failures.
What DORA Articles 5–16 Require for Privileged Access on Linux
The ICT Risk Management Framework
Chapter II of DORA (Regulation (EU) 2022/2554) — spanning Articles 5 through 16 — establishes foundational ICT risk management obligations for financial entities operating in the EU. This is directly applicable law, and it took effect on 17 January 2025. As of mid-2026, enforcement is intensifying — only an estimated 50% of financial institutions are fully compliant.
Key articles and their Linux access control implications:
- Article 5 (Governance and Organisation): The management body bears ultimate, non-delegable responsibility for ICT risk management. Board-level reporting on ICT risk posture must become a regular cadence — and that posture cannot be accurately reported without visibility into Linux privilege configurations
- Article 8 (Protection and Prevention): Financial entities must implement ICT security policies covering access management, including identity management, access control, and strong authentication mechanisms. This explicitly covers "root" accounts on Linux servers handling critical or important functions
- Article 9 (Detection): Detection capabilities must go beyond perimeter security — DORA expects behavioural analytics, anomaly detection, and near-real-time monitoring of critical systems. For Linux, this means monitoring privilege escalation, unauthorised sudo usage, and anomalous SSH key additions in near-real time
- Article 10 (Response and Recovery): Entities must have comprehensive audit trails with detailed forensic capabilities for incident investigation
- Article 15 (RTS Requirements): The Regulatory Technical Standards issued by the European Supervisory Authorities (EBA, EIOPA, ESMA) provide granular, binding specifications covering ICT security tools, detection capabilities, logging, and testing methodologies — financial entities must comply with both the regulation and the applicable RTS
DORA and Linux PAM: The Privileged Account Imperative
DORA's Delegated Regulation (EU) 2024/1774 explicitly references the need to protect "highly privileged accounts (such as 'root' on Linux servers) on critical systems". The regulation requires tools that provide automated alerts based on pre-defined rules to identify anomalies affecting the completeness and integrity of log collection. If your root accounts on Linux are not under continuous, automated monitoring, you have a gap that a DORA auditor will find.
What the EU AI Act Means for Linux Access Controls
A Third Regime Converges on the Same Infrastructure
The EU AI Act (Regulation (EU) 2024/1689) introduces a fourth regulatory dimension that IT teams running AI-adjacent Linux infrastructure cannot ignore. Following the Digital Omnibus provisional agreement reached by the EU Council and Parliament on 7 May 2026, the deadline for Annex III high-risk AI system obligations has been pushed from 2 August 2026 to 2 December 2027 — a 16-month postponement. Annex I obligations (AI embedded in regulated products) move to 2 August 2028. The agreement still requires formal adoption and publication in the Official Journal before these dates are legally binding.
The delay is real, but as industry commentators have been clear: it is not a reset. The compliance architecture is intact. Risk categories have not changed. Documentation requirements have not softened. What the postponement provides is additional runway to build evidence infrastructure — and that runway runs directly through the Linux estate.
Who Is In Scope
The AI Act applies to providers and deployers of AI systems operating in the EU market, regardless of where the organisation is headquartered. High-risk AI systems — those in Annex III — include AI used in critical infrastructure, employment and worker management, credit scoring and insurance risk, and access to essential services. For organisations in finance, utilities, and manufacturing — LinuxGuard's core ICP — high-risk AI system scope is extremely likely. Fewer than 25% of organisations have completed an AI system inventory.
Article 12: The Logging Mandate
Article 12 of the AI Act is the provision with the most direct bearing on Linux infrastructure. It mandates that high-risk AI systems "shall technically allow for the automatic recording of events (logs) over the lifetime of the system". The key word is automatic — not documented after the fact, not reconstructed from memory, but automatically generated throughout the system's operational life.
What Article 12 logging must capture (at minimum for biometric and access-related systems):
- The period of each use — start date/time and end date/time of each session
- The reference database against which input data was checked
- The input data for which a match was returned
- Identification of the natural persons involved in verifying results
Article 19 requires providers to retain these logs for at minimum six months, though auditors in employment, credit, and law enforcement contexts typically expect significantly longer retention windows. Financial institutions subject to DORA may satisfy Article 19 by maintaining AI logs as part of their existing regulatory documentation.
Why This Lands on Linux
Here is what makes the AI Act materially relevant to Linux infrastructure teams: if your organisation runs high-risk AI workloads — credit scoring models, anomaly detection engines, workforce management tools, fraud prevention systems — those workloads almost certainly run on Linux servers. The AI Act's logging obligations are infrastructure requirements as much as they are AI governance requirements.
Article 12 compliance requires logging infrastructure that is provider-independent, tamper-evident, and captures every inference, every access, every privileged action by a human operator on the system. For Linux, this means that the same auditd-based capture pipeline, centralised log collection, and immutable storage that satisfies DORA's Article 9 detection requirements and NIS2's Article 21(2)(i) access control obligations also provides the foundation for Article 12 compliance.
The Regulatory Collision: NIS2 + DORA + AI Act
Treating these three regimes as separate compliance exercises triples your workload and produces three overlapping audit programmes with redundant evidence gathering. The controls share significant common ground: risk management systems, audit trails, access control, incident detection, and human oversight. A unified Linux evidence architecture satisfies all three simultaneously.
Overlapping obligations across all three frameworks:
| Obligation | NIS2 | DORA | EU AI Act |
|---|---|---|---|
| Continuous audit logging | Article 21(2)(i) | Article 9, RTS | Article 12 |
| Access control and identity management | Article 21(2)(i) | Article 8 | Article 9 (risk mgmt) |
| Incident detection and alerting | Article 21(2)(f) | Articles 9–10 | Article 12(2)(a) |
| Change records and documentation | Article 21(2)(e) | Article 8 | Articles 11, 19 |
| Human accountability trail | Article 21(2)(i) | Article 5 | Article 14 |
What PCI DSS Requirements 7 and 10 Look Like on a Linux Estate
Requirement 7: Restrict Access by Business Need to Know
PCI DSS v4.0 Requirement 7 mandates a formal access control model based on the principle of least privilege. Access to system components and cardholder data must be limited to individuals whose job function requires it, with a default deny-all policy. Four specific elements are required:
| PCI DSS 7 Component | Linux Implementation | Evidence Required |
|---|---|---|
| Documented access control policy | Formal policy governing sudo rules and SSH key assignment | Policy document, version history |
| Role-based access control (RBAC) | Role-defined sudo groups, no direct root login[^34] | /etc/sudoers export, group membership records |
| Default deny-all configuration | Explicit allowlist of privileged access only | Configuration snapshots, baseline records |
| Access reviews every six months | Periodic audit of sudo rules, SSH keys, service accounts | Dated review records, remediation evidence |
A common failure mode: organisations implement RBAC but define roles too broadly, granting access to production environments that a developer's specific function does not require. On Linux, this manifests as overly permissive sudoers entries (e.g., ALL=(ALL) NOPASSWD: ALL) that effectively grant unrestricted root access without requiring a password.
Requirement 10: Track and Monitor All Access
PCI DSS Requirement 10 mandates that organisations implement automated audit trails to link all access to system components to individual users. For Linux estates, this maps directly to auditd — the Linux Audit daemon — which captures events at the kernel level and cannot be bypassed by user-space applications.[36][37]
What Requirement 10 specifically mandates for Linux:
- 10.2.1.1: Audit logs capture all individual user access to cardholder data
- 10.2.1.2: All actions taken by any individual with root or administrative privileges must be logged
- 10.2.1.5: All changes to identification and authentication credentials, including creation of new accounts and elevation of privileges
- 10.2.1.7: All creation and deletion of system-level objects
- 10.3: Audit logs must be protected from changes or destruction by unauthorised parties
- 10.5: Audit log history must be retained and available for analysis
- 10.6: Time-synchronisation mechanisms must support consistent time settings across all systems
Without centralised collection, local logs can be modified or deleted by anyone with shell access — which itself fails multiple PCI DSS controls.
What SOX ITGC Means for Linux Sysadmins
The Four ITGC Domains That Touch Linux
The Sarbanes-Oxley Act requires public companies to maintain adequate internal controls over financial reporting. For IT systems, this is implemented through IT General Controls (ITGC) — and Linux servers hosting financial applications, databases, or ERP systems are squarely in scope.
SOX auditors look for evidence that four ITGC domains are effectively managed:
- Access Management: Limit access to systems and sensitive financial data. Ensure only authorised users can perform critical functions, and review access rights regularly to avoid privilege creep
- Segregation of Duties (SoD): Separate key tasks across different personnel. For Linux sysadmins, this means the person who writes code cannot also approve and deploy it to production
- System Monitoring and Audit Logging: Track user activities, system events, and access attempts. Maintain audit logs and review them regularly for unusual or unauthorized behaviour that could compromise financial reporting
- Change Management: All changes to production systems must follow a formal, documented approval process with evidence of testing and authorisation
Privileged User Access Testing on Linux
SOX ITGC testing for privileged access on Linux follows a structured methodology that auditors apply during fieldwork. The test of design examines whether privileged access controls are properly configured at the system level — specifically reviewing /etc/sudoers files to confirm that privileged roles are clearly defined, that access provisioning is based on formal requests with ticket IDs and approval records, and that emergency access (firecall IDs) is time-bound and logged.
For Linux sysadmins, the practical implication is that every privileged access grant must have a corresponding approval record. If a developer was added to the wheel group on a production database server, there must be a ticket, an approval, and a dated change record. If that access is not reviewed and recertified on a defined schedule, it becomes a finding. Shared root passwords with no individual accountability are an automatic failure.
The Five Types of Evidence Auditors Actually Request
When a NIS2, DORA, AI Act, PCI DSS, or SOX auditor asks for Linux access control evidence, the requests fall into five categories. Understanding this taxonomy allows IT teams to build evidence generation into their operational workflows rather than scrambling to produce it retrospectively.
1. Access Logs
The most commonly requested evidence type — and now explicitly mandated by the EU AI Act's Article 12 for high-risk AI system operators as well as NIS2 and DORA. Auditors want timestamped records of who authenticated to which systems, using which credentials, and whether the attempt succeeded or failed. For Linux, this includes:
- SSH authentication logs (/var/log/auth.log or /var/log/secure)
- auditd records of sudo invocations, capturing the invoking user, target user, command executed, and timestamp
- PAM authentication records for local console access
- Failed login attempts and account lockout events
The audit framework must capture events at the kernel level to be forensically reliable. User-space logging can be bypassed; auditd cannot.
2. Privilege Reviews
Periodic evidence that privileged access has been formally reviewed and remains appropriate. Auditors want dated snapshots showing:
- A complete inventory of all accounts with sudo-to-root capability
- SSH key inventories mapping each public key to a named, current employee
- Service account privilege assignments and business justifications
- Evidence that orphaned accounts (users who have left the organisation) have been identified and disabled
- Sign-off from an authorised reviewer confirming appropriateness
For NIS2 and DORA, these reviews must demonstrate continuous posture management, not just point-in-time snapshots. An organisation that conducts an access review in January and makes no changes until the following January will have difficulty demonstrating proportionate risk management under Article 21(2)(i).
3. Change Records
Documented evidence that all changes to access control configurations were formally authorised, tested, and tracked. For Linux, auditors look for:
- Records of changes to /etc/sudoers and /etc/sudoers.d/ with before/after state and approver
- SSH key addition and removal records with change ticket references
- Group membership changes for privileged groups (wheel, sudo, docker)
- Changes to PAM configuration files
- Correspondence between auditd file-integrity records and change management tickets
Under SOX ITGC, a change detected in auditd with no corresponding approved change ticket is a segregation-of-duties violation. Under DORA Article 8 and the AI Act's Article 11 technical documentation requirements, undocumented changes to production ICT systems contradict explicit change management obligations.
4. Incident Trails
When a security incident occurs — or when a compliance control fails — auditors require a complete forensic trail. Linux-specific incident evidence includes:
- Chronological auditd event sequences showing privilege escalation attempts
- Records of privilege misuse (e.g., a standard user invoking sudo for unauthorised commands)
- Evidence of account creation or SSH key addition outside normal business hours or without a change record
- Alert records and response actions, demonstrating that detection capabilities were functioning
NIS2 Article 23 mandates a 24-hour initial notification for significant incidents, with a detailed assessment within 72 hours. DORA similarly requires financial entities to detect anomalies and trigger alerts within hours, not days. Neither obligation can be met without continuous, automated monitoring of Linux privilege activity.
5. User Inventories
A complete, current record of all user identities on the Linux estate — not just active users, but service accounts, shared accounts, and orphaned accounts. For AI Act compliance, this inventory extends to the human operators who interact with and oversee high-risk AI systems, as required by Article 12(3)(d). Auditors specifically look for:
- Full account inventory from /etc/passwd across all in-scope servers
- Identification and disposition of accounts that have no corresponding current employee
- Documentation of shared accounts with justification and compensating controls
- Service account inventories with owners, purposes, and privilege scopes
- Demonstration that dormant or unneeded accounts have been disabled or removed
One LinuxGuard audit of a multi-country payments provider found 247 orphaned accounts with active sudo rules and 31 shared SSH keys across hundreds of Linux systems — each one a potential NIS2, DORA, PCI DSS, and AI Act finding waiting to be discovered by an auditor.
How to Generate That Evidence Continuously and Automatically
The Technical Foundation: auditd and Centralised Log Collection
The Linux Audit framework (auditd) provides the kernel-level event capture that all four compliance frameworks require. Configured with appropriate rules, it captures authentication events, privilege escalation, file permission changes, and system call activity in a tamper-resistant manner that satisfies the "automatic" logging mandate of AI Act Article 12 as well as PCI DSS Requirement 10. Key rules for compliance include:[37][27][^38]
# Monitor sudo configuration changes
-w /etc/sudoers -p wa -k sudoers
-w /etc/sudoers.d/ -p wa -k sudoers
# Track privilege escalation
-w /usr/bin/sudo -p x -k privilege_escalation
# Monitor SSH key management
-w /root/.ssh -p wa -k ssh_keys
-a always,exit -F dir=/home -F name=.ssh -F op=create -k ssh_keys
# Monitor authentication file changes
-w /etc/passwd -p wa -k auth_changes
-w /etc/shadow -p wa -k auth_changes
-w /etc/group -p wa -k auth_changes
However, auditd alone is not sufficient for compliance. Local logs can be modified by root users, they are not centralised across a multi-server estate, and they do not produce the structured, human-readable inventory formats that auditors expect. The evidence generation architecture requires four layers working together.
The Four-Layer Evidence Architecture
Layer 1 — Kernel-Level Capture: auditd rules configured to capture all privileged access events, authentication changes, and system configuration modifications at the kernel level, ensuring events cannot be suppressed by user-space processes
Layer 2 — Centralised Collection: Log forwarding (via Filebeat, rsyslog with TLS, or equivalent) to a centralised, immutable log store, removing the ability for local users to modify or delete audit evidence. Centralised collection also enables cross-server correlation — a requirement for DORA's anomaly detection obligations and the AI Act's post-market monitoring requirements[31][50][40][15]
Layer 3 — Identity Inventory Scanning: Scheduled collection of identity state from /etc/passwd, sudoers configuration, SSH authorized_keys files, and PAM configuration across the entire estate. This produces the user inventories and privilege maps that auditors request, and detects drift between authorised baselines and actual configurations
Layer 4 — Continuous Evidence Export: Automated generation of auditor-ready evidence packages — structured reports mapping the above data to specific framework controls — on a continuous basis rather than at audit time. This eliminates the weeks-long manual effort of evidence gathering and ensures evidence is always current across NIS2, DORA, AI Act, PCI DSS, and SOX simultaneously.
From Manual to Continuous: What Changes
| Evidence Type | Traditional Approach | Continuous Approach |
|---|---|---|
| Access logs | Manual grep across log files at audit time |
Centralised, indexed, queryable with auditd + SIEM
|
| Privilege reviews |
Manual SSH into each server, export /etc/sudoers
|
Automated estate-wide inventory with drift detection |
| Change records | Reconcile change tickets with server configs manually | Automated correlation of configuration changes to change tickets |
| Incident trails | Reconstruct from disparate logs post-incident | Pre-built forensic trail from continuous monitoring |
| User inventories | Spreadsheet-based, stale within days | Live inventory with orphan account detection |
| AI system access logs (AI Act) | Not captured at all | Immutable log of all human interactions with AI workloads |
LinuxGuard Capability Map to Each Framework
LinuxGuard delivers identity-first security for Linux through continuous monitoring of users, groups, sudo rules, and SSH keys across the entire Linux infrastructure. The platform maps each capability to the specific control obligations under NIS2, DORA, the EU AI Act, PCI DSS, and SOX ITGC.
| Framework | Key Obligation | LinuxGuard Capability |
|---|---|---|
| NIS2 Article 21(2)(i) | Access control policies and asset management | Estate-wide user inventory, sudo privilege mapping, SSH key inventory with drift detection |
| NIS2 Article 21(2)(a) | Risk analysis and documented security policies | Continuous configuration baseline assessment, CIS Benchmark alignment checks |
| NIS2 Article 21(2)(j) | MFA and access restriction to authorised users | Detection of accounts without MFA, shared credentials, and anonymous access paths |
| DORA Article 8 | Identity management and access control, strong authentication | Real-time privilege monitoring, automated alerts on sudo escalation and SSH key additions |
| DORA Article 9 | Near-real-time anomaly detection on critical systems | eBPF-powered behavioural monitoring, anomaly alerting on privilege activity |
| DORA Article 10 | Comprehensive audit trails for incident forensics | Immutable audit trail export, incident evidence packages |
| EU AI Act Article 12 | Automatic logging of events over the AI system lifetime | Continuous logging of AI-related privileged activity and configuration changes |
| EU AI Act Article 19 | Six‑month minimum log retention | Retention‑compliant storage of privileged access logs and evidence exports |
LinuxGuard produces auditor-ready evidence mapped to NIS2, DORA, the EU AI Act, PCI DSS, SOC 2, CIS, NIST, and ISO 27001 from actual Linux configuration — not spreadsheets — and reduces audit preparation from weeks of manual gathering to a single structured export. The 28-day Linux Identity & Security Audit delivers a complete privilege map, risk-ranked findings, and board-ready compliance evidence in a fixed-scope, fixed-fee engagement.
Review the LinuxGuard documentation regarding compliance here: https://docs.linuxguard.io/audit-and-comply/audit-comply
The Compliance Case for Acting Now
NIS2 scope has expanded from approximately 10,000 entities under NIS1 to over 160,000 under NIS2. Essential entities in energy, banking, financial market infrastructure, transport, and health are subject to proactive supervision — meaning regulators can inspect at any time, not only after an incident. Important entities in manufacturing, food production, and digital providers face reactive supervision, but the evidence obligations under Article 21 apply equally.
DORA enforcement is intensifying. Only 50% of financial institutions are estimated to be fully compliant as of 2026. National regulators have submitted their first Register of Information filings to the European Supervisory Authorities, marking the beginning of active, cross-border enforcement scrutiny. Firms that fall short face fines of up to 10% of annual turnover.
The EU AI Act's 16-month postponement is not a holiday from compliance work. The organisations that use the additional runway to build Linux infrastructure evidence capabilities — AI system inventories, access logs, privilege maps, operator identity trails — will satisfy all three frameworks simultaneously at the December 2027 deadline. The organisations that treat the delay as permission to defer will face the same frantic manual evidence-gathering scramble in 2027 that their NIS2 and DORA counterparts are living through today.
The Linux compliance gap is not a theoretical future problem. It is the question your next auditor will ask — whether that auditor is reviewing NIS2, DORA, PCI DSS, SOX, or AI Act compliance. Building continuous evidence generation into the Linux estate now closes that gap across all five frameworks simultaneously.
