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.
NHIMG editorial: based on content published by LinuxGuard: Does the NCSC CAF Apply to Linux?
Questions worth separating out
Q: What breaks when Linux access is not managed as a live inventory for CAF assessments?
A: The assessment breaks at the point where documentation no longer matches reality.
Q: Why do stale sudo rules and SSH keys create CAF risk on Linux?
A: They create risk because they preserve access after the original need has passed.
Q: How do teams know whether CAF identity and access control is actually working on Linux?
A: Look for current host-level evidence that matches the approved access model.
Practitioner guidance
- Inventory every Linux access path Build a live register of accounts, sudo rules, SSH keys, and service accounts on every in-scope host, and reconcile it to owner and purpose data.
- Separate named admin access from shared root use Remove shared logins where possible, enforce named administrative identities, and tie elevation to individual accountability on the host.
- Review privileged service accounts as first-class identities Track service account owners, expiry, and purpose so automated functions are removed when systems retire or workflows change.
What's in the full article
LinuxGuard's full analysis covers the operational detail this post intentionally leaves for the source:
- Line-by-line interpretation of CAF Principle B2 for Linux teams and assessors
- Practical evidence examples for accounts, sudoers entries, SSH keys, and service accounts
- CAF version 4.0 changes that tighten expectations around privileged access abuse
- Comparison of CAF and NIS2 access-control evidence in multinational Linux estates
👉 Read LinuxGuard's analysis of how the NCSC CAF applies to Linux access control →
NCSC CAF on Linux: what identity and access evidence do you need?
Explore further
28/09/2026 4:07 pm
CAF B2 is really an identity inventory test on Linux: the framework's outcome language becomes a requirement to account for every human and automated access path on the host. On a Linux estate that means accounts, sudo, SSH keys, and service accounts must be visible as one governed access surface. Organisations that treat directory identity as the whole picture will miss the privileged state that actually matters for assessment.
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: How should organisations balance CAF and NIS2 access evidence for Linux estates?
A: They should build one authoritative picture of Linux access and reuse it across both regimes. CAF wants outcome evidence for essential functions, while NIS2 expects access-control measures and governance to be demonstrable under local law. A single live inventory of host access reduces duplication and strengthens both compliance narratives.
👉 Read our full editorial: Why the NCSC CAF maps directly to Linux access control
