Cyber Essentials Plus Test 2: the authenticated patch scan

What does Test 2 check?

Test 2 is the technical verification of the 14-day patching rule you declared in A6.4 and A6.5. The assessor runs a credentialed scan on each sampled device, so the scanner sees installed software versions and missing updates rather than only what is visible over the network.

What counts as critical or high risk?

An update counts as critical or high risk if the vendor describes it that way, if it fixes a vulnerability with a CVSS v3 base score of 7 or above, or if the vendor gives no severity details at all.

Three criteria, and meeting any one of them is enough. The third is the one people miss: if the vendor publishes an update without saying what severity it fixes, the scheme treats it as if it were critical, and the 14-day clock runs from release.

Why 14 days, and from when?

The 14 days run from the date the vendor releases the update, and the threshold is set by Requirements for IT Infrastructure v3.3.

The Requirements for IT Infrastructure v3.3 set the threshold: updates that fix critical or high-risk vulnerabilities, CVSS v3 7 or above, or unrated issues must be installed within 14 days of release. The NCSC notes that any longer would be a serious security risk and any shorter may not be practical. The clock starts when the vendor releases the fix, not when you notice it.

Where a vendor bundles several fixes of differing severity into one update, the whole update must be installed within 14 days if any of the issues inside it is critical or high. A monthly cumulative update almost always qualifies.

Automatic updates count, and the requirements say to enable them where possible. What the assessor sees in the scan is the outcome, so a device that has auto-update enabled but has not rebooted for six weeks will still fail.

Why is virtual patching not accepted?

The test specification states that virtual patching is not an acceptable long-term mitigation for legacy unsupported operating systems and is not recognised as a way to comply. The software must be updated, removed or moved out of scope.

Virtual patching means an intrusion prevention system or endpoint agent that blocks exploitation of a known vulnerability without the underlying software being fixed. It is sometimes offered as a way to keep an unsupported operating system in scope.

• An unsupported operating system on a sampled device fails Test 2 regardless of compensating controls, and it contradicts A6.1 and A6.3 on the self-assessment, where unsupported software means the licensed-and-supported requirement is not met.
• The only route for software that must stay is the one in the requirements: move it into a sub-set that prevents all traffic to or from the internet (A6.7), so it is outside the boundary and is not sampled.

What happens if Test 2 fails?

Since April 2026, a failed update management test is remediated and retested on the original sample plus a new random sample. A second failure revokes the verified Cyber Essentials self-assessment certificate.

IASME added this rule in its April 2026 scheme update, under 'Verification of update management compliance', for assessment accounts created after 26 April 2026. It says some organisations had updated only the devices sampled for the audit. The new random sample at retest is there to catch exactly that.

In practice, treat a Test 2 finding as evidence about your update process, not about one device. Push the missing update to every device in scope, confirm compliance from your management console, and only then book the retest. The self-assessment answers to A6.4 and A6.5 cannot be changed once Plus testing has started.

How do you pass Test 2?

Patching is a common cause of first-attempt failures, and it is also the most predictable test case to prepare for.

• Retire or isolate every unsupported operating system and application before the audit. Windows 10, older macOS releases and end-of-life browsers are the usual suspects.
• Run your own authenticated scan with the same class of tool, at least two weeks before the audit, and fix everything rated high or critical.
• Force reboots. Pending updates that are downloaded but not installed still show as missing.
• Check third-party applications, not only the operating system: browsers, PDF readers, Java, Zoom, Teams, office suites and remote-access agents.
• Check servers and IaaS instances the same way. They are in the sample and are often the least frequently rebooted.
• Re-scan two or three days before the audit and keep the report as evidence for A6.4.2 and A6.5.2.

How do assessors check this?