Insights › Guide

The Cyber Essentials 14-day patching rule, explained

What the rule actually says, when the clock starts, what falls in scope, and how to meet it without an audit-week scramble.

Patch management is one of the five technical controls at the heart of Cyber Essentials, and it is the one that trips up the most organisations. The requirement is often summarised as "the 14-day rule", but the detail matters: what counts, when the clock starts, and what happens if you miss it all changed for the stricter in the April 2026 update. This guide sets out the rule in plain terms for UK IT teams and service providers.

14 days
to apply high-risk & critical updates
CVSS ≥ 7.0
or vendor-rated "high"/"critical"
Vendor release
when the clock starts
Auto-fail
if the window is missed

What the rule actually says

Cyber Essentials requires that high-risk and critical security updates are applied within 14 days of a fix being released. In the self-assessment this is captured by the patch-management questions (A6.4 and A6.5), which ask whether critical and high-risk updates are applied within 14 days to operating systems and firmware, and to all software respectively. A "No" to either is enough to fail the whole assessment.

What counts as "high-risk" or "critical"

An update falls inside the 14-day window if any of the following is true:

  • the vendor describes it as "critical" or "high risk"; or
  • it has a CVSS v3 base score of 7.0 or above; or
  • the vendor has not published a severity rating at all.

That last point catches a lot of people out. If a vendor ships a security fix with no severity attached, the safe assumption is that it is in scope. Updates rated "low" or "medium" by the vendor and scoring below 7.0 are not caught by the 14-day deadline, though you should still apply them in good time.

When the 14-day clock starts

The clock starts on the vendor's release date - the day the patch becomes publicly available - not the day you learn about it, and not the day it lands in your management console. If a fix was released ten days ago and you only just imported it into Configuration Manager, you already have four days left, not fourteen.

This is why "we patch monthly on the second Tuesday" is no longer a defensible policy on its own. A vulnerability disclosed the day after your patch window can sit unremediated for nearly a month - well outside the 14 days - unless you have an out-of-band process for high and critical fixes.

What's in scope

The requirement applies across the whole assessment boundary:

  • Operating systems on servers, desktops, laptops and mobile devices;
  • Firmware, where the vendor issues security updates for it;
  • All software - browsers, productivity suites, line-of-business applications, plugins and runtimes;
  • Cloud services, which from April 2026 are formally defined and can no longer be excluded from the assessment.

Third-party applications are frequently the weak spot. Everyone patches Windows; far fewer have an equally reliable process for the dozens of non-Microsoft products that make up a real estate, each with its own release cadence.

Why it is harder than it looks

Meeting the 14-day rule on paper is simple. Proving it continuously, across every device and every application, is where the effort lives:

  • Visibility. You cannot patch what you cannot see. Unmanaged or under-reported devices are the usual reason an estate quietly drifts out of compliance.
  • Third-party breadth. Intune and Configuration Manager patch Microsoft products well out of the box; third-party apps need extra tooling or manual packaging.
  • The clock, not the calendar. Compliance is measured against each vendor's release date, so you need to track releases as they happen, not on a fixed monthly rhythm.
  • Evidence. An assessor - and the April 2026 retest mechanics - will want proof that the fix reached every in-scope device, not just the sample.

How to meet it reliably

  • Maintain a live inventory of every device and application in scope, so nothing falls through the gaps.
  • Track vulnerabilities against vendor release dates, and prioritise anything rated high, critical, unrated, or listed in CISA's Known Exploited Vulnerabilities (KEV) catalogue.
  • Run an out-of-band lane for high and critical fixes rather than waiting for the monthly window.
  • Automate deployment to Intune or Configuration Manager, including third-party applications, so the fix reaches the whole estate inside the window.
  • Keep the evidence - patch status per device over time - so you can demonstrate compliance on demand rather than reconstructing it under audit pressure.

Note: This guide is a practical summary, not a substitute for the official Cyber Essentials Requirements for IT Infrastructure published by IASME and the NCSC. Always check the current version of the requirements for the definitive wording that applies to your assessment.

Frequently asked questions

How long do you have to patch under Cyber Essentials?

Fourteen days from the vendor releasing the fix, for any update that is high-risk or critical.

Does the 14 days start when I find out about the update?

No. It starts on the vendor's public release date, regardless of when you become aware of it or when it reaches your patching tool.

What if the vendor gives no severity rating?

Treat it as in scope and apply it within 14 days. Unrated security updates are caught by the rule.

What happens if I miss the deadline on one device?

Since the April 2026 update, an in-scope update left unpatched beyond 14 days is an automatic failure - the earlier tolerance for a couple of patching gaps has been removed.

Sources: IASME - Cyber Essentials, the official Cyber Essentials Requirements for IT Infrastructure (v3.3), and CISA's Known Exploited Vulnerabilities catalogue.

Stop reconstructing patch evidence under audit pressure

APaaS Assure maps every application to live vulnerabilities, holds each to the 14-day clock, and deploys the fix to Intune or Configuration Manager - so compliance is continuous, not a scramble.

Book a demo