How a Forgotten Linux Account Can Put Your CEO Personally at Risk Under NIS2

The auditor doesn’t care that you’re busy.
The regulation doesn’t care that Linux is hard.
And the attacker who finds that sudo rule you forgot about in 2019 definitely doesn’t care.

Most of us don’t wake up excited about compliance.

NIS2, DORA, the EU AI Act — the acronyms blur together, the PDFs stack up, and somewhere around page 47 your brain starts planning dinner.

But this story doesn’t end in a checkbox.
It ends either with your CEO explaining personal liability to the board, or with a threat actor using a forgotten Linux account to walk quietly through your infrastructure.

Both outcomes are avoidable.
Both trace back to the same blind spot: Linux access controls that nobody is watching.

The credential your attacker is already betting on

Credential‑based attacks are still one of the most common ways breaches start. IBM’s 2025 Cost of a Data Breach work shows that incidents involving stolen or compromised credentials are among the most expensive, with average costs in the mid‑single‑digit millions of dollars per breach.

Detection is slow. Credential‑driven breaches typically take many months to identify and contain, giving an attacker a long window to operate as a “valid user” inside your environment.

On Linux, that “valid user” often looks like:

• A service account with sudo‑to‑root permissions that nobody remembers owning.
• An SSH key in an authorized_keys file that still grants access, even though the corresponding identity left the company two years ago.
• A sudo rule created for an emergency change that was never cleaned up.

In mid‑2025, a critical sudo vulnerability (CVE‑2025‑32463) was disclosed, allowing local users to escalate to root using the chroot option, with a CVSS 3.1 score of 9.3. Exploitation details and public proof‑of‑concept code followed quickly, and distributions rushed to patch.

The pattern is familiar:

• Linux is a high‑value target.
• Privilege escalation paths are plentiful.
• The weakest link is often not the kernel, but the sudo rule or SSH key you forgot about.

The sudo rule you forgot is still the one they find first.

The regulation that follows the people, not just the company

Most compliance discussions focus on fines. That’s only half the picture.

Under the NIS2 Directive, essential and important entities face administrative fines that can reach up to 10 million euros or 2% of global annual turnover, whichever is higher (and 7 million or 1.4% for important entities), depending on the violation.

But the sharper edge is personal accountability.

NIS2 requires that management bodies approve and oversee cybersecurity risk‑management measures and can be held liable for serious failures to comply. Member states, including Germany, have translated that into national law with immediate effect. Germany’s NIS2UmsuCG entered into force on 6 December 2025, with no transition period, and introduced strict registration, oversight, and enforcement powers.

For German entities in scope:

• Thousands of organisations had to register with the BSI by 6 March 2026.
• Non‑compliance can trigger significant fines tied to turnover.
• Management is explicitly in the frame for governance and oversight duties.

Across the EU, surveys now show a consistent pattern: only a minority of businesses feel “fully ready” for NIS2, even after the April 2026 compliance date, and many cite execution gaps rather than a lack of awareness.

In other words: the regulatory clock has already started, and many organisations — and their executives — are still exposed.

Three regulators, one shared blind spot

What makes the current moment unusual is not that we have new regulations, but that three major EU regimes converge on the same operational reality — and all of them run straight through your Linux estate:

• NIS2: Applies to a large population of “essential” and “important” entities across critical sectors, with requirements around risk management, access control, incident reporting, and board‑level oversight. Member states now have national laws in force and have begun active supervision.
• DORA: In force since January 2025 as directly applicable EU law for financial entities and certain ICT providers, with explicit obligations around ICT risk management, incident detection, and logging on critical systems. Supervisors have begun to move from guidance into audits and follow‑up reviews.
• EU AI Act: The political agreement and Digital Omnibus adjustments extended key deadlines, including high‑risk system obligations into late 2027, but kept the core compliance architecture intact — risk categories, logging, and documentation duties remain.

Strip away the legal detail and you see the same demands repeated:

• Continuous audit logging on critical systems.
• Strong privileged access and identity controls.
• Near‑real‑time incident detection and anomaly monitoring.
• A clear, human accountability trail over changes and access.

If your critical workloads, AI systems, and payment engines run on Linux, then Linux is where those controls must actually exist — not just in policy documents.

The organisations building this capability now, across all three regimes in one go, will be having very different conversations with auditors in 2027 than those still exporting spreadsheets from ad‑hoc shell scripts.

The gap your stack never closed on Linux

There’s a structural reason this keeps getting missed: most enterprise security tooling was built around centralised directories and Windows‑centric logging.

• SIEM platforms are excellent at aggregating logs — but they only see what’s forwarded.
• IGA systems govern the identities they know about — usually in AD, HR, or central IdPs.
• PAM tools manage privileged sessions — once you’ve integrated the target systems properly.

On Linux, a large part of the identity and privilege story lives outside those systems:

• /etc/passwd and /etc/group controlling local accounts.
• /etc/sudoers and sudoers.d defining who can escalate and how.
• SSH authorized_keys files scattered across many servers.
• PAM configuration influencing who can authenticate and under what conditions.
• Cron jobs and service accounts that no central directory tracks cleanly.

Most of this is not automatically inventoried, risk‑scored, or reconciled against HR and IAM systems. It is also not easily exposed in a single, current view for an auditor.

That leads to the same painful pattern every audit cycle:

• Someone gets an email asking for “a complete list of all accounts with sudo‑to‑root access, as of now.”
• Teams fan out with SSH, grep, and ad‑hoc scripts.
• Weeks later, they submit a spreadsheet that is already out of date.

In the meantime, privilege drift continues: accounts are created, keys are added, sudo rules evolve, and no central system tracks the effective privilege landscape.

This isn’t just an operational problem. It is a live exposure across NIS2, DORA, PCI DSS, SOX, and the AI Act whenever critical workloads run on Linux.

What auditors are really asking

If you simplify the regulatory language, every NIS2, DORA, and EU AI Act auditor is effectively asking the same five questions of your Linux estate:

1. Who can do what right now?
   Not last quarter, not at last audit — right now. That includes every account with sudo‑to‑root capability, every SSH key mapped to a named person, and every service account with elevated privileges and a documented purpose.
2. How fast do you detect change?
   They want to see how you catch privilege drift: new sudo rules, new SSH keys, changing group memberships, and expanded access. NIS2 and DORA both speak to timely detection and reporting of significant incidents; without continuous monitoring of Linux privilege and identity state, those obligations are hard to meet in practice.
3. Can you reconstruct what happened?
   This means system‑level and kernel‑level audit logs that:

• Capture privileged actions and security‑relevant events.
• Are centralised so they cannot be tampered with by someone who has local shell access.
• Are retained and searchable in a way that stands up in a regulatory investigation.

1. Was every change authorised?
   Auditors look for a clear link between changes (new sudo rule, new account, new key) and approved change records. For financial and listed entities, this intersects with SOX IT general controls; under DORA, undocumented changes to production ICT systems conflict directly with formal change‑management duties.
2. Where is the AI system access trail?
   For high‑risk AI systems — credit scoring, fraud detection, workforce management, and others that often run on Linux — the EU AI Act requires automatic, tamper‑evident logging of system behaviour and human interventions over the system’s lifetime. That log has to live somewhere concrete, with access, changes, and privileged actions traceable back to identities.

Most organisations can answer some of these questions for their Windows and SaaS estate. Very few can answer all five confidently and continuously for Linux.

An architecture that actually answers all five

You do not need yet another monolithic platform to close this gap. You need four layers working together, using primitives you already know:

1. Kernel‑level capture
   Use Linux audit frameworks (for example, auditd on distributions that support it) to capture:

• Privileged execution (sudo, su, setuid binaries).
• Authentication changes and account modifications.
• Security‑relevant configuration changes.

User‑space logging is useful but can be bypassed; kernel‑level capture is harder to evade.

1. Centralised, immutable collection
   Forward logs (for example, via rsyslog, journald forwarding, or agents) into a central store that:

• Is protected from modification or deletion by local users.
• Supports retention aligned to regulatory expectations.
• Provides correlation across servers for anomaly detection.

This is the foundation for DORA‑style anomaly detection and for AI Act post‑market monitoring on Linux workloads.

1. Identity and privilege inventory
   Continuously collect and normalise the Linux identity and privilege state across your estate:

• /etc/passwd, /etc/group, sudoers and includes.
• SSH authorized_keys and known_hosts where relevant.
• PAM and authentication configuration.

From this, generate:

• A live map of “who can do what, where.”
• Drift detection between authorised baselines and reality.
• Orphaned accounts, stale keys, and over‑privileged service identities.

1. Continuous evidence export
   Map the data you already collect to specific controls in NIS2, DORA, PCI DSS, SOC 2, ISO 27001, and the EU AI Act, and export evidence packages on demand instead of assembling them manually before each audit.

The shift here is not just automation. It changes your relationship with regulators:

• From reactive (scrambling before an inspection)
• To proactive (showing continuous control and monitoring)

That is the difference between an audit that drains three weeks of engineering time and one that consumes a few hours of review.

The real question

At some point, you will get the Tuesday‑morning email.

It will ask, in different words, for the same things:

• Who had root on these systems?
• When did that change?
• How do you know?
• Where is the evidence?

NIS2’s proactive supervision model does not require an incident before regulators come asking.
DORA’s enforcement phase has already begun.
The EU AI Act clock is ticking toward the 2027 high‑risk system deadlines.

The Linux compliance gap is not a future problem. It is embedded in today’s audits — whether the label is NIS2, DORA, PCI DSS, SOX, or the AI Act.

Building continuous evidence generation into your Linux estate now closes that gap across all of them at once. It turns the audit email from an emergency into a scheduled export.

And it answers the question that matters most:

The sudo rule you forgot about is still there.
Who is going to find it first — your attacker, your auditor, or you?

LinuxGuard is built around that question. We focus on identity‑first security for Linux: continuous mapping of users, groups, sudo rules, and SSH keys across your estate, with auditor‑ready evidence aligned to frameworks like NIS2, DORA, the EU AI Act, PCI DSS, SOC 2, CIS, and ISO 27001. Our 28‑day Linux Identity & Security Audit delivers a full privilege map, risk‑ranked findings, and board‑ready evidence — fixed scope, fixed fee, and a small, predictable time commitment from your team.

If you had to answer “who can do what, right now, on every Linux system you run” this week, how confident would you be in the answer?