TL;DR: The NCSC Cyber Assessment Framework applies to Linux through access outcomes, not operating-system language, and LinuxGuard shows that Principle B2 lands on accounts, sudo rules, SSH keys, and service accounts. For practitioners, the key issue is that access governance for essential functions must prove live control over human and automated functions, not just policy intent.
At a glance
What this is: This article explains how the NCSC Cyber Assessment Framework maps to Linux access control through Principle B2, with the main evidence centred on accounts, sudo rules, SSH keys, and service accounts.
Why it matters: It matters because Linux estates often hold the privileged and automated access that assessors expect teams to prove, not just describe, and that evidence model is directly relevant to NHI, human admin, and lifecycle governance programmes.
Context
The NCSC Cyber Assessment Framework does not name Linux, but its identity and access expectations still apply wherever essential functions run on Linux hosts. The governance problem is not whether the operating system is mentioned. It is whether the organisation can prove who and what can access in-scope systems, under what privilege, and with what ongoing control.
On Linux, that proof lives in accounts, sudo rules, SSH keys, and service accounts rather than in policy statements. The framework is therefore an access-evidence exercise, and that makes it relevant to both human administration and non-human identity governance. The same control gap can show up in a named admin account, a stale SSH key, or an orphaned service account.
The article also shows why static inventory is not enough. CAF assessment expects a live relationship between documented access and actual host state, which is exactly where most Linux estates diverge from their governance story.
Key questions
Q: What breaks when Linux access is documented but not reconciled to live host state?
A: The assessment story breaks, because the CAF cares about managed outcomes rather than declared intent. If host state is not reconciled, sudo rules, SSH keys, and service accounts can drift away from the recorded picture without anyone noticing. That leaves you unable to prove that essential-function systems are actually controlled, which weakens both compliance evidence and operational assurance.
Q: Why do service accounts create CAF evidence gaps on Linux?
A: Service accounts often persist longer than the business event that created them, and that makes their access harder to justify in outcome-based assessments. They can retain sudo, host login rights, or key-based access after the original task has ended. If ownership and removal triggers are unclear, the organisation cannot convincingly show that automated functions are appropriately authorised and managed.
Q: How should teams prove least privilege for Linux administration under CAF?
A: They should show who can elevate, by what route, and for what purpose, using host-level evidence rather than directory roles alone. The useful proof is a named administrator model, narrow sudo entitlements, and records that show privileged access is granted and withdrawn deliberately. Shared root access and broad NOPASSWD rules make that proof much harder.
Q: What is the difference between an access policy and CAF-ready access evidence?
A: An access policy states what should happen, while CAF-ready evidence shows what is happening on the hosts that matter. On Linux that means current accounts, sudoers entries, SSH keys, and service account ownership aligned to the systems supporting essential functions. A policy without live reconciliation is aspiration; evidence is the current state plus the history of change.
Technical breakdown
Why CAF B2 maps to Linux host identity evidence
Principle B2, Identity and Access Control, is an outcome statement about managed access, not a product or a platform. On Linux, the relevant objects are local and operational: user accounts, sudo privileges, SSH keys, and service accounts that authenticate directly on hosts. The important technical point is that the framework cares about whether access is verified, authorised, documented, and kept current across those objects, not whether they sit in a single directory or management console. That is why the same host can look compliant on paper while still exposing a dormant key or an overbroad sudo rule.
Practical implication: assess Linux access at host level, not just in directory reports.
Why service accounts and SSH keys matter as much as human admins
CAF wording explicitly includes automated functions, which means access control extends beyond named people. In Linux environments, service accounts often carry persistent privileges, and SSH keys can outlive the operator or system they were created for. Technically, these identities bypass the assumptions many review processes make about a human owner, a clear start date, and an obvious offboarding event. That is why a forgotten key or orphaned daemon account is not a minor hygiene issue; it is part of the access-control surface the framework is asking you to manage.
Practical implication: inventory non-human access with the same rigor as privileged human accounts.
Why point-in-time reviews are weak evidence on Linux
The framework is outcome-based, so evidence has to demonstrate that access is controlled over time, not merely documented once. A spreadsheet can show intended privilege, but it does not prove that sudo rules, authorized keys, and service account access still match that intent today. Linux teams need reconciliation between baseline and live state because privilege drift is normal in operating environments that change frequently. Without that reconciliation, the assessment can only confirm a claim about access, not the access reality on the host.
Practical implication: pair access inventories with continuous host-level reconciliation and change records.
Breaches seen in the wild
- Cisco Active Directory credentials leak 2025: Kraken leaked Cisco Active Directory hashes, including service and krbtgt accounts; Cisco says they came from its 2022 breach, not a new one.
- Secrets in Docker Hub images (RWTH Aachen study): A 2023 RWTH Aachen study found secrets in 8.5% of container images, and 275,269 internet hosts still using the leaked private keys.
Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
CAF B2 on Linux is really a control over evidence, not just access. The framework asks organisations to understand, document, and manage access to essential-function systems, which on Linux means host-level accounts, sudo rules, SSH keys, and service accounts. That turns the problem into one of provable access governance, not administrative intent. Practitioners should treat the Linux estate as the evidence source, not the policy document.
Non-human identity is embedded in the CAF even when the framework never uses that term. The phrase automated functions is the key signal, because it brings service accounts and machine-held credentials into the same control expectation as human users. That is a direct overlap with NHI governance, where the challenge is not whether access exists but whether it is owned, scoped, and retired on time. The implication is that Linux access programmes must govern both humans and machines as one lifecycle problem.
Static access snapshots are structurally too weak for outcome-based assessment. A once-a-year review assumes access is stable enough to observe, certify, and close. Linux estates break that assumption through short-lived admins, delegated sudo, one-off migration accounts, and keys that persist after their original purpose ends. The implication is that access governance has to move from declaration to verification if teams want credible CAF evidence.
Least privilege on Linux is not a policy slogan but a live control boundary. Blanket root, shared admin logins, and accumulated sudoers entries create evidence gaps that are easy to miss until assessment or incident response. The framework rewards organisations that can show exactly who can elevate, why they can do it, and how that privilege is withdrawn. The implication is that privilege scope must be demonstrable at host level, not inferred from directory role design.
Identity and access control becomes the hinge between human IAM and NHI governance. Linux estates expose how often those two disciplines share the same technical artefacts but different management habits. The same host can contain a human administrator, a service account, and an SSH key chain that all need different ownership and review logic. The implication is that identity programmes should stop separating human and machine evidence when the control objective is the same.
From our research library:
- Only 5.7% of organisations have full visibility into their service accounts, according to the Ultimate Guide to NHIs.
- Read next: Service Account Security Guide
What this signals
Identity evidence is the real control plane for CAF on Linux: the framework can only be satisfied when organisations can show current host-level state for accounts, sudo rules, SSH keys, and service accounts. That shifts the programme from policy authoring to continuous verification, which is where many Linux estates are weakest.
The most important operational change is to treat automated functions as governed identities, not as incidental infrastructure. Once service accounts and keys are in scope, review cadence, ownership, and removal triggers become part of identity governance rather than an operations side task.
For practitioners
- Audit Linux host-level identity evidence Build an in-scope inventory that includes local accounts, sudo rules, SSH keys, and service accounts on every Linux host supporting essential functions.
- Reconcile documented access to live state Compare declared access against current host configuration so that drift in /etc/passwd, /etc/sudoers, and authorized_keys is visible before assessment.
- Separate human and automated access ownership Assign explicit owners, business purpose, and removal triggers to service accounts and other automated functions so they can be reviewed and retired.
- Evidence privilege reduction at the host Replace shared root use with named administration and constrained sudo pathways, then retain change history that shows when elevated access was granted and removed.
Key takeaways
- The article frames CAF compliance on Linux as an evidence problem, because outcomes must be demonstrated through current host-level access state.
- Linux access control under CAF depends on visibility into accounts, sudo rules, SSH keys, and service accounts, not just directory-level role design.
- Teams that can reconcile declared access to live host configuration are better positioned to prove managed access and reduce assessment friction.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-05 — Overprivileged NHI | Linux sudo sprawl and broad service account rights create overprivileged non-human access. |
| NHI-01 — Improper Offboarding | Stale SSH keys and retired service accounts show offboarding failures on Linux hosts. | |
| NHI-07 — Long-Lived Secrets | SSH keys and persistent credentials remain valid long after their original purpose on Linux. | |
| Recommendation — Map Linux service accounts and sudo pathways to NHI-05 and remove unnecessary elevation rights. Revoke Linux keys and service accounts when ownership ends to enforce NHI-01. Review Linux SSH key age and secret lifetime to eliminate long-lived credentials. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | CAF B2 aligns with managing who can access essential-function Linux systems. |
| Recommendation — Maintain a live Linux access inventory and reconcile entitlements against host state. | ||
| CIS Controls v8 | CIS-5 — Account Management | Linux account and sudo governance depends on disciplined account management across hosts. |
| Recommendation — Track Linux accounts centrally and remove dormant or unmanaged access quickly. | ||
| MITRE ATT&CK | TA0006;TA0008 — Credential Access; Lateral Movement | Stolen keys and broad sudo rights enable attackers to move from access to privilege abuse. |
| Recommendation — Hunt for exposed SSH keys and privilege paths that support credential access and lateral movement. | ||
Key terms
- Identity And Access Management: Identity and Access Management is the discipline of controlling who or what can access systems, data, and services. It covers identity lifecycle, authentication, authorization, provisioning, deprovisioning, and policy enforcement across users, devices, applications, and non-human identities, so access is granted only to approved entities under defined conditions.
- Service Account: A special-purpose account used by applications, automated tools, or services rather than a human user to interact with systems, APIs, and infrastructure. Service accounts are a primary category of NHI and one of the most frequently exploited attack vectors.
- Sudo Rule: A policy entry that allows a Linux user or account to elevate privileges for specific commands or, in some cases, broadly across the host. Sudo rules are a high-value governance object because they often become the practical boundary between standard user access and root-level control.
- Access Evidence Trail: The access evidence trail is the set of records that proves who had access, why it was granted, who reviewed it, and what changed after review. In PCI DSS 4.0, the trail matters as much as the control because assessors need proof, not assumptions.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on September 28, 2026.
Updated on October 7, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org