What Is the CAF and Who Must Use It?
The NCSC Cyber Assessment Framework (CAF) is a set of 14 objectives organised into four groups — Managing Security Risk (A), Protecting Against Cyber Attack (B), Detecting Cyber Security Events (C), and Minimising the Impact of Cyber Security Incidents (D). Each objective contains a set of Indicators of Good Practice (IGPs) — specific, assessable behaviours that demonstrate the objective is being met.
The CAF is the assurance standard for operators of essential services (OES) under the Network and Information Systems (NIS) Regulations 2018 — the UK's implementation of the EU NIS Directive. Competent authorities in each sector use CAF to assess whether operators have appropriate and proportionate security measures in place. Sectors include:
- Energy — electricity generation, transmission, distribution; gas transmission and distribution; oil transmission
- Transport — aviation, maritime, rail, road
- Health — NHS England, NHS trusts, certain independent providers
- Water — water supply and sewerage undertakers
- Digital infrastructure — internet exchange points, DNS providers, TLD registries
- Finance — systemically important financial market infrastructure
- Government — central government departments assessed against CAF by the NCSC
Beyond the NIS Regulations, the CAF is used by local authorities, emergency services, and public sector organisations as a voluntary framework. It is also referenced in government procurement and grant conditions for technology suppliers to CNI sectors.
CAF as a Maturity Framework
The CAF is explicitly a maturity framework, not a pass/fail standard. Each IGP is assessed as Achieved, Partially Achieved, or Not Achieved. Organisations are not expected to achieve all IGPs immediately. The framework is designed to provide a structured improvement path. However, assessors and competent authorities will escalate concerns where fundamental IGPs — particularly in Objective B2 — remain persistently unachieved without a credible improvement programme.
Objective B2: Identity and Access Control — The Structure
CAF Objective B2 is titled Identity and Access Control. Its stated purpose is: "Understanding, controlling and managing access to the system and data that the system stores or processes." It contains four contributing outcomes, each with their own set of IGPs:
B2.a — Identity Verification, Authentication and Authorisation
This outcome covers whether the organisation has verified that users (human and non-human) are who they claim to be before granting access, and whether access is authorised appropriately. The IGPs include:
- User identities are uniquely identified and authenticated. Shared accounts are not used for network access.
- Multi-factor authentication is used for all access to the network from outside the organisation's premises (remote access).
- MFA is used for administrator access to all systems and services — including cloud management planes, directory services, and privileged management interfaces.
- Authentication credentials are protected — passwords meet minimum complexity requirements, credential stores are protected from offline attack, and credentials are not shared or stored insecurely.
- Authorisation is granted based on a defined access control policy, following the principle of least privilege.
B2.b — Device Management
This outcome covers whether devices used to access the network are known and managed. IGPs include maintaining an inventory of authorised devices, enforcing device authentication policies, and controlling the use of removable media and personally-owned devices. While device-focused, it intersects directly with identity: a known-managed device with an authenticated identity is the combination required for the most stringent access policies.
B2.c — Privileged Account Management
This is the most detailed outcome in B2 and the area where the majority of assessment gaps are found. IGPs explicitly include:
- Privileged accounts are inventoried and their use is controlled. The organisation knows who holds admin rights on every system in scope.
- Privileged access is restricted to defined, named individuals with a legitimate business need. Generic or shared admin accounts are not acceptable.
- Privileged accounts are used only for administrative purposes — they are not used for web browsing, email, or general user activities.
- Administrative access is performed from dedicated privileged access workstations (PAWs) or equivalent isolated access mechanisms.
- Just-in-time access is implemented where technically feasible — privilege is granted temporarily and revoked after use.
- Privileged account activity is logged and the logs are reviewed. Anomalous privileged activity generates alerts.
- Service accounts holding privileged rights are documented, and their privilege is scoped to minimum necessary. Passwords are managed — not static and long-lived.
B2.d — Identity and Access Management
This outcome covers the broader lifecycle of identities — joiners, movers, and leavers processes; access reviews; and the management of access rights over time. IGPs include:
- Processes exist to provision and deprovision access as people join, change roles, or leave. Leavers' accounts are disabled promptly — ideally on the day of departure.
- Access is reviewed periodically — typically annually at minimum, more frequently for privileged access. Review outcomes are documented.
- Stale accounts — accounts that have not been used for a defined period — are identified and disabled or removed.
- The access control policy is documented, communicated to system owners, and enforced.
What Assessors Look For: Evidence That Works
CAF assessments are carried out through a combination of document review, workshops, and technical sampling. Understanding what assessors actually test guides preparation effectively.
Documentation Assessors Expect
- Privileged access policy. A documented policy defining what constitutes a privileged account, who may hold one, how they are managed, and what controls apply. Not a generic IT policy — specific to privileged accounts and their lifecycle.
- Privileged account register. A current inventory of all privileged accounts across all in-scope systems — domain admin, local admin on servers, cloud IAM administrator roles, database administrator accounts, network device management accounts. Each account mapped to a named individual owner and a business justification.
- Access review records. Evidence that access reviews have been conducted — dates, scope, who reviewed, what was found, what was changed as a result. A review that resulted in no changes raises questions; the assessment process should show the rigour applied.
- Joiner/mover/leaver process documentation. Evidence of how access is managed through identity lifecycle changes. This should include sample records of recent offboarding actions.
- MFA implementation evidence. Configuration screenshots or policy exports showing MFA is enforced (not just enabled) for remote access and admin access. For Microsoft environments, Conditional Access policy exports are the standard evidence format.
Technical Evidence That Supports Assessment
Assessors increasingly expect technical evidence to back up documentary claims. Claims that MFA is enforced are tested by reviewing the enforcement policy in the identity provider. Claims that privileged access is minimised are tested by sampling the actual group memberships of privileged accounts. Claims that stale accounts are removed are tested by querying the directory for accounts inactive beyond the stated threshold.
The most convincing B2 evidence packs contain:
- Exported AD/Entra ID reports of all accounts with Domain Admin, Global Admin, or equivalent privileged roles — with last logon dates and account types
- Conditional Access policy exports or screenshots showing enforced MFA for admin access and remote access
- A stale account report showing accounts inactive beyond 90 days, with a record of what action was taken
- Service account inventory with privilege levels, password age, and managed account type (gMSA vs. standard)
- Evidence of JIT controls for cloud admin roles (PIM eligible assignment configuration exports)
- PAW deployment confirmation — which systems require PAW access and evidence of the PAW build standard
- Privileged access log review records — showing that privileged session logs are generated and reviewed
Common B2 Findings in CAF Assessments
The identity-related findings that appear most frequently in CAF assessments — and that result in Partially Achieved or Not Achieved ratings — are consistent across sectors.
No Formal Privileged Account Register
Organisations frequently cannot produce a current inventory of privileged accounts. IT teams know about the accounts they created, but not about accounts created by predecessors, vendors, or application installations. Without a register, the organisation cannot demonstrate control over who holds privileged access — which is the foundational requirement of B2.c.
MFA Not Enforced for Admin Access
Many organisations have MFA deployed for standard user remote access but have not extended enforcement to administrative accounts accessing management interfaces, server consoles, or cloud management planes. The IGP requires MFA for all administrator access — not just remote access — and enforcement (not just availability) is required.
Service Accounts with Persistent High Privilege
Domain Admin service accounts, or service accounts with local admin on large server sets, appear consistently as B2.c findings. The combination of persistent high privilege, static long-lived passwords, and no MFA makes these accounts the highest-risk identities in the environment — and they are explicitly called out in the CAF IGPs.
Access Reviews Not Conducted or Not Documented
Access reviews may be conducted informally — a manager confirms their team's access is appropriate. Without documentation — who reviewed what, when, what action was taken — this cannot be evidenced to an assessor. B2.d requires documented, systematic access reviews, not ad-hoc conversations.
No JIT for Privileged Access
While the CAF acknowledges JIT is aspirational for some organisations, the B2.c IGP that references JIT is now expected to be at least Partially Achieved for organisations that have cloud presence with PIM available, or for those assessed in the energy, health, or government sectors where regulator expectations have hardened. "We are aware of JIT and are planning implementation" is a Partially Achieved position. "We have not considered JIT" is Not Achieved.
B2 in the Context of NIS2 and DORA
For UK organisations with EU operations, or for financial entities subject to DORA, CAF B2 alignment provides a foundation but not a ceiling. NIS2 and DORA both require more comprehensive privileged access management programmes than the CAF minimum.
Where CAF B2 Achieves NIS2 Alignment
The B2 IGPs for identity verification, MFA enforcement, and privileged account management broadly satisfy NIS2 Article 21(2)(j) minimum requirements on access control. An organisation assessed as Achieved across B2 with documented evidence would be in a strong position on NIS2 identity controls. The gap is in the operational aspects NIS2 expects — continuous monitoring, automated detection of access anomalies, and documented incident response for identity-related events — which are addressed in CAF Objectives C1 and D.
Where DORA Goes Further
DORA's privileged access management requirements in Article 9 are more prescriptive than the CAF. DORA expects financial entities to have operational PAM tooling, audit logs for all privileged sessions (not just administrative activity), and JIT access implemented rather than planned. Organisations that achieve CAF B2.c should treat it as the baseline for DORA — DORA will require additional programme investment on top.
Preparing for a CAF B2 Assessment: A Practical Sequence
The following sequence covers the activities needed to move from an undocumented current state to an assessment-ready B2 position.
Step 1: Enumerate the Current Identity Landscape
Begin with a full inventory — all user accounts, all privileged accounts, all service accounts, and all cloud roles. This cannot be done from memory or from documentation alone. The source of truth is the directory: Active Directory, Entra ID, AWS IAM, GCP IAM, and any other identity stores in scope. An automated assessment tool produces this inventory faster and with higher accuracy than manual querying.
Step 2: Gap Analysis Against Each IGP
Map the inventory findings against each B2.a–B2.d IGP. For each indicator, determine: is this currently Achieved, Partially Achieved, or Not Achieved? Document the evidence for each achieved indicator. Document the gap for each partial or not achieved indicator.
Step 3: Remediate Critical Gaps
Prioritise the gaps by severity. Not Achieved indicators for foundational requirements — shared admin accounts, no MFA for admin access, Domain Admin service accounts — should be remediated before the assessment where possible. Partially Achieved indicators can be presented with a credible improvement plan.
Step 4: Build the Evidence Pack
Assemble the documentation and technical evidence that supports each achieved indicator. This should be current — evidence from 18 months ago does not demonstrate current control effectiveness. The evidence pack is what the assessor reviews; its completeness and currency directly affect assessment outcomes.
Step 5: Define Improvement Plans for Partial Indicators
For indicators that remain Partially Achieved, document a credible improvement plan: what will be done, by when, by whom, and how it will be evidenced. Assessors recognise that organisations cannot achieve all indicators simultaneously. A structured improvement programme with realistic timelines and named owners is more credible than aspirational claims.
CAF B2 Evidence Pack Production
IdentityFirstMRI produces the technical evidence the CAF B2 assessment requires: privileged account inventory, MFA enforcement verification, stale account identification, service account risk profile, JIT readiness assessment, and gap analysis mapped to each B2 IGP. The output is audit-grade documentation suitable for direct submission to a competent authority.
View Compliance & Audit Service