Linux Access Control under the UK NCSC Cyber Assessment Framework

Does the NCSC CAF Apply to Linux?

The NCSC Cyber Assessment Framework — the CAF — is the UK's outcome-based framework for judging whether an organisation is managing cyber risk to its essential functions well enough. It is used by operators of essential services and other bodies assessed under the UK's network and information systems regime, and increasingly as a general resilience benchmark. Like most compliance frameworks it never names an operating system, and a search for how it applies to Linux mostly returns results Google itself marks "Missing: Linux." That gap is misleading, because the essential-function systems the CAF cares about very often run on Linux.

The CAF does not ask which technology you run; it asks whether you can demonstrate a set of security outcomes. Several of those outcomes are, in practice, statements about access control — who and what can reach a system, whether that access is authorised, and whether it is managed over time. On a Linux estate that translates directly into the accounts in /etc/passwd, the rules in /etc/sudoers, the keys in every authorized_keys file, and the service accounts running your daemons. So while the CAF is written in the abstract language of outcomes, satisfying it is a concrete exercise on your Linux hosts.

The Four Objectives and Fourteen Principles

The CAF is organised into four high-level objectives, each containing a set of principles — fourteen in total. Objective A, managing security risk, covers governance, risk management, asset management, and supply chain. Objective B, protecting against cyber attack, covers the day-to-day technical and procedural controls. Objective C, detecting cyber security events, covers monitoring and threat hunting. Objective D, minimising the impact of cyber security incidents, covers response and recovery.

Beneath the four objectives sit the fourteen principles. Objective A holds four — governance, risk management, asset management, and supply chain. Objective B holds six — service protection policies and processes, identity and access control, data security, system security, resilient networks and systems, and staff awareness and training. Objective C holds two — security monitoring, and proactive security event discovery. Objective D holds two — response and recovery planning, and lessons learned. Identity and access control is one principle among fourteen, but for a Linux team it is among the most consequential, because it is the one an attacker most wants to defeat.

The defining feature of the CAF is that every principle is written as an outcome, not as a checklist of controls. Each is accompanied by Indicators of Good Practice — the IGPs — that an assessor uses to judge whether the outcome is achieved, partially achieved, or not achieved. This matters for Linux teams: the CAF will not tell you to configure sudo in a particular way. It will ask whether you understand, document, and manage who can obtain privileged access, and expect you to show evidence that you do. The freedom to choose how you meet the outcome comes with the burden of proving that you meet it.

Objective B: Protecting Against Cyber Attack on Linux

Objective B is where access control lives, and specifically its principle B2, Identity and Access Control. In the NCSC's own words, B2 asks that "the organisation understands, documents and manages access to networks and information systems supporting the operation of essential functions," and that "users (or automated functions) that can access data or services are appropriately verified, authenticated and authorised." Read that carefully on a Linux estate and it becomes a demanding requirement.

Understanding and documenting access means having an accurate inventory of every account and credential on your in-scope hosts — not just the named users, but the service accounts, SSH keys, and tokens that hold access. Managing it means least-privilege sudo rather than blanket root, named administrators rather than shared logins, and prompt removal when someone leaves or a system is retired. The phrase "or automated functions" is the part teams miss: the CAF explicitly extends identity and access control to non-human identities, so an orphaned service account or a stale key that still trusts a decommissioned host is a B2 gap, not an afterthought.

Objective B does not stop at B2. Principle B4, system security, expects the hosts themselves to be protected and their configuration controlled — which again turns on who can change them — and B3, data security, depends on the same access decisions. But B2 is the principle a Linux team will spend the most time evidencing, because privileged access is both the control an attacker most wants to subvert and the one an assessor most wants to see managed.

In practice, most B2 findings on Linux come from the same handful of patterns. Root is logged into directly and shared, so no action can be tied to a named person. Sudo rights accumulate in /etc/sudoers.d, sometimes as NOPASSWD rules that grant silent elevation. A service account picks up broad sudo for a one-off migration and never loses it. An SSH key added during setup still grants access long after its owner has left. Each of these is a concrete, evidenced gap against B2's requirement to understand and manage access — and each is invisible to the directory-based review most organisations rely on.

What CAF Version 4.0 Changed

The NCSC released CAF version 4.0 on 4 August 2025, in response to a growing threat to critical national infrastructure. It introduced four notable changes. First, a new section on building a deeper understanding of attacker methods and motivations, so that cyber risk decisions are informed by how adversaries actually operate. Second, a new section on ensuring the software used in essential services is developed and maintained securely. Third, updates to security monitoring and threat hunting to improve detection of cyber threats. Fourth, improved coverage of AI-related cyber risks throughout the framework.

None of these rewrote the identity and access-control outcome, but they raise the bar around it. A deeper focus on attacker methods puts privilege-escalation paths — exactly the sudo misconfigurations and forgotten keys that let an attacker move from a foothold to root — under sharper scrutiny. Stronger monitoring expectations mean you are increasingly asked to detect changes to privileged access, not merely to have documented it once. The practical message of 4.0 for a Linux team is that a static, annual snapshot of access is no longer a convincing answer; the framework now leans towards understanding and detecting how access could be abused. As with any framework version, confirm the current text on ncsc.gov.uk before an assessment, as details are updated over time.

Evidence for a CAF Assessment

Because the CAF is outcome-based, an assessment is an evidence exercise: you demonstrate, against the IGPs, that the outcome is achieved. For B2 on Linux the evidence that carries weight is a demonstrable, current inventory of which people and which automated functions can access each in-scope host and at what privilege, proof that the access is least-privilege and reviewed on a schedule, and proof that access is removed promptly when a person leaves or a service is retired.

It also helps to understand how the CAF is scored, because it shapes what "enough" looks like. An assessor does not simply pass or fail a principle: each indicator of good practice is judged achieved, partially achieved, or not achieved, and the principle's status follows from the pattern across its indicators. Sector assessment schemes then set a target profile — the level an organisation is expected to reach for each principle given how much it matters. The consequence for access control is that partial evidence yields a partial outcome: documenting who should have access counts for little if you cannot show that the live state on the hosts matches the documentation.

The weakest evidence is a spreadsheet assembled the week before the assessment — it is a point-in-time claim that says nothing about how access was managed across the period and quietly omits the NOPASSWD sudo rule and the orphaned key. The strongest evidence is produced continuously: host-level discovery that inventories every account, group, sudo rule, and SSH key, reconciles them against a known-good baseline, and records every change as it happens maps almost word-for-word onto "understands, documents and manages access," and turns an assessor's question into a query you can answer on the spot.

For how CAF access-control evidence sits alongside NIS2, DORA, and the wider compliance picture, see the Linux access controls evidence guide, which walks through the access-control expectations across frameworks for IT teams.

CAF Compared With NIS2

The CAF and NIS2 are often mentioned together and are easy to conflate, but they are different instruments from different jurisdictions. The CAF is a UK framework, published by the NCSC and used to assess organisations under the UK's own network and information systems regime. NIS2 — Directive (EU) 2022/2555 — is European Union law; 17 October 2024 was the deadline for EU member states to transpose it into national legislation, and those national laws have landed on staggered dates since. The United Kingdom, outside the EU, is not subject to NIS2; it runs its own regime, assessed with the CAF, and is separately reforming that regime.

The deeper difference is in style. The CAF is outcome-based and assessment-oriented: it describes what good looks like through principles and IGPs and asks you to evidence the outcome. NIS2, as transposed into each member state's law, tends to impose more prescriptive obligations, with defined risk-management measures, governance duties, and incident-reporting timelines enforced by national authorities. What they share is the centrality of access control: CAF principle B2 and NIS2's cyber-risk-management measures both put identity, authentication, and authorisation at the core. An organisation operating on both sides of the Channel will find that the same Linux access evidence — a live, owned inventory of who and what can reach each host — is what satisfies both, even though the frameworks ask for it in different words.

For a multinational the overlap is more useful than the divergence. Rather than run two separate access-governance programmes, teams find that a single, well-evidenced picture of Linux access — every account and automated function, its privilege, its owner, and its change history — is the raw material both regimes ask for. The CAF consumes it as evidence against B2; a NIS2 national authority consumes it as evidence of the access-control measures its transposed law requires. The framework wording differs; the underlying Linux control does not.

FAQ

Does the NCSC CAF apply to Linux servers?

The CAF does not name any operating system — it asks organisations to demonstrate security outcomes for the systems supporting their essential functions. Those systems very often run on Linux, so the CAF's access-control outcomes, in particular Principle B2, land directly on your Linux accounts, sudo configuration, SSH keys, and service accounts. Meeting the CAF on Linux is a concrete exercise even though the framework is written in the abstract.

Which CAF principle covers identity and access control?

Objective B, "Protecting against cyber attack," contains Principle B2, Identity and Access Control. It expects the organisation to understand, document and manage access to the systems supporting essential functions, and requires that users — or automated functions such as service accounts — that can access data or services are appropriately verified, authenticated and authorised. On Linux that explicitly includes non-human identities like service accounts and SSH keys.

When was CAF 4.0 released and what changed?

The NCSC released CAF version 4.0 on 4 August 2025. It added a new section on understanding attacker methods and motivations, a new section on developing and maintaining software for essential services securely, updates to security monitoring and threat hunting, and improved coverage of AI-related cyber risks throughout the framework. The identity and access-control outcome was not rewritten, but expectations around detecting and understanding privileged-access abuse tightened.

Is the CAF the same as NIS2?

No. The CAF is a UK framework published by the NCSC and used under the UK's own network and information systems regime. NIS2 — Directive (EU) 2022/2555 — is EU law; 17 October 2024 was the member-state transposition deadline, with national laws landing on staggered dates. The UK is not subject to NIS2. Both, however, place identity and access control at the centre, so the same Linux access evidence tends to satisfy each.