Cyber Essentials Plus Patching Failure Casebook, Six Patterns the Assessor Sees Routinely

Net Sec Group is an IASME and NCSC certification body. Of the 16 recurring CE Plus failure patterns we see across our 800+ assessment history, Security Update Management produces the second-largest share, behind User Access Control. The 14-day rule for high and critical patches is widely known. The shapes of how firms still fail it are less widely catalogued.

This article walks six patching failure cases the assessor encounters routinely. Each case is anonymised. Each case describes the symptom, what the assessor saw on the live vulnerability scan, the underlying technical reason it failed the IASME Cyber Essentials Plus test specification, the fix, and the evidence format that subsequently passed.

If you are about to go through CE Plus, the patterns below are the ones to defuse before the assessor's scan runs. If you have already failed on patching, this is the diagnostic.

What the 14-day rule actually says

The IASME Cyber Essentials Plus test specification requires high and critical patches (CVSS 7.0 and above per the published thresholds, and any patch the vendor labels critical) to be installed within 14 days of vendor release.

The clock starts at vendor release, not at the firm's awareness of the patch. A firm that finds out about a critical CVE a week after release has 7 days, not 14. A firm whose patch-management tool only scans weekly cannot rely on the scan cadence to define the window.

The clock applies to every device in the in-scope estate, not to a sample. The assessor verifies on a sample, but the rule applies to the population.

The clock applies to operating system patches and application patches. It applies to firmware patches when the firmware vendor publishes a patch addressed at a CVE. It applies to third-party software, not just first-party.

These four properties of the rule are what the failure shapes below are responses to. Firms tend to fail when one of these properties is misunderstood.

Case 1: high-severity patch on a sampled device outside the 14-day window

Symptom

The assessor's internal vulnerability scan flags a critical CVSS finding on a sampled Windows device. The patch was released 32 days before the assessment day. The device has not picked it up.

What the assessor saw

The patch was a Windows cumulative update with a known critical CVE. The patch-management tool's last scan on this device was 11 days ago. Between that scan and the assessment day, the device had been online for several full working days, with the user's permission to apply updates set to "automatic during inactive hours". The updates had not run.

The deeper finding: Windows Update on the sampled device was paused, with a deferral set to 14 days. The user did not remember setting the deferral; the deferral had been set programmatically by an unrelated piece of vendor software during install months earlier.

Why it failed

The patch was outside the 14-day window. The deferral was a configuration that the firm did not control or audit. The IASME Cyber Essentials Plus test specification expects the patch to be installed within 14 days regardless of the local update-deferral state.

Fix

Three configurations land together:

  1. Push the missing patch to the failed device immediately
  2. Audit the rest of the estate for the same Windows Update deferral state, remove deferrals that are not deliberate
  3. Tighten the patch-management policy: deferrals that exceed 14 days are blocked at the management layer, not left to local configuration

Evidence that passed

A patch-management tooling export covering every in-scope device, showing each device's Windows Update deferral state is zero days, plus a tenant-wide patch-status report showing the previously-failing patch is installed across the estate.

Case 2: deferred Windows feature update accumulating CVEs

Symptom

The applicant has held back a Windows 11 feature update across the estate for stability reasons. The version of Windows 11 currently in use is two feature updates behind. The IT lead believes this is acceptable because the version still receives monthly security updates.

What the assessor saw

The version still receives monthly security updates, that is true. The version is also approaching end of servicing on the vendor's published lifecycle, six months out from the assessment day. Two CVEs identified in the last 14 days are addressed in the latest feature update but back-ported to the current version with a documented caveat that some configurations remain affected.

Why it failed

The current version is patchable but is on a documented end-of-servicing trajectory. The two CVEs back-ported with caveat fall into the "documented as patched but the back-port may not address all configurations" category. The IASME Cyber Essentials Plus test specification expects the firm to be on a current servicing branch, not on a deferred branch within the patching window.

Fix

Two paths:

  1. Move forward to the current feature update on a phased rollout, prioritising the in-scope estate
  2. If the estate cannot move forward inside the assessment timeline, document the compensating controls and the planned rollout date, and confirm the back-port-with-caveat CVEs are not present on the sampled devices

Path 1 is preferred. Path 2 is acceptable to the assessor for the current engagement only; the firm cannot use Path 2 indefinitely.

Evidence that passed

A patch-management tooling export showing the in-scope estate is on a current Windows 11 feature update with security patching applied.

Case 3: end-of-life operating system on a sampled device

Symptom

The assessor's internal scan identifies a Windows 10 device on the in-scope sample. Windows 10 reached end of life on the date Microsoft published. The firm intended to upgrade the device but missed the deadline.

What the assessor saw

The device was on Windows 10, no Extended Security Updates (ESU) entitlement, no documented out-of-scope status. The user was an in-scope employee with cloud admin rights.

Why it failed

End-of-life operating systems do not receive security updates. They cannot satisfy the 14-day rule. The test specification rejects them.

There is no mitigation that fixes this without either an upgrade, an ESU subscription with documented active patches, or a scope change.

Fix

Three paths:

  1. Upgrade the device to a supported Windows version. Same-day for a fresh install, longer for application compatibility issues
  2. Purchase Extended Security Updates from Microsoft and document the active subscription. Acceptable to the assessor for the duration of the ESU period
  3. Scope the device out of CE Plus, which usually means scoping the user out of the in-scope work

Path 1 is the cleanest fix. Path 2 is a holding pattern. Path 3 is a scoping decision.

Evidence that passed

For Path 1: a patch-status report showing the upgraded version is current. For Path 2: an ESU subscription confirmation and the patch-status report showing ESU patches are installed.

Case 4: end-of-life browser

Symptom

The assessor's scan flags an old version of a major browser (Chrome, Edge, or Firefox) on a sampled device. The version is two major releases behind current and outside the vendor's security-support window.

What the assessor saw

The browser was the user's default for cloud admin work. The browser had auto-update disabled at the platform level.

Why it failed

End-of-life browser versions are a documented attack surface. The test specification treats browsers in scope alongside operating systems and applications.

Fix

Re-enable browser auto-update across the estate via group policy or MDM, push the current version. Ensure the browser is not pinned to a specific version by an unrelated dependency (we have seen browser version pinning to support a legacy SaaS application; the SaaS vendor has to be the one to lift the pin).

Evidence that passed

A patch-status report covering the browser version on every in-scope device, plus the group policy or MDM configuration that enforces auto-update.

Case 5: third-party software (Adobe, Java, browser plug-in) untracked

Symptom

The assessor's scan flags a critical CVSS finding on Adobe Acrobat or a browser plug-in on a sampled device. The IT lead believed third-party software was patched by the vendor's auto-update; the patch-management tool did not cover the third-party software.

What the assessor saw

Adobe was several versions behind the current release. The browser had a plug-in installed that had been published a year earlier and not updated since. Java (in the rare cases where Java is still installed) was on a version with public CVEs.

Why it failed

The 14-day rule applies to third-party software. The patch-management tool's not covering it does not exempt it.

Fix

Two configurations:

  1. Extend the patch-management tool's coverage to include third-party software. Modern Microsoft Intune, Jamf, BigFix, and PDQ Deploy all support this on the standard set of third-party applications
  2. Inventory the third-party software in scope. Remove software that is not actively used. Auto-update the rest. Block the install of new third-party software at the user level

Path 1 closes the technical gap. Path 2 reduces the surface that path 1 has to cover.

Evidence that passed

A patch-management tooling export showing third-party software inventory and patch state per in-scope device, with the failed application updated to the current version.

Case 6: patch-management console says compliant, the device reports otherwise

This is the most counter-intuitive failure shape. It catches well-resourced firms with mature tooling.

Symptom

The applicant submits a patch-management tooling export showing all in-scope devices are compliant. The assessor runs the live vulnerability scan and finds critical CVSS findings on three of the sampled devices.

What the assessor saw

The patch-management tool reported compliance based on its last scan. The last scan was three days ago. Between the scan and the assessment day, three devices had received patches that introduced new CVEs (the patch was a feature update that backed out a previous fix, or a fix that was superseded by a higher-severity issue published in the interim). The tool's compliance state had not refreshed.

The deeper finding: the tool defined "compliant" as "all patches as of the last scan applied". The assessor's live scan defined "compliant" as "no high or critical CVSS finding right now". Those are different definitions, and on three devices they disagreed.

Why it failed

The test specification's expectation aligns with the live scan, not the tool's last-scan compliance state. A device with a critical CVE present right now fails, even if the patch-management tool says compliant.

Fix

Two configurations:

  1. Tighten the patch-management tool's scan cadence on in-scope devices. Daily scans on the day of the assessment is acceptable
  2. Run a live vulnerability scan before the assessment to validate the tool's compliance claim. We routinely run a pre-assessment vulnerability scan as part of CE Plus engagement preparation

The tool is not wrong; the tool is reporting what it last knew. The fix is to keep what it knows current.

Evidence that passed

A live vulnerability scan output from inside the 24 hours before the re-test, showing no high or critical CVSS findings on the in-scope estate, plus the tightened scan-cadence configuration.

Patterns the cases share

Across the six cases, three patterns repeat:

  1. The patch is missed because the firm's patching apparatus has a deferral, a coverage gap, or a stale view that the firm did not realise was in effect
  2. The patch is missed because the software is end of life and the firm has not handled the lifecycle event in time
  3. The patch is missed because a third-party piece of software is not in the patch-management tool's scope

The fix shape repeats too. A patch-management tool with full estate coverage, full third-party coverage, daily scans during the assessment week, and a live pre-assessment vulnerability scan covers Cases 1 through 6 collectively. End of life events still need a separate planning track, but the technical patching failures cluster around tool coverage and tool currency.

Pre-assessment patching checklist

If you are 48 hours out from CE Plus, run through this checklist against your in-scope estate:

  1. Is the patch-management tool's coverage complete: every in-scope device enrolled and reporting?
  2. Is the tool's third-party coverage active: Adobe, Java if in use, browser plug-ins, and any other third-party software in scope?
  3. Has the tool's last scan run in the last 24 hours, on every in-scope device?
  4. Are any devices on a deferred Windows feature update or a deferred macOS major release? Document the deferral or remove it
  5. Are any devices on an end-of-life operating system? Path 1 (upgrade), Path 2 (ESU), or Path 3 (scope out) decided
  6. Are all browsers on a current major version with auto-update enforced?
  7. Has a live pre-assessment vulnerability scan run inside the last 24 hours, returning no high or critical findings?
  8. Are the compensating controls for any unpatchable system documented and in effect?

For the broader pre-assessment evidence checklist that includes patching and the other four controls, see The evidence the CE Plus assessor accepts on this site. For the full set of CE Plus failure patterns across all five controls, see The most common CE Plus failures by control. For the formal re-attempt rules if you have failed and need to re-test, see The CE Plus second-attempt rules.

Common questions

The CVE is published with a CVSS 7.5 score by the vendor but the NIST National Vulnerability Database scores it 9.0. Which score does the assessor use?

In our practice, where vendor and NIST National Vulnerability Database scores disagree on the same CVE, we treat the higher authoritative score as governing for the 14-day window. The intent of the test specification is to ensure high and critical issues are addressed, not to give firms a route to argue down a CVE score.

What if the vendor releases a patch but it breaks production?

The IASME Cyber Essentials Plus test specification allows compensating controls during the patching window. Document the compensating control, document the planned rollout once the vendor publishes a fix to the breaking change, and demonstrate the compensating control is in effect on the live screen-share. The 14-day rule is intended to protect against unpatched CVEs, not to force the firm to ship a regression.

Do firmware patches count?

Yes when the firmware vendor publishes a patch addressed at a CVE. Network kit, server BMC firmware, laptop EFI firmware, mobile device firmware are all in scope. The 14-day window applies.

Does the rule apply to cloud-hosted servers in scope?

Yes. A managed virtual machine the firm operates inside its cloud account is in scope and the 14-day rule applies. A cloud-managed service where the cloud provider patches the underlying infrastructure (Lambda, App Service, managed database) is the cloud provider's responsibility for the underlying patch, but any application code and runtime versions the firm controls are in scope.

What is the "compliant in console, non-compliant on device" pattern called formally?

We have not seen the IASME or NCSC documentation give it a formal name. We refer to it as "stale-compliance state" in our internal triage notes. The fix is the live pre-assessment vulnerability scan; the underlying issue is scan-cadence vs assessment-day cadence.

Next steps

For the deeper netsecgroup.io references:

When you are ready to book or want a pre-assessment vulnerability scan against your own estate before booking, contact Net Sec Group or book a Cyber Essentials Plus assessment directly.