Plain English Guide to the April 2026 Cyber Essentials Changes

Cyber Essentials v3.3, in force from 28 April 2026, adds stricter password requirements (12-character minimum), explicit firmware patching, phishing-resistant MFA for administrators, and clearer cloud-service scoping rules. Every UK organisation certifying or recertifying on or after 28 April 2026 is assessed against v3.3. Most existing-scheme organisations need minor changes.

The NCSC updated the Cyber Essentials requirements to version 3.3 on 28 April 2026. The assessment uses a new question set (known informally as the "Danzell" question set) and introduces changes that have caused genuine confusion among IT managers, MSPs, and business owners preparing for certification.

This guide answers the specific questions people are actually asking and the issues that come up most often during Cyber Essentials preparation.

Three things changed:

1. MFA is now mandatory for all user accounts that access organisational data or services. Previously it was only required for administrator accounts and cloud services. Now it applies to every user.

2. The definition of "cloud services" has been broadened. The question set now explicitly includes SaaS platforms, web-based email, cloud storage, and any service accessed via a browser or app where the provider hosts the data.

3. The question set itself has been restructured. The Danzell question set groups questions differently and asks for more specific evidence in some areas, particularly around patch management timelines and access control policies.

The five control categories have not changed. Firewalls, secure configuration, security update management, user access control, and malware protection still form the core of the assessment.

This is the single most common question I get asked, and the answer requires some nuance.

If the account is used for organisational purposes and handles organisational data, it is in scope. A free Mailchimp account that sends your company newsletter contains customer email addresses. That is organisational data. The account is in scope and needs MFA.

However, the question is really about what counts as an "organisational cloud service" under the new definitions. The test is straightforward: does the service store, process, or provide access to any data belonging to your organisation or your customers? If yes, it is in scope regardless of whether the service is free or paid.

Practical examples:

The auto-fail: If an in-scope cloud service does not have MFA enabled on all user accounts, the submission will fail. There is no partial credit. The assessor cannot exercise discretion on this point - it is a binary pass/fail control under v3.3.

What to do: Audit every cloud service your organisation uses. If it holds any organisational data, enable MFA. If the service does not support MFA at all, you need to either find an alternative that does, or demonstrate that the service genuinely holds no organisational data and is therefore out of scope.

The previous question set was ambiguous about what qualified as a cloud service. The Danzell set is more explicit.

Under v3.3, a cloud service is any externally hosted service that your organisation uses to store, process, or access data. This includes:

• SaaS platforms: Microsoft 365, Google Workspace, Salesforce, HubSpot, Xero, QuickBooks Online, Slack, Teams, Zoom
• Cloud storage: OneDrive, Google Drive, Dropbox, SharePoint Online, iCloud (if used for work)
• Web-based email: Outlook.com, Gmail (organisational), any webmail
• Line-of-business applications hosted externally: CRM systems, project management tools, HR platforms, accounting software
• Infrastructure services (if you manage them): AWS, Azure, Google Cloud Platform - but only the management console access, not the infrastructure itself (that is your customer's scope if you are an MSP)

What is NOT a cloud service under this definition:

• Websites you visit but do not log into
• Services where you have no account and store no data
• Consumer services used purely personally with no organisational data (your personal Netflix account)

The key test remains: does your organisation store or access its own data through this service? If yes, it is a cloud service in scope for Cyber Essentials, and all user accounts need MFA.

All users. This is the biggest change in v3.3 and the one that catches most organisations out.

Under the previous requirements, MFA was mandatory for:

• Administrator accounts
• Accounts accessing cloud services

Under v3.3, MFA is mandatory for every account that accesses organisational data or services. That includes standard users, not just administrators.

In practice, this means:

• Every Microsoft 365 user needs MFA, not just Global Admins
• Every Google Workspace user needs MFA, not just Super Admins
• Every user of your CRM, project management tool, or cloud accounting software needs MFA

The auto-fail specifically: If an assessor identifies any in-scope user account without MFA during the assessment, the submission fails. This is not scored on a percentage basis. One account without MFA means the entire User Access Control section fails.

For organisations with Conditional Access policies (Azure AD / Entra ID), see the next section.

Yes, if it is configured correctly. This is one of the most misunderstood areas.

Conditional Access in Microsoft Entra ID (formerly Azure AD) can satisfy the Cyber Essentials MFA requirement, but only if the policy actually enforces MFA for all users in all relevant scenarios. Common mistakes:

Policies that will pass:

• "Require MFA for all users, all cloud apps, all locations" - This is the cleanest configuration and will always pass.
• "Require MFA for all users, all cloud apps, except from compliant devices on the corporate network" - This can pass if the compliant device requirement itself constitutes a second factor (the device is enrolled, managed, and the user had to authenticate to enrol it).

Policies that will fail:

• "Require MFA only when users are off the corporate network" - This does not satisfy v3.3 because users on the corporate network are not using MFA. The requirement is for MFA on all accounts, not just remote access.
• "Require MFA for admin accounts only" - This was acceptable under older requirements but fails under v3.3.
• "Require MFA for risky sign-ins only" - Risk-based policies alone do not satisfy the requirement. The requirement is unconditional MFA, not conditional MFA based on risk scoring.

What the assessor checks: The assessor will ask you to describe your MFA implementation. If you say "Conditional Access," they will ask about the specific policy configuration. You should be prepared to show that every user, in every location, is subject to MFA or an equivalent control.

My recommendation: If you are using Conditional Access, set the policy to require MFA for all users and all cloud apps with no location exceptions. You can exclude specific break-glass accounts (emergency access accounts without MFA), but these must be documented and monitored.

Yes, but the segregation has to be genuine and documented.

This is a common approach for organisations running legacy systems that cannot meet the patching or configuration requirements. The v3.3 requirements allow you to remove devices from scope if they are "segregated from the network such that they cannot access organisational data or services and are not accessible from other in-scope devices."

What "genuine segregation" means in practice:

• The legacy server is on a separate VLAN with no routing to the main network
• Firewall rules prevent any traffic between the legacy VLAN and the in-scope network
• Users on the in-scope network cannot access the legacy server, and vice versa
• The segregation is documented in your network diagram

What will NOT pass:

• Putting the server on a different subnet but still allowing it to communicate with in-scope devices
• Having a "segregated" server that users still RDP into from their in-scope workstations
• Claiming segregation verbally without supporting evidence in the network diagram

The assessor will ask: "Is there any network path between this device and your in-scope systems?" If the answer involves the words "but we only use it for..." then the segregation is probably not sufficient.

This is increasingly common and the v3.3 requirements handle it clearly.

If your organisation has no physical office and all employees work remotely, the scope is:

• Every device used to access organisational data (laptops, phones, tablets)
• All cloud services used by the organisation (M365, Google Workspace, business SaaS, IaaS, PaaS)
• All user accounts

The home router question: Under v3.3 (Danzell A2.5), normal home routers used by remote workers are explicitly out of scope. The relevant Danzell wording is: "Details of routers and firewalls in the home environment must not be included." The boundary instead follows the device that touches organisational data, and the device's software firewall handles enforcement against the home network.

What this means in practice:

1. The work laptop's software firewall (Windows Firewall, macOS firewall, or Linux iptables/nftables) must be enabled, default-deny on inbound, and configured so a standard user cannot disable it.

2. Reliance on the software firewall must be noted in the A2.5 network-equipment field of the questionnaire. The wording does not need to be elaborate; "Home and remote workers rely on the device's software firewall as the boundary; no home routers in scope" is enough.

3. Where the organisation supplies and manages a router for a home worker (i.e., issues the router as corporate kit rather than relying on the worker's own home router), that router IS corporate equipment and is in scope.

What you do NOT need:

• You do not need to audit employees' home routers
• You do not need to mandate anything about their home ISP or router
• You do not need to enrol home routers in any inventory or management system

It depends on whether organisational data is stored on the device.

If an employee uses their personal phone to check work email via Outlook Web Access (OWA) in a browser, and no organisational data is downloaded, cached, or stored on the device, the device itself can be considered out of scope.

However, if the employee has the Outlook mobile app installed with work email configured, the device is in scope because organisational data (emails, contacts, calendar) is being synced and stored on the device.

The practical test:

• Browser-only access, no app, no data stored - Device out of scope, but the user account accessing OWA still needs MFA
• Outlook app installed with work email - Device in scope. Must meet all device requirements (OS updates, screen lock, etc.)
• Any MDM-enrolled device - In scope by definition

This is an area where organisations often get caught out. The safest approach is to implement a mobile device management (MDM) policy that either enrolls BYOD devices (bringing them into scope with managed controls) or blocks access from unmanaged devices entirely.

Across Cyber Essentials assessments, these are the issues that commonly cause failures under v3.3:

Fig Group is an IASME-licensed Cyber Essentials certification body. The service is built around the v3.3 requirements and the Danzell question set, with structured feedback when a submission needs correction.

If you are unsure whether your organisation is ready for certification under the new requirements, use our free readiness checker to assess your position across all five controls before purchasing your certification.

Cyber Essentials certification from £299.99 + VAT. Guaranteed within 6 hours for compliant submissions. Three free reviews included if your submission needs corrections.

Check your readiness for free | View pricing