Linux Access Control for Critical National Infrastructure: NIS2 and NCSC CAF
Energy, water, telecoms, transport and data centres run essential functions on Linux — historians, gateways, network management, billing. Years of operator accounts, integrator access from long-finished projects, and shared engineering credentials have built paths to root on those hosts. Those paths live on the host, outside what SIEM, EDR and cloud IAM were designed to inspect. Automation and AI agents now find and use them faster than any review. NIS2 and the NCSC CAF already ask for that map. LinuxGuard maps every path and watches for change — without touching anything on the OT side.
Sample console. Every figure shown is illustrative, not from a live estate.
How privilege builds up behind essential functions
Entitlement spread on a converged IT/OT estate: six common situations, and what LinuxGuard does about each.
Integrator and supplier accounts that outlived their project
The integrator who commissioned the historian still has sudo on it. LinuxGuard inventories every third-party account with the sudo rules and keys attached, and shows which essential-function hosts it reaches. It flags the dormant ones and the access that exceeds its authorised scope, so supplier access can carry an expiry instead of a permanent grant.
Shared engineering credentials
One shared ops login used by a shift of eight means no action on that host is attributable to a person. LinuxGuard flags shared accounts and keys reused across accounts and servers, scores them, and attributes logins, sudo commands and configuration changes to the identity behind them, so shared credentials become visible, and replaceable.
The maintenance-window sudo grant that outlives the window
Sudo opened for a Sunday patch run on a gateway host is still open in March. LinuxGuard tracks sudoers, SSH and PAM configuration against an approved baseline, surfaces the change in near-real-time and attributes it to the identity that made it, so the grant surfaces while the window is still fresh rather than at the annual review.
Collectors, vendor tooling and agents that log in as service accounts
The telemetry collector, the integrator’s remote maintenance tooling and, increasingly, AI agents in the engineering pipeline all log in as service accounts and inherit whatever reach those accounts have built up on the hosts behind the essential function. LinuxGuard shows what each service account can do on each host, ranks the ones with a path to root, and flags the moment that reach changes.
Knowing the blast radius before it matters
If an operator workstation credential is stolen, which hosts behind the essential function can it reach, and can it get to root there? The identity graph answers that per host, and a gated response action can cut the path.
Sensitive hosts, handled as sensitive
Collection is lightweight and read-only, scoped to the Linux layer. No industrial control protocol, PLC or SCADA system is touched, and nothing changes on a host without an approved action.
Scope is the Linux layer of the converged estate: the operator, engineering, integrator and service accounts holding privilege there.
How the pilot runsWhy it matters
Attackers on Linux log in. They rarely break in.
of enterprise attacks use no malware
of breaches involved stolen or misused credentials
days to identify and contain a credential breach
OT, PLC or SCADA systems touched by the pilot
CrowdStrike 2025 Global Threat Report · Verizon DBIR 2025 · IBM Cost of a Data Breach 2025
Linux under the NCSC CAFWhat changes for the operator
LinuxGuard is the control plane for Linux identity. On an essential-function estate, that means:
- Fewer identities that can take an essential-function host down. Standing privilege reduced to what the role needs; every remaining account scored, with the factors behind the score shown inline.
- Supplier access you can put a date on. Every integrator and vendor account listed with what it can reach; any change to its privilege detected and attributed to the identity that made it.
- Attribution on hosts where shared logins were the norm. Who ran which sudo command, and who changed which configuration file, tied to a person rather than to a shared account.
- A board answer that is a dated map, not a policy statement. Continuous scoring against NIS2, the NCSC CAF and NIST SP 800-53, with the evidence exported when the management body or the regulator asks.
Where the evidence lands
When your national supervisory authority asks, or your sector regulator assesses you against the CAF, this is where the same inventory answers them.
| Article / Requirement | What It Mandates | How the Founding Pilot Covers It |
|---|---|---|
| NIS2 Article 21(2)(i) | Identity and access management | Full inventory of users, groups, sudo rules, SSH keys, PAM configuration, and service accounts on essential-function Linux hosts with privilege path mapping |
| NIS2 Article 21(2)(a) | Risk analysis and information system security policies | Risk-scored findings mapped to exploit patterns and prioritised by impact on the continuity of essential services |
| NIS2 Article 21(2)(d) | Supply chain security | Assessment of integrator and third-party privileges, identifying vendor accounts with excessive or unreviewed access |
| NCSC CAF Principle B2 | Identity and access control (verify, authenticate, authorise, least privilege, review) | Evidence of privileged-access governance on Linux hosts supporting essential functions, aligned to the B2 outcomes your sector regulator assesses you against |
| NIST SP 800-53 (AC) | Access control family (secondary, for US-facing CNI) | Mapping of Linux access-control findings to the AC control family where NIST baselines apply |
Frequently Asked Questions
Do you monitor our OT, SCADA or industrial control systems?
We run SLES, RHEL and some hardened or older builds. Will it run?
Can we act on a finding without risking an outage?
Does the pilot assess us against the CAF, or sign the assessment off?
What does our board get out of this?
Is NIS2 in force everywhere?
How long does the CNI pilot take?
Related solutions
NIS2 on its own, in more depth — what Article 21 asks of the identity and access controls on the Linux systems behind an essential service.
Explore the NIS2 Pilot
If more than these two apply to you — how one Linux identity evidence set maps across every framework a regulated organisation answers to.
View Regulated Industries
The product behind the pilot — least-privilege access control and compliance posture for Linux infrastructure.
View Security & Compliance
Further reading: Linux access control under the UK NCSC Cyber Assessment Framework.
Ready to see every path to root behind your essential functions?
Start the pilot on your essential-function Linux estate: every operator, integrator and service account mapped, every change flagged — and the evidence for NIS2 Article 21 and NCSC CAF Principle B2 produced from the same inventory.