Most Cyber Essentials Plus programmes do not fail on the audit day. They fail about six weeks earlier, at the moment somebody decides the scope is "basically the corporate estate" and moves on to the next agenda item. Everything after that is the cost of that decision being discovered slowly.
The scheme changed materially in April 2026, and a good deal of the advice still circulating was written for the version before it. If you are running a remediation programme this year, the gap between the two is the difference between certifying and paying twice. This piece covers the pathway at a level a steering group can follow, then goes down into the test mechanics, then sets out the failure patterns I keep seeing.
The pathway, at the level a steering group needs
Cyber Essentials is the UK government scheme, owned by the NCSC and delivered through IASME as its partner. It has two tiers and they are frequently confused, including by people sponsoring the work.
Cyber Essentials is a verified self-assessment. You answer a question set on the IASME portal, a director or board-level representative signs a declaration, and an assessor marks the answers. Nobody visits, nobody scans. It is an assertion that is checked for coherence.
Cyber Essentials Plus is the audited tier. It does not add new controls. It takes the same five controls you already asserted and has a qualified assessor verify them technically against a sample of your real estate. This distinction matters more than any other single fact in this article, because it tells you what remediation is for. You are not building new controls to satisfy Plus. You are closing the distance between what the self-assessment claims and what the estate actually does.
The sequence is fixed. You certify at Cyber Essentials first, then the Plus technical audit must be completed within three months of the base certificate. If you have achieved the verified self-assessment less than three months before certifying to Plus, you do not need to repeat the self-assessment stage. Let that window lapse and the base certificate is no longer usable for Plus purposes, so you recertify before you can proceed. Both can be run as a single coordinated process, and on a remediation programme they usually should be.
What changed in April 2026
This is the part that invalidates older guidance. Cyber Essentials Danzell is the 2026 version of the question set, in force from 27 April 2026, replacing Willow and aligning with version 3.3 of the NCSC Requirements for IT Infrastructure. Willow itself only arrived in April 2025, so any organisation certifying annually is now on its second consecutive change of question set.
There is a transition path, and it is worth checking which side of it you are on. Organisations already working towards Willow have a grace period until 27 October 2026 to complete the Cyber Essentials application, and those also pursuing Plus get an additional three months, until 27 January 2027, to finish the Plus assessment. If your client opened an assessment account before the cutover, you may have a decision to make about which set to certify under. If they have not, the question is settled: it is Danzell.
Four changes carry real programme risk.
Auto-fail rules now exist. From 26 April 2026, no multi-factor authentication on a cloud service that offers it, or high-risk security updates applied slower than 14 days, fails the assessment outright regardless of everything else. Previously these were serious findings among other findings. Now they are terminal on their own, which changes how you sequence remediation. Anything touching MFA or patch latency goes first, not into the general backlog.
Cloud services cannot be scoped out. Cloud services now have a formal definition and can never be excluded from scope. The definition covers on-demand, scalable services accessible over the internet using shared infrastructure, and any cloud service used to store or process business data must be in scope. Every SaaS platform the business quietly adopted is now in the assessment, whether IT knows about it or not.
You can no longer fix the paperwork after the audit. Organisations are not permitted to amend their verified self-assessment answers based on the outcome of the Plus assessment, so self-assessments must be complete and accurate before the technical audit stage. The old informal pattern, where the audit surfaced a discrepancy and the answer was quietly restated, is closed. If the self-assessment says something the estate does not do, that is now a finding rather than an edit.
Sampling became adversarial. This is the change that catches experienced teams. Audits previously tested a defined sample, so organisations could focus remediation on the sample set and leave the rest of the estate untouched. Assessors can now randomly re-sample during remediation to verify fixes have been applied across the organisation rather than only on the devices originally tested. The consequence is specific and harsh: if an organisation fails an initial sampled device, the assessor tests an additional random device before remediation is permitted. If that additional device also fails, the organisation can fail Plus immediately, and this may also result in the loss of their existing Cyber Essentials certification.
The technical detail that decides the outcome
Scoping, which is the whole programme in disguise
Scope determines sample size, sample size determines audit duration, and audit duration determines cost and the odds of a random device embarrassing you. Treat scoping as an architectural decision made once, deliberately, with the assessor's methodology in mind.
Under Danzell the room to be vague has closed. The scope must be clearly defined, justified and based on network boundaries. All internet-connected organisational devices must be included unless their exclusion is explicitly justified, and cloud services that store or process business data, including SaaS platforms, are no longer eligible for exclusion. Exclusions now need genuine technical justification such as physical network segregation, not an assertion that a subnet is "out of scope for this exercise".
The practical consequence for a remediation lead is that you need a real inventory before you need anything else. Not the CMDB as maintained, the CMDB as verified. On every engagement I have seen, the delta between those two is where the programme's actual work lives.
Sampling, and why build sprawl is a budget line
Cyber Essentials Plus does not test everything. The audit covers a representative set of user devices, all internet gateways and all servers with services accessible to unauthenticated internet users, with the assessor testing a suitable random sample, typically around ten per cent, then deciding whether further testing is required.
The mechanic that surprises people is that sampling is applied per operating system build, not across the organisation as a whole. The IASME sampling methodology selects a representative sample from each build group, on the reasoning that if every device in a group is configured identically then testing a sample gives confidence about the rest. Servers are the exception and are tested in full, with no sampling applied. Fifty Windows 11 devices on one build might yield a sample of four, while ten macOS devices add a further three from their own group.
This gives you a lever most programmes never pull. Every additional build is another sample group, another set of tests, more assessor hours. Standardising devices and operating systems as far as possible is a direct method of reducing sample size, and therefore the time and cost of each assessment. If the estate carries four Windows builds because nobody retired the old images, consolidating them before the audit is cheaper than testing them. That is an argument you can take to a CIO in financial terms rather than security ones.
Bring your own device does not escape this. The sampling table applies to BYOD the same way it applies to corporate hardware, with the practical wrinkle that personal devices fragment into more build groups because the organisation does not control the operating system version.
The five test cases
The methodology derives from the NCSC and IASME test specification, which is published and which you should read in full before advising anyone. In outline:
External vulnerability assessment. An unauthenticated scan of internet-facing infrastructure, looking at what is exposed and whether an internet-based attacker could realistically exploit it. This is where forgotten public services surface, and it is worth running yourself early because the findings are often organisational rather than technical.
Authenticated vulnerability scan. A sample of end-user devices is scanned with credentialed access, enumerating installed software, missing patches and configuration weaknesses, with high or critical vulnerabilities counting as a fail. This is the test that most commonly catches organisations out, because it surfaces unpatched browser plug-ins, outdated PDF readers and older versions of office software that slip through informal patching processes. The threshold is specific: the assessment must not identify vulnerabilities rated CVSSv3 7.0 or above within the selected sample. And the timing rule is equally specific: where a patch has been available for more than 14 days prior to testing, the sub-test records a fail.
One detail worth carrying into design conversations: virtual patching is not accepted as a long-term mitigation for the vulnerabilities of legacy unsupported operating systems, and will not be recognised as a mechanism for compliance. If somebody is planning to put a WAF or an IPS signature in front of an unsupported system and call it handled, that conversation is better had in week one than in the audit.
Malware protection on end user devices. Every in-scope device must run anti-malware software, application allow-listing, or operate in a sandboxed environment such as a managed mobile device profile. Mobile devices are included, and jailbreak or root detection may be checked.
Malware delivered by email. The assessor sends a series of test files, a mix of harmless EICAR samples and password-protected archives containing inert payloads, to a user mailbox. The expectation is that the email gateway, the mail client and the endpoint engine combine to block or quarantine each one, and any file that reaches the inbox and can be executed counts as a fail. Critically, this test must be undertaken on a standard non-administrative account.
Malware delivered through a browser. The assessor attempts to access pseudo-malware files through all browsers installed on the device, and a pass requires that the files cannot be opened. The word doing the work is "all".
MFA, where the auto-fail lives
MFA moved from important to terminal, so it deserves separate treatment. The assessor verifies MFA on all declared services where it is available, ideally evidenced through a global configuration that makes MFA mandatory for all users, or through single sign-on with MFA enforced. Where that cannot be shown centrally, MFA is verified for sampled users and administrators across all relevant services.
Two specifics catch people. First, location-based controls, including IP allow-listing, are no longer recognised as a compliant form of MFA. Any conditional access policy that trusts an office IP range in place of a second factor is now a finding, and given the auto-fail rule, potentially a terminal one. Second, the requirement extends to administration portals, not just the user-facing service. Tenant admin consoles, billing portals and vendor support portals all count.
On the positive side, passkeys are recognised, with FIDO2 authenticators regarded as MFA because user authentication is performed. If a client is already moving to passwordless, that work counts.
| Control area | What gets verified | Common failure |
|---|---|---|
| Firewalls and gateways | External scan, rule review | Forgotten public service, default admin interface exposed |
| Secure configuration | Device build, account separation | Admin rights on daily-driver accounts |
| Security update management | Authenticated scan, 14 day rule | Third-party software outside the patch pipeline |
| User access control | Account review, MFA enforcement | Service accounts and admin portals without MFA |
| Malware protection | EICAR by email and browser | Second browser nobody remembered was installed |
The gotchas, in the order they usually bite
Scope agreed too late, or agreed verbally. If scope is still moving when remediation starts, you are remediating a moving target and your gap analysis has a shelf life measured in days. Fix scope in writing, with the assessor, before any remediation ticket is raised.
Build sprawl nobody costed. Four Windows images, two macOS versions and a Linux estate is six sample groups. Nobody notices until the assessor's quote arrives or the audit runs into a second day.
Third-party software outside the patch pipeline. The endpoint patching tool covers the operating system beautifully and does nothing about the PDF reader, the Java runtime, the old VPN client or the browser extension. This is the single most common authenticated-scan failure, and it is entirely predictable in advance.
Unsupported software still in scope. You cannot attain Cyber Essentials at all if you are using unsupported software within scope. Not a finding, a blocker. Every programme needs an early sweep for end-of-life operating systems and applications, with a decision per item: upgrade, remove, or remove from scope through genuine segregation.
MFA that exists but is not enforced. Available and enabled are different words. A tenant where MFA is configured but a conditional access exclusion group has thirty people in it will fail, and now fail terminally.
The email test run on the wrong account. An administrative account may behave differently from a standard one. The test is specified against a standard non-administrative account, and if your dry run used an admin mailbox, you have tested the wrong thing.
The forgotten second browser. Edge is fine because it is managed. Nobody remembered the Chrome installation from two years ago, or Firefox on the developer builds. The test covers every browser present.
Remediating the sample rather than the estate. This used to work. It now actively triggers the failure mode, because the retest deliberately includes a fresh random device drawn from the wider population.
Burning the three month window on remediation. The window is not remediation time. It is audit scheduling time. If you certify at base level and then start a twelve week remediation programme, you will be recertifying.
Assuming last year's answers still apply. Danzell replaced Willow, which had replaced Montpellier the year before. Responses that passed under the previous set may not meet the current criteria, and reusing them is now a meaningful risk rather than a time saver.
Running it as a programme, not an assessment
The difference between an advisory engagement and a delivery one is that the second is judged on whether the certificate arrives. A few things follow from that.
Sequence by auto-fail first. MFA coverage and patch latency are now terminal on their own. They go to the front of the plan regardless of how the risk register scores them, because everything else is irrelevant if either is unresolved on the day.
Run a dry run of the actual tests. Not a policy review. Run an authenticated scan against a real sample, send EICAR files to a standard mailbox, fetch test files through every browser on the build. The tooling is not exotic and the test specification is public. A programme that has not rehearsed the tests is guessing, and the second-sample rule makes guessing expensive.
Do not book the audit until the dry run passes. This is the single highest-value piece of programme discipline available, and it is usually the one under most pressure, because a booked date makes a steering group feel progress is happening. A booked date that arrives early converts a recoverable position into a failed audit and possibly a lost base certificate.
Treat build consolidation as a cost saving. It shortens the audit, reduces the sample, and lowers the chance of a random device failing. It is also the one recommendation in this whole area that infrastructure teams tend to welcome, because they wanted to retire those images anyway.
Own the inventory, and keep owning it. Point-in-time compliance means the estate has to be right on the day and demonstrably right afterwards, since the declaration now explicitly acknowledges an ongoing responsibility to maintain the controls. A programme that certifies and dissolves leaves the client worse off at renewal than they were at the start.
The honest summary
Cyber Essentials Plus is not technically difficult. Every control in it is something a competent infrastructure team already believes it does. What makes certification hard is that the audit measures the gap between belief and evidence, and the 2026 changes have removed most of the ways that gap used to be papered over. No amending answers afterwards. No excluding the awkward cloud service. No fixing the sample and hoping. No treating MFA and patch latency as things to get to.
For a remediation programme, that reframes the work. The deliverable is not a set of recommendations. It is a verified inventory, a scope somebody has signed, an auto-fail sweep completed first, a rehearsed set of tests, and an audit date chosen because the evidence supports it rather than because the quarter is ending. Get those five right and the certificate is a formality. Get the scope wrong in week one and you will be paying for the audit twice.
If you are working through a Cyber Essentials Plus programme and want a second opinion on scope or readiness, that is the kind of work I do through Cyber Spartans.