The 5 Cyber Essentials Controls Explained

The NCSC's incident data shows the same patterns repeating: attackers get in through unpatched vulnerabilities, default credentials, over-permissioned accounts, and absent malware protection. The five controls are the minimum set of barriers that block these routes. They're not a gold standard: they're the floor.

The scheme itself has moved through two named versions in recent years. Willow was in force from January 2022, initially requiring MFA only on administrative accounts for cloud services. From 24 April 2023, that requirement widened to cover every cloud-based user account, not just admins, and it’s this fuller mandate that still catches organisations out today: MFA is required on all accounts that can authenticate to internet-facing services, not a subset. From 26 April 2026, Cyber Essentials moved to its current scheme version, Danzell, which is what 2026 assessments are certified against. The MFA mandate carries forward unchanged from Willow into Danzell, but organisations still working from older Willow-era guidance documents should check this requirement first, since it remains the change most likely to require remediation work, and should confirm they’re assessing against current Danzell documentation rather than anything pre-dating April 2026.

Each control below covers what it requires, why it was included, the specific CE requirements, a worked example of how the control plays out on real infrastructure, and what assessors actually probe for when they review it. For a ready-to-use implementation checklist, see our step-by-step certification checklist.

What It Requires:

CE requires a firewall at the network boundary (between your internal network and the internet) and personal firewalls on all devices used outside a protected network environment. The requirement is for a default-deny policy: all inbound connections not explicitly required must be blocked.

Why It Exists:

Unprotected internet-facing services are among the most common attacker entry points. Services with no firewall or permissive inbound rules are exposed to automated scanning and exploitation within hours of going online. Personal firewalls matter because devices on home broadband or public Wi-Fi face the same threats as any internet-facing service.

Specific Requirements:

1. A firewall or equivalent network device at every boundary between the organisation’s internal network(s) and the internet.

2. Default administrative passwords on firewalls changed to a strong, unique password, or administrative access disabled from the internet entirely.

3. Inbound firewall rules approved and documented by an authorised person, with a business justification recorded for each.

4. Unapproved inbound firewall rules removed or disabled once they’re no longer needed.

5. Internet-facing services protected by a further layer of security, such as authentication, before they grant access to sensitive data.

6. Personal firewalls (or equivalent host-based controls) configured and enabled on all laptops and mobile devices used outside a controlled network environment, applying the same default-deny approach as the boundary firewall.

In Practice:

Consider a sales rep working from a laptop that tethers to a personal mobile hotspot at a client site. The corporate boundary firewall is irrelevant here; the device isn’t behind it. What matters is whether the laptop’s personal firewall is enabled and enforcing default-deny on its own, and whether the corporate VPN is set to connect automatically before any other network traffic is permitted. If the VPN is optional or user-initiated, there’s a window where the device sits on an unmanaged network with only its host firewall for protection. Assessors treat this scenario as entirely normal for a modern, hybrid workforce, but it needs to be accounted for in scope: every device that leaves the office network, not just the ones plugged into a desk, needs its own enforced firewall configuration.

Assessor’s Perspective: 

An assessor reviewing this control asks to see the actual firewall rule set, not a policy document describing what the rules should be. They’ll check whether each inbound rule has a documented business reason and an owner, and they’ll test whether the firewall’s admin interface is reachable from the internet at all, since that’s a five-minute check with an immediate fail if it’s exposed with weak or default credentials.

Common failure point:

Firewall rules that permit inbound connections more broadly than necessary, often left over from a previous project and never cleaned up. Firewall management interfaces accessible from the internet with default or weak credentials are also a frequent issue.

What It Requires:

Devices and software must be configured to reduce inherent vulnerabilities and provide only the services required for business operation. This means removing or disabling unnecessary accounts and functionality, and replacing default settings with organisation-controlled ones.

Why It Exists:

Devices ship configured for ease of setup, not security. Default accounts, default passwords, and unnecessary services left enabled all widen the attack surface without adding any business value. Attackers routinely scan for exactly these defaults because they’re so common.

Specific Requirements::

1. Unnecessary user accounts removed or disabled, including guest accounts and any accounts no longer in use.

2. Default or guessable passwords changed on all devices and software before deployment.

3. Auto-run and autoplay features disabled so software cannot execute automatically from removable media or network locations.

4. A password policy enforced: either MFA combined with a minimum 8-character password, or a minimum 12-character password with no other complexity rules, alongside brute-force protection such as account lockout or throttling.

5. Unnecessary or unused software, services, and functionality removed or disabled to reduce the attack surface.

6. Devices and software configured according to manufacturer or developer security guidance, with end-of-life software removed, replaced, or brought back into manufacturer support before assessment.

In Practice:

A common real-world example: a developer spins up a new Azure VM for a proof of concept and leaves it running with the default Network Security Group rules, which permit broader inbound access than the workload needs. Nobody revisits it once the project quietly becomes production. A second, equally common example sits in the office rather than the cloud: a network printer or multifunction device installed years ago, still running its default admin password, connected to the same network as everything else. Neither device looks risky day to day. Both are exactly the kind of unmanaged, default-configured asset that secure configuration exists to catch.

Assessor’s Perspective:

Assessors probe secure configuration by sampling devices outside the obvious core estate: printers, network switches, any device provisioned outside the standard build process. They’ll ask how new devices, including cloud instances, get hardened before going live, and whether that process is consistent or dependent on whoever happened to set the device up.

Common failure point:

Default credentials on network devices, printers, switches, and IoT-category hardware that fell outside the standard device build process. End-of-life software is the other frequent issue, particularly where a specific application or plugin has been kept running because replacing it is inconvenient.

What It Requires:

Access to accounts and systems must be controlled through a proper approval process, limited to what’s needed for each user’s role, and protected by multi-factor authentication where the account can be reached from the internet.

Why It Exists:

Over-permissioned accounts and weak authentication give attackers a much larger blast radius once they compromise a single set of credentials. Restricting access to what’s needed, and requiring a second authentication factor, contains the damage a single stolen password can do.

Specific Requirements:

1. A formal process for granting access to accounts and administrative privileges, requiring approval and a documented business justification.

2. Unique accounts for every user; shared logins are not permitted.

3. Administrative accounts used only for legitimate administrative tasks, with a separate standard account used for day-to-day activities such as email and browsing.

4. Regular reviews of user accounts and access privileges, with access removed or adjusted promptly for leavers and role changes.

5. Multi-factor authentication enforced on all accounts, mandatory for administrators and for any account, including cloud services, that can be accessed directly from the internet.

6. Strong, unique passwords or equivalent authentication in place for every account, following the same password policy set out under secure configuration.

In Practice:

MFA gaps rarely show up where you’d expect. A typical case: a Google Workspace tenancy has MFA enforced correctly on the main web login, and it looks compliant on paper. But some users, often in finance or a legacy team, still connect via IMAP or POP for a third-party tool or an old mail client, and that connection method doesn’t support the same MFA challenge. The account is technically protected, and technically not. The same pattern shows up with legacy API connections, service accounts, and old SharePoint or file-sync clients that predate the MFA rollout.

Assessor’s Perspective:

Assessors don’t just ask whether MFA is “enabled” at a tenancy level; they ask which authentication protocols are still permitted and whether any of them bypass the MFA challenge. They’ll also test whether administrative accounts are genuinely separate from day-to-day user accounts, or whether the same login does both jobs.

Common failure point:

MFA not enforced on cloud applications, particularly Microsoft 365 and Google Workspace, or enforced on the primary login but not on legacy protocols still in use. Shared administrative accounts are also a frequent finding, usually inherited from a smaller team structure that never got revisited as the organisation grew.

What It Requires:

Every in-scope device must be protected against malware, either through anti-malware software or through application allowlisting (also called application control), which permits only approved software to run.

Why It Exists:

Malware remains one of the most common ways attackers achieve persistence and move laterally once inside a network. Anti-malware software catches known and behavioural threats; allowlisting takes the more restrictive approach of only permitting what’s explicitly approved, which is stronger but less flexible.

Specific Requirements:

1. Anti-malware software installed and kept up to date on all in-scope devices, configured to scan files automatically on access and to scan web pages when accessed via a browser.

2. Anti-malware software configured to prevent users from disabling it or downgrading its protection level.

3. Where application allowlisting is used instead, only approved applications, approved application stores, and code signed by a trusted certificate are permitted to execute, with the approved list actively maintained and reviewed.

4. Where application sandboxing is used, code executing within the sandbox is prevented from accessing other files, devices, networks, and sensitive data without explicit user permission.

5. All in-scope devices covered, including newly provisioned devices, before they are connected to the network.

In Practice:

The two approaches suit different teams for genuine operational reasons, not just preference. Finance department PCs are a natural fit for allowlisting: the set of applications each person needs is small, predictable, and rarely changes, so locking execution down to an approved list adds little friction and closes off a lot of risk. A development team is the opposite case: developers routinely need to run new packages, scripts, and tools, and a strict allowlist would slow them down constantly or get bypassed informally. Traditional anti-malware, kept current and actively monitored, is usually the more realistic control for that population. What CE doesn’t accept is a mixed estate where nobody has actually decided which devices use which approach.

Assessor’s Perspective:

Assessors check that the choice between anti-malware and allowlisting has actually been made deliberately for each device population, rather than defaulting by accident. Where allowlisting is in use, they’ll ask to see how the approved list is maintained and who signs off additions.

Common failure point:

Anti-malware installed but not actively maintained, particularly on devices outside the main managed estate. Devices added to scope after the initial deployment and never enrolled in either anti-malware or allowlisting are also a frequent finding, usually new starters’ laptops or replacement hardware issued outside the standard build process.

What It Requires:

All software on in-scope devices must be kept up to date, licensed, and supported by its vendor. High and critical severity patches must be applied within 14 days of release, and unsupported software must be removed or isolated.

Why It Exists:

Unpatched software is the most exploited weakness in real attacks, because the vulnerability and the fix are both public knowledge the moment a patch ships. The 14-day window reflects how quickly attackers weaponise known CVEs once they’re disclosed.

Specific Requirements:

1. All software on in-scope devices kept up to date, licensed, and supported by the vendor.

2. Unsupported, end-of-life software removed from in-scope devices, or isolated from the internet if it must remain in use for operational reasons.

3. High and critical severity patches applied within 14 days of release.

4. Automatic updates enabled wherever available, or a managed patching process in place that achieves the same outcome within the same timeframe.

5. An accurate, current inventory of software and firmware maintained across all in-scope devices, so patch status can actually be tracked and verified rather than assumed.

In Practice:

The pattern Matt Davies describes above shows up in a very specific, recognisable shape. Windows Server Update Services (WSUS) is running properly, and every device shows as fully patched at the OS level, which is genuinely reassuring to look at in a dashboard. But Chrome, Adobe Reader, and a legacy accounting plugin that a handful of finance staff rely on are all running versions that are months, sometimes over a year, out of date. None of these are managed by WSUS, because WSUS only patches Microsoft’s own products by default. Nobody owns third-party patching as a distinct responsibility, so it doesn’t happen until an assessor asks for a full software inventory and cross-references version numbers against release dates.

Assessor’s Perspective:

Assessors will ask for the current version number of every piece of software in scope and check it directly against the vendor’s published release history, not against an internal patch log. They’re specifically looking for the gap between what an organisation says its patch cycle is and what individual applications actually show.

Common failure point:

OS updates running reliably while third-party applications sit months behind, because nothing outside the operating system is being tracked systematically. End-of-life software is the other recurring issue, usually kept in place because the replacement project is complex, costly, or simply hasn’t been prioritised.

1. All five controls apply across every in-scope device; there is no partial pass.
2. The 14-day patching window applies to all in-scope software, not just the operating system.
3. MFA is mandatory for administrators and for any account reachable from the internet, including cloud services.
4. Any end-of-life software found on an in-scope device is an automatic fail unless removed, replaced, or isolated.
5. Malware protection can be met through anti-malware software or application allowlisting; the choice should match how each device population is actually used.
6. Willow, the previous scheme version, ran from January 2022 to April 2026. MFA for cloud admin accounts was required from January 2022, widening to all cloud-based accounts from 24 April 2023. Danzell, the current scheme version, has been in force since 26 April 2026 and is what 2026 assessments are certified against.