Plain English Guide to the April 2026 Cyber Essentials Changes

Cyber Essentials v3.3 took effect for assessment accounts created from 27 April 2026. It makes missing MFA on an in-scope cloud service an automatic fail, makes two critical update questions automatic fails, and adds clearer cloud-service and assessment-scope rules. Existing assessment accounts created earlier retain a six-month completion window under the previous requirements.

The NCSC updated the Cyber Essentials requirements to version 3.3 on 27 April 2026. The assessment uses 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. It is grounded in the NCSC requirements v3.3, IASME's April 2026 update, and the current Danzell question-set preview.

Three things changed:

1. MFA marking became stricter. MFA must be used wherever it is available and cloud-service authentication must always use MFA. Failing to implement available MFA on an in-scope cloud service is now an automatic fail.

2. Critical update marking became stricter. Failure to apply high-risk or critical fixes within 14 days for operating systems, router and firewall firmware, or applications is now an automatic fail.

3. Scope and certificates became clearer. Applicants must describe exclusions and legal entities more precisely, while the requirements add a specific cloud-service definition and remove ambiguity from some network-scope language.

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 an on-demand, scalable service hosted on shared infrastructure, accessed via the internet through an account, and used to store or process organisational 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: AWS, Azure, and Google Cloud Platform, including the administrative accounts and the customer-managed components that fall inside your assessment scope

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.

No. For an in-scope cloud service, the MFA requirement applies to the accounts authenticating to that service, not only its administrators. The wider requirements also say to implement MFA wherever it is available.

In practice:

• 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 in-scope cloud service makes MFA available but the organisation has not implemented it, the assessment fails. Avoid extending that statement into an invented blanket rule for accounts or systems that are not cloud services; assess those against the exact v3.3 wording.

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 can satisfy the Cyber Essentials MFA requirement, but only if the resulting control actually meets the requirement for the in-scope cloud services. Common mistakes include untested exclusions or policies that are merely available rather than enforced.

A straightforward policy:

• "Require MFA for all users and all in-scope cloud apps" provides a clear baseline, subject to correctly controlled and documented technical accounts.

Policies that need careful review:

• MFA only for administrators leaves ordinary users of the cloud service uncovered.
• Location or device exclusions can create a route that does not use MFA.
• Risk-based policies may allow some authentication without MFA.

What to prepare: describe the policy, identify exclusions, and test representative sign-ins. Your certification body decides whether the actual implementation meets the scheme requirements; a policy name by itself is not evidence.

Practical recommendation: keep the policy as broad and simple as the environment permits, and discuss unavoidable technical exceptions with the certification body before submission.

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