Cyber Essentials: what the scan has to pass

Cyber Essentials is usually described as a five-control scheme, which makes it sound like a policy exercise. The self-assessment mostly is. Cyber Essentials Plus is not: an assessor runs an external vulnerability scan against your internet-facing addresses, and the outcome turns on findings you either fixed in time or did not. That is the part teams discover late.

The two certifications are not the same test

Cyber Essentials is a self-assessment questionnaire, verified by a certification body, covering five technical controls: firewalls, secure configuration, security update management, user access control and malware protection. You answer the questions and someone marks them. What each control requires is set out in the Cyber Essentials requirements guide.

Cyber Essentials Plus is a hands-on technical audit of the same five controls, carried out within three months of passing the self-assessment. It adds an external vulnerability scan of the in-scope internet-facing IP addresses, an authenticated scan of a sample of user devices, and practical tests of how email and browsers handle malicious files. Both certificates last twelve months, so this is an annual event, not a one-off.

The self-assessment asks whether you patch promptly. Plus checks.

The fourteen-day rule, and where it stops applying

The update-management control requires that updates are applied within fourteen days of release when the vendor calls the fix critical or high risk, when it fixes a vulnerability with a CVSS v3 base score of 7 or above, or when the vendor gives no severity detail at all. Under the v3.3 requirements that apply from April 2026, failing either patching question in the self-assessment is an automatic fail of the whole assessment.

The external scan in Cyber Essentials Plus is stricter than that. The NCSC test specification runs every internet-facing service through a flowchart, and its first question is simply whether the service has a vulnerability scoring 7.0 or more. If it does, that service fails. There is no fourteen-day allowance at this step. The fourteen-day window only appears in the separate authenticated scan of sampled devices, where a 7.0+ vulnerability fails once its fix has been available for more than fourteen days.

A scanner can still misread a service, for example a patched server that reports an old version number. So treat any tool's "likely fail", ours included, as something to check and fix before the assessment, not as the assessor's verdict.

The same flowchart fails a reachable service that needs no login (unless it only serves public, read-only content), one still using default passwords, and one that neither throttles login attempts nor locks users out after ten failures. Two or more authentication factors pass a service outright.

	Cyber Essentials	Cyber Essentials Plus
Method	Self-assessment questionnaire	Technical audit by an assessor
External vulnerability scan	No	Yes, on in-scope public IPs
Device sampling	No	Yes, authenticated
Fails on	Answers that don't meet the controls, including the auto-fail patching and cloud MFA questions	Any internet-facing service with a 7.0+ vulnerability; on sampled devices, a 7.0+ with a fix older than 14 days
Valid for	12 months	12 months

Sources: the NCSC's Requirements for IT Infrastructure v3.3 (April 2026), the Cyber Essentials Plus Test Specification v3.2 (April 2025, the latest published test specification we could find when we checked in October 2026), and IASME's summary of the April 2026 changes. The scheme is revised periodically. Where this page and the current documents disagree, the documents are right.

Two other conditions sink certifications quietly. Unsupported software (an operating system or application past its end of support) has to be removed from scope or segregated from the internet, because it cannot receive the updates the control requires. And any service reachable from the internet needs a documented business need behind its firewall rule; "it has been open since 2019" is not one. That second condition overlaps almost exactly with the ports that should never face the internet.

Why teams fail on the day

The common failure is a gap between the scope someone declared and the addresses that actually answer. Scope for Cyber Essentials is the whole organisation by default, or a clearly separated sub-part; the assessor scans what is in it. A staging box, an old marketing subdomain, an appliance someone stood up for a project: if it resolves inside the declared scope, it is scanned, and it is judged exactly as production is.

The second failure is timing. The assessment happens on a fixed date. On the external scan, a 7.0+ vulnerability on that date is a fail whether it was disclosed last year or last week. If the first time anybody looks at the external attack surface is the week the assessor books in, there is no remediation window left to use. The fix is a scanning cadence, the same problem behind why annual pentests miss drift.

Running your own scan first

Nothing stops you scanning the same addresses the assessor will, on your own schedule, and working the CVSS 7.0-and-above list down to zero before the audit date. That is the entire preparation: know which addresses are in scope, know what answers on them, know how long each finding has been open.

CyberSpec scans external assets on a schedule, attaches CVSS scores and vectors plus CVE and CWE references to each finding, and tracks first-seen and last-seen dates across repeated scans, so how long each finding has been open is a value you can read rather than reconstruct from old reports. On paid plans, the readiness view reads those findings against the five controls and the external scan flowchart: likely fail, review, no issues found, or no scan yet. It never says pass, and it is not the assessor's verdict; the two controls a scan cannot see (user access control and malware protection) are left for you to attest. See the Cyber Essentials overview.

Book the audit second. Scan first, and give yourself more than fourteen days between the two.