User Access Control for Cyber Essentials v3.3: the complete pillar guide

User Access Control for Cyber Essentials v3.3: the complete pillar guide

User Access Control is one of the five technical controls assessed under the Cyber Essentials scheme, and in 2026 it is the pillar that catches the most UK organisations out at assessment. The move to v3.3 sharpened the requirements in several places - particularly around MFA scope, admin-account separation, and third-party access - and the gap between what organisations think they have and what an assessor will actually accept has widened.

This guide covers every v3.3 requirement under the User Access Control pillar, the exact evidence an assessor now expects to see, and the specific configurations that pass or fail at submission.

What the pillar covers

User Access Control under v3.3 addresses the full identity lifecycle across every account that can access in-scope systems, data, and services. It is assessed under five headings:

1. Individual accounts - no shared or generic accounts for real users.

2. Minimum necessary privilege - standard users do not have admin rights; admins have separate admin accounts.

3. Authentication - strong passwords plus MFA, with v3.3 rules on factor type.

4. Joiner-mover-leaver - accounts are created, updated, and removed in line with employment lifecycle.

5. Third-party and service-account control - contractors, MSPs, and service principals are treated as named users, not generic logins.

The pillar sits across every in-scope system: Windows and macOS endpoints, Microsoft 365 / Google Workspace tenants, line-of-business SaaS applications, VPN and remote access, and any server or cloud infrastructure that holds organisational data.

1. Individual accounts

The rule is simple: every real user logs in with their own named account. No shared "admin@" mailbox as a login, no generic reception account, no single credential passed around.

What passes under v3.3:

• Every staff member has a named account on the identity provider (Entra ID, Google Workspace, Okta, or similar).
• Accounts are traceable to a real person (HR record or explicit documented approval).
• Shared-use devices (reception kiosk, shop-floor tablet) have a named account per user, or are tightly scoped to a single documented purpose with MFA.

What fails:

• Shared admin credentials between multiple MSP engineers or internal staff.
• Generic accounts used for day-to-day work ("we all log in as the office account").
• Service accounts used by humans for interactive login instead of automation.

Evidence the assessor asks for:

• User list export from the identity provider, matched against current headcount.
• Confirmation there are no active shared interactive accounts.

2. Minimum necessary privilege (admin separation)

v3.3 formalised what many organisations had been doing informally: any user with admin rights must have two accounts - a standard day-to-day account and a separate admin account - and must use the right one for the right task.

What passes:

• Every admin has a named admin account distinct from their day-to-day account.
• Day accounts have no local admin rights on endpoints.
• Admins use the admin account only for admin tasks (user management, system configuration, IdP changes).
• Service accounts used for automation are marked as non-interactive and protected from interactive sign-in.

What fails:

• One account used for both reading email and performing admin tasks.
• Users with permanent local-admin rights on laptops (except where justified and documented).
• The MSP logs into a shared client admin account.

Evidence:

• Screenshot of Entra ID / Google Admin showing the admin role membership, and that each member holds both a day account and an admin account.
• Policy statement confirming the separation is enforced and audited.

See also: Cyber Essentials v3.3 admin account requirements.

3. Authentication - passwords and MFA under v3.3

This is the area where v3.3 is strictest.

Passwords

• Minimum length 12 characters for standard accounts, 14 for admin accounts.
• No forced periodic rotation unless there is a known compromise (NCSC position for several cycles now).
• Password managers acceptable and encouraged.
• Complexity rules should be replaced with length + compromised-password checks (Have I Been Pwned integration at the IdP, or an equivalent service).

Multi-factor authentication

• Required for all cloud services in scope (Microsoft 365, Google Workspace, identity provider, primary SaaS).
• Required for all remote access to internal systems (VPN, remote desktop).
• Required for all admin accounts, regardless of location.
• SMS is not acceptable for admins under v3.3. App-based authenticator, FIDO2, or Windows Hello for Business is expected.
• SMS remains acceptable for standard users where no stronger factor is practical, but is treated as a weakest-acceptable baseline.

What fails:

• MFA enforced only on admins, not on standard users with cloud access.
• SMS MFA on admin accounts.
• Users able to bypass MFA by logging in from "trusted" networks where the trust-decision is ungoverned.
• Legacy authentication enabled on Microsoft 365.

See the pillar guide: Multi-factor authentication for Cyber Essentials v3.3.

Evidence:

• Conditional Access / equivalent policy export showing MFA requirement per user group.
• Report of users registered for MFA vs licensed users.
• Screenshot confirming legacy authentication is disabled.

4. Joiner-mover-leaver

A user-access control is only as strong as the process that creates and removes accounts. v3.3 expects a documented lifecycle and evidence it runs.

What passes:

• Documented process covering account creation, role change, and termination.
• Leaver process executed within a defined SLA (typical expectation: access revoked same day; accounts deleted or disabled within 30 days).
• Periodic access reviews (at least annually) confirming who has what.
• Evidence that leavers' accounts, licenses, mailbox access, and MFA registrations are revoked.

What fails:

• No documented process.
• Active accounts belonging to people who left the organisation.
• Access not removed when people change role (e.g., former developer retains production access after moving to marketing).

Evidence:

• The written JML process.
• Sample leaver records with dated removal timestamps.
• Most recent access review output.

5. Third-party and service-account control

Contractors, MSPs, and service accounts are one of the highest-risk areas and a frequent source of failed submissions.

What passes:

• Named accounts for every third party with access - no shared MSP admin credentials.
• Service accounts marked as non-interactive, with strong passwords or keys and no MFA bypass.
• Service-principal secrets rotated on a defined cadence and revoked when no longer needed.
• Written contract or onboarding record for each third party with access.

What fails:

• "The MSP logs in as us" using a shared credential.
• Service accounts used for human logins.
• Historical contractors still in the directory.

Evidence:

• Third-party access register.
• Service-principal / service-account inventory, with owner and purpose.

v3.3 edge cases worth noting

Break-glass accounts. v3.3 expects these exist, are sealed, are monitored, and are excluded from Conditional Access policies that could lock them out. Two per tenant is typical. Test at least annually.

Passwordless authentication. v3.3 explicitly allows passwordless (FIDO2, Windows Hello for Business) as a preferred factor. See Cyber Essentials v3.3 and passwordless authentication.

Device unlock credentials. Under v3.3 the local unlock credential on an endpoint is in scope - the laptop PIN, the phone biometric. Minimum length of 6 numeric, or biometric, with a documented lockout policy. See Cyber Essentials v3.3 and device unlock.

Sub-set scoping. Access controls apply to the in-scope environment, not the whole organisation. See Cyber Essentials v3.3 sub-set scoping.

Common reasons User Access Control submissions fail

From assessments processed in the first quarter of v3.3:

1. SMS MFA on admin accounts. Upgrade to authenticator app or FIDO2.

2. No admin separation in small organisations claiming "we only have one admin." Still required - create the second account.

3. Shared MSP credentials. Split into named engineer accounts.

4. Legacy authentication still enabled on Microsoft 365. Disable via Security Defaults or Conditional Access.

5. Leaver accounts still active on secondary SaaS (the identity provider was cleaned up; the standalone SaaS tool was not).

6. Service accounts registered for interactive MFA - mark them non-interactive.

7. Conditional Access trusted-network bypass misconfigured so MFA is skipped from the office.

Evidence checklist for the assessment

Minimum artefacts to have ready before submission:

• [ ] User list export from the identity provider.
• [ ] Admin role membership screenshot with day/admin account separation visible.
• [ ] MFA coverage report (registered vs licensed users).
• [ ] Conditional Access (or equivalent) policy export showing MFA rules.
• [ ] Password policy export (length, complexity, rotation).
• [ ] JML process document.
• [ ] Most recent access review output.
• [ ] Third-party access register.
• [ ] Service-account inventory.
• [ ] Break-glass account documentation.

The fastest path to compliant User Access Control

The organisations that pass User Access Control on the first submission typically do three things in the 48 hours before submitting:

1. Export and sanity-check the user list. Compare against HR headcount. Disable everyone who shouldn't be there.

2. Run a Conditional Access audit. Export every policy, confirm MFA is required for all users on cloud apps and remote access, and confirm legacy authentication is blocked.

3. Document the JML process if it isn't already written down, and attach it to the submission.

A fully prepared submission on this pillar is 30 minutes of work. An unprepared one can cost a week and a failed first submission.

Bottom line

User Access Control under v3.3 comes down to: named accounts, separated privileges, MFA everywhere that matters, documented joiner-mover-leaver, and no shared credentials with third parties. Get those five right and the pillar is a strong part of your submission. The assessment evidence is routine to produce if the underlying controls are in place - and at Fig Group, a clean submission is reviewed and certified within 6 working hours.

Start Cyber Essentials from £299.99 + VAT | MFA pillar guide | Admin accounts guide | All pricing