Skip to main content

The 14-day update rule

Critical and high-risk security updates, or updates with no severity given, must be installed within 14 days of release. Being one version behind is fine only until 14 days after the newer release.

Published by Apexward Group, an IASME Certification Body. Last reviewed 10 November 2026.

Cyber Essentials requires you to install security updates within 14 days of their release when they fix critical or high-risk vulnerabilities. The rule covers operating systems, router and firewall firmware, and applications including their extensions. Under the Danzell question set, the two 14-day questions (A6.4 for operating systems and firmware, A6.5 for applications) are automatic fails if you answer No.

Which updates the rule covers

An update must be installed within 14 days if any of these apply:

  • the vendor describes the fix as critical or high risk
  • the fix addresses a vulnerability with a CVSS v3 base score of 7 or more
  • the vendor gives no information about the severity

CVSS is the Common Vulnerability Scoring System, a 0 to 10 scale for how serious a flaw is. If an update bundles several fixes and any one of them is critical or high, the whole update is in scope of the rule. Vulnerability fixes include patches, updates, registry fixes, configuration changes and scripts.

Feature updates and optional updates are not required. The NCSC strongly recommends, but does not require, installing every update within 14 days.

Worked example

Apple released iOS 27.2.1 on 9 November 2026. Apple does not rate the severity of its fixes, so Apple security releases count as high or critical.

DatePhone on iOS 27.2Phone on iOS 27.2.1
9 November 2026One version behind, inside the windowUp to date
16 November 2026Still inside the windowUp to date
23 November 2026Deadline: 14 days after releaseUp to date
24 November 2026Out of date: does not meet the ruleUp to date

Being one version behind is fine only until the deadline. The clock starts on the vendor's release date, not the day the device first offers the update, and not the day you notice it. Install before the deadline rather than on it.

Each release has its own clock. Suppose Apple then released 27.2.2 on 16 November. A phone still on 27.2 must reach at least 27.2.1 by 23 November. A phone on 27.2.1 is fine until 30 November, 14 days after 27.2.2. Newer releases do not reset the clock on older ones.

The same logic applies to every vendor. A Windows cumulative update, a Chrome release or a firewall firmware fix starts its own 14 days on its release date.

The answer must be true all the time

The question set says that if you cannot meet the 14 days in all circumstances, you do not meet the requirement. Your answer describes how you operate, not just what is installed on submission day. In practice:

  • your devices must be within the window on the day you submit
  • you must have a process that keeps them within it all year

How to meet it

  1. Turn on automatic updates for operating systems, browsers, office software and phones. The requirements expect this wherever possible.
  2. Force restarts. Many updates download but only apply after a restart or app relaunch. Set a deadline that restarts devices.
  3. Set deadlines shorter than 14 days. For example, Windows Update for Business deadlines of 7 days, or MDM update deadlines on iPhones and Macs.
  4. Keep a manual list of things that cannot auto-update: firewalls, servers, NAS devices, line-of-business software. Check them at least weekly.
  5. Watch vendor release pages, such as Apple security releases, Microsoft's monthly security updates and your firewall vendor's advisories.
  6. Check before you submit. Look at each device type's installed version against the latest release.

Checking a version live

The Knowledge Hub's software checker, and the cyberessentials_check_software tool on the CyberEssentials.AI MCP server, compute this live from vendor release data. Give a product and version, and they tell you whether the release line is supported, whether a newer security release exists, and the date by which it must be installed.

Edge cases

  • Staged rollouts. Some vendors release updates gradually. Our reading is that the clock still runs from the release date, so trigger the update yourself if the rollout is slow.
  • Updates that break something. Testing is allowed, but it must fit inside the 14 days.
  • Unsupported software. If no update will ever come, the 14-day rule cannot be met. See the supported software rule.

Your Certification Body judges whether your process and evidence meet the rule. The readiness checker asks about your patching before you start.

Sources

This is guidance, not a marking decision: your Certification Body marks your submitted assessment. Contains public sector information licensed under the Open Government Licence v3.0. All articles