Cyber Essentials is the UK government-backed baseline for cyber security. The NCSC describes it as the minimum standard it recommends for organisations of all sizes, and a growing number of buyers, including central government, ask suppliers to hold it. The scheme was updated in April 2026: the NCSC published Cyber Essentials: Requirements for IT Infrastructure v3.3, and IASME, the NCSC's Cyber Essentials delivery partner, replaced the Willow question set with a new one called Danzell.
This guide covers what the scheme asks for, what changed under Danzell, the difference between Cyber Essentials and Cyber Essentials Plus, how certification works, and why the October 2026 PHP2Shell vulnerabilities are a good test of whether your patching process would pass.
The five technical controls
The v3.3 requirements are organised under the same five control themes as earlier versions:
| Control | What it requires in practice |
|---|---|
| Firewalls | Every in-scope device sits behind a correctly configured firewall (boundary or software). Default admin passwords changed, admin interfaces not exposed to the internet without MFA or an IP allow list, unauthenticated inbound connections blocked by default, inbound rules documented and approved. |
| Secure Configuration | Remove unnecessary accounts and software, change default passwords, disable auto-run, authenticate users before access, and lock devices (no more than 10 guesses in 5 minutes, or lock after 10 failed attempts). |
| Security Update Management | All software licensed and supported, unsupported software removed, automatic updates on where possible, and critical or high-risk fixes applied within 14 days of release. |
| User Access Control | A process to create and approve accounts, unique credentials, prompt removal of leavers, separate admin accounts, and MFA wherever available. Authentication to cloud services must always use MFA. |
| Malware Protection | Anti-malware that is kept updated, blocks malware and malicious websites, or application allow-listing through code signing and an approved app list. |
Scope is where many first attempts go wrong. Under v3.3, a scope that excludes end-user devices is not acceptable, bring-your-own devices that access organisational data or services are in scope, and the requirements now state plainly that cloud services cannot be excluded from scope. IaaS (such as Amazon EC2), PaaS and SaaS (such as Microsoft 365 or Google Workspace) all count, and the Danzell question set adds that business social media accounts are cloud services too.
What changed in April 2026: v3.3 and Danzell
The v3.3 requirements document lists its own changes: a formal definition of a cloud service, an updated passwordless authentication definition that includes FIDO2 (passkeys count as MFA), the explicit statement that cloud services cannot be excluded, a reference to the Software Security Code of Practice for software development, removal of the old wording about 'untrusted connections' from the scope criteria, and more emphasis on backups. Backups are still not a technical requirement, but the NCSC now strongly recommends them.
The Danzell question set applies to new assessments from 27 April 2026; IASME directs anyone who purchased before that date to the Willow questions. The booklet IASME currently publishes is version 16.3, dated May 2026. You still answer on IASME's online platform; the booklet is for preparation.
The change that matters most in practice is how the questions are marked. Comparing the Willow (v15.1) and Danzell (v16.3) booklets, Danzell adds explicit automatic-fail notes to several questions:
- A6.4 and A6.5: high-risk or critical updates for operating systems, router and firewall firmware, and applications not installed within 14 days. A 'no' is an automatic fail.
- A7.15: listing a cloud service as having no MFA option when it actually has one is an automatic fail.
- A7.16 and A7.17: MFA not applied to all administrators, or to all users, of your cloud services means the assessment fails.
Danzell also says that if a cloud service has no MFA of its own but can be linked to another service that provides it (for example single sign-on through Microsoft 365 or Google Workspace), that link must be configured.
The 14-day rule, precisely
The 14-day period itself did not change in v3.3; what changed is that failing it is now spelled out as an automatic fail. The requirement is that all software on in-scope devices is updated, including vulnerability fixes, within 14 days of release where:
- the vendor describes the fixed vulnerabilities as 'critical' or 'high risk', or
- the vulnerabilities have a CVSS v3 base score of 7 or above, or
- the vendor gives no details of the severity of what the update fixes.
If a single update bundles fixes of mixed severity and any of them is critical or high risk, the whole update falls under the 14-day rule. 'Software' is defined broadly: operating systems, applications, extensions, interpreters, scripts, libraries, network software and firmware. Feature updates and optional updates are not required. Software that is out of vendor support must be removed, or isolated in a sub-set that blocks all traffic to and from the internet. A 'supported' product can come from a vendor other than the original author, as long as that vendor can produce fixes and publishes the date support ends.
A live example: PHP2Shell
On 21 October 2026 the PHP project released fixes for CVE-2026-109618 and CVE-2026-109619, a pair of critical, unauthenticated remote code execution flaws now known as PHP2Shell. Both are rated 9.2 under CVSS v4.0 and affect any PHP SAPI that serves HTTP. The fixed releases are 8.2.35, 8.3.36, 8.4.27 and 8.5.12. The NCSC urged organisations to patch immediately. The details are in PHP2Shell explained.
PHP is an interpreter, so it is in scope wherever it runs on an in-scope server or cloud instance. For a certified organisation using upstream PHP, the deadline is 4 November 2026, 14 days after the 21 October release. In practice:
- If you install PHP from a Linux distribution or a commercial support vendor, that vendor's update is the one you apply, and it may keep the old upstream version number. Check the vendor's security advisory, not just
php -v. - PHP 7.4, 8.0 and 8.1 get no official upstream release. They only count as supported if a vendor (a distribution or LTS provider) is committed to shipping fixes for them, and you must apply that fix within 14 days.
- PHP 7.3 and older, including PHP 5, are affected with no fix. They are unsupported software under Cyber Essentials and must be removed or isolated, whatever happens with PHP2Shell. See options for end-of-life PHP.
- Configuration workarounds reduce exposure while you schedule the update, but they are not a substitute for the update the 14-day rule requires.
If you can't answer 'which servers run PHP, which version, and who supports it' within an hour, that's a gap in asset management. The NCSC doesn't make asset management a separate control, but the requirements note that it helps with all five.
Cyber Essentials vs Cyber Essentials Plus
| Cyber Essentials | Cyber Essentials Plus | |
|---|---|---|
| Requirements | The five controls in v3.3 | The same five controls |
| How it is assessed | Verified self-assessment, signed off by a board member or equivalent, then marked by an assessor | Self-assessment plus a technical audit (on site or remote) |
| What gets tested | Your answers | External scan of every public IP, plus a representative sample of devices checked for supported and patched software, working malware protection, account separation and MFA on cloud services |
| Timing | Renewed annually | Audit must be completed within 3 months of your Cyber Essentials certification; non-compliances must be fixed within 30 days |
On fees, IASME publishes Cyber Essentials prices by organisation size: £320 + VAT for micro (0 to 9 employees), £440 + VAT for small (10 to 49), £500 + VAT for medium (50 to 249) and £600 + VAT for large (250+), according to IASME's FAQ at the time of writing. Cyber Essentials Plus is quoted by the Certification Body based on the size and complexity of your network. Check IASME's site for current prices before budgeting.
UK-domiciled organisations with turnover under £20 million that certify their whole organisation can opt into the free cyber liability insurance arranged through IASME. Opting in adds a few questions but doesn't change the price.
Who needs it
Procurement Policy Note PPN 014, in effect from 24 February 2025 and replacing PPN 09/14 and PPN 09/23, applies to central government departments, their executive agencies, non-departmental public bodies and NHS bodies. Where a contract involves citizens' personal information, government staff personal information such as payroll, ICT systems that store or process OFFICIAL data, or information about government business and finances, suppliers must show Cyber Essentials or Cyber Essentials Plus (or equivalent controls) before award, and renew annually for the life of the contract. Outside government, many larger companies and insurers ask for it in supplier due diligence.
How certification works
- Define scope. Whole organisation is simplest and gives the most assurance. A sub-set needs a real network boundary (a router or firewall, not a host firewall) and a justification.
- Prepare. Download the Danzell question booklet, and try the NCSC's Cyber Essentials Readiness Tool. Eligible SMEs can also get a free 30-minute consultation with an NCSC-assured Cyber Advisor.
- Close the gaps. Typical gaps: MFA missing on one SaaS tool, an old server or NAS, admin accounts used for email, firewall rules nobody can explain, or patching that relies on someone remembering.
- Submit. Either self-led through IASME's platform, or supported by an IASME-licensed Certification Body. A board-level person (or owner) must sign off the answers, and the person named as responsible for IT must be a member of your organisation, not someone employed by your outsourced provider.
- Stay compliant. The 14-day rule applies all year, not just on assessment day. Book CE Plus within 3 months if you need it.
Where readiness work helps
Most of the effort goes into evidence: knowing every device, cloud service, account and piece of software in scope, then proving MFA and patch status for each. That's the part where automated inventory and scanning save the most time (see automating security checks with AI agents). For AWS-hosted workloads, the AWS security baseline checklist covers root MFA, IAM and patching. If you also handle personal data, read UK GDPR security obligations for SMEs; the ICO itself calls Cyber Essentials a good starting point.
HashTech helps UK organisations prepare for Cyber Essentials and fix the gaps before they apply to a licensed Certification Body; see our UK services.
