Topic starter
28/09/2026 4:05 pm
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.
Editorial analysis by NHI Mgmt Group, based on content published by LinuxGuard: “Linux Access Control under the UK NCSC Cyber Assessment Framework”.
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.
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.
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.
Practitioner guidance
- 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.
Bottom line: The article frames CAF compliance on Linux as an evidence problem, because outcomes must be demonstrated through current host-level access state.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
28/09/2026 4:07 pm
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.
A few things that frame the scale:
- Only 5.7% of organisations have full visibility into their service accounts, according to the Ultimate Guide to NHIs.
A question worth separating out:
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.
👉 Read our full editorial: Why the NCSC CAF maps directly to Linux access control