Plain English Guide to the April 2026 Cyber Essentials Changes
The NCSC updated the Cyber Essentials requirements to version 3.3 in 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. I assess organisations for Cyber Essentials every day, and these are the issues that come up most often.
What actually changed in April 2026?
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.
Do I automatically fail if I don't have MFA on my free Mailchimp account?
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:
- Mailchimp (free tier) sending company newsletters - In scope. Contains customer email addresses. Needs MFA.
- Canva (free) used to design company marketing materials - In scope if you store company assets there. Needs MFA.
- A personal Gmail account that occasionally receives a forwarded work email - This is where it gets complicated. If it is a personal account and your organisation has no policy directing email there, most assessors would consider it out of scope. But if work email is routinely forwarded to personal accounts, that is a policy issue you need to address regardless.
- Trello (free) used to manage a team project - In scope. Contains organisational project data. Needs MFA.
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.
What is the new definition of "cloud services" in the Danzell question set?
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.
Does the MFA auto-fail apply to admin accounts only, or all users?
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.
Is Conditional Access enough for Cyber Essentials MFA?
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.
Can I put a legacy server on a separate VLAN to exclude it from scope?
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.
How do I define scope for 100% remote workers with no office firewall?
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)
- The home router of each remote worker (as the boundary firewall)
- All cloud services used by the organisation
- All user accounts
The home router question: Under Cyber Essentials, the home router acts as the boundary firewall for each remote worker. You do not need to configure every employee's home router. The requirement is that:
1. The router's admin password has been changed from the default
2. The router's firmware is supported and receiving updates
3. The router's firewall is enabled (it almost always is by default)
In practice: Most modern ISP-provided routers meet these requirements out of the box, provided the admin password has been changed and the firmware is current. The assessor will ask you to confirm that remote workers have been instructed to change default router passwords and keep firmware updated. A written policy or employee guidance document is sufficient evidence.
What you do NOT need:
- You do not need to install enterprise firewalls in employees' homes
- You do not need to VPN all traffic through a central firewall
- You do not need to physically inspect each employee's home router
Do BYOD phones count if they only check email via Outlook Web Access?
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.
What are the most common fails I see as an assessor?
Having assessed hundreds of organisations, these are the issues that cause the most failures under v3.3:
1. MFA not enabled on all cloud service accounts. Usually it is enabled for admins but not standard users. Under v3.3, this is an automatic fail.
2. Unsupported operating systems still in use. Windows 10 reaches end of support in October 2025. If I am assessing your organisation in April 2026 and you are still running Windows 10 without Extended Security Updates (ESU), that is a fail.
3. Patches not applied within 14 days. The 14-day clock starts from the date the vendor publishes the patch, not when your scanner finds it. Many organisations are patching monthly, not within 14 days of release.
4. Default admin passwords on network devices. The ISP-provided router still using "admin/admin" or "admin/password" is the classic example. This applies to switches, access points, and any network device with a management interface.
5. No documented scope. The Danzell question set asks you to define and document your scope. "Everything" is not an acceptable answer. You need to list your in-scope devices, users, and network boundaries.
How Fig Group can help
Fig Group is an IASME-licensed Cyber Essentials certification body. We assess organisations against the v3.3 requirements every day and understand exactly what the Danzell question set requires.
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 £314.99 + VAT. Guaranteed within 6 hours for compliant submissions. Three free reviews included if your submission needs corrections.