Security Update Management for Cyber Essentials v3.3: the complete pillar guide

Security Update Management is the quietest-looking of the five Cyber Essentials pillars and the one UK organisations most often fail on at renewal. The reason is mechanical: controls drift. An organisation that passes User Access Control is likely to keep passing it next year. An organisation that passes Security Update Management can fail by the next quarter simply because a Windows build moves out of support or a firmware vendor pulls updates.

This guide covers every v3.3 requirement under the pillar, the exact evidence an assessor will accept in 2026, and the specific configurations and operational habits that keep you compliant through the full 12-month certificate cycle.

Security Update Management under v3.3 addresses the maintenance of every in-scope software and firmware component - operating systems, applications, browser plugins, network device firmware, mobile device OS versions, and the cloud services your organisation depends on. It is assessed under four headings:

1. Patching within the defined window - the 14-day rule for vendor high/critical, CVSS v3 7+ and unspecified-severity vulnerability fixes.

2. Supported versions only - nothing out of vendor support may be in scope.

3. Automated where possible - automatic updates are enabled where possible and required fixes are applied on time.

4. Cloud-service maintenance - where a service is managed by a third party, that party is expected to patch; where it is configured by you, your configuration must remain current.

The core expectation of the pillar is simple, and widely misunderstood:

Apply vulnerability fixes within 14 calendar days of vendor release when the vendor rates the issues high or critical, a CVSS v3 base score is at least 7, or the vendor supplies no vulnerability-severity details. The NCSC requirements, pages 17-18, also require licensed supported software and automatic updates where possible. A vendor-approved registry/configuration fix or workaround can qualify as a vulnerability fix; generic mitigation is not a waiver.

The 14-day clock starts at vendor release. It does not start at your scanner detecting it, at your change board approving it, or at your MSP raising a ticket. The window is absolute.

What passes:

• A documented patch-management process that targets 14 days for high/critical severity.
• Evidence the process runs - a patch-management tool report, or an MDM compliance view, or a sample of closed change tickets with deployment dates.
• A vendor-approved vulnerability fix applied within the required window. A business-critical label or generic mitigation does not waive the deadline.

What fails:

• "We patch monthly on the second Tuesday." A monthly cycle alone can miss the deadline when a required fix is released between scheduled runs. Check the actual release-to-install interval and out-of-cycle process.
• No reliable account of actual update status. Native update settings and version evidence can be suitable; a central management console is not compulsory.
• Deferred updates in Intune / Jamf configured to 30 days or more.

See also: The 14-day patching rule: what it actually says and how to stay compliant.

Evidence:

• Export from patch-management tool showing compliance percentage.
• Intune update-policy settings plus installation/restart evidence showing required fixes met the deadline; a compliance policy evaluates status rather than generally configuring updates.
• Sample change tickets for recent high/critical patches with deployment dates within 14 days of vendor release.

Every in-scope product must be licensed and supported by a vendor providing vulnerability fixes with a published future support end date. Check the exact version, edition and any active extended-support arrangement; the scheme does not impose a generic mainstream-support-only or mobile N-minus-one rule.

Windows 10 requires a qualifying active ESU route after normal support ends. Supported Windows Server extended support can also qualify. For macOS, iOS/iPadOS and Android, check actual vendor/OEM coverage and available fixes; monthly Android releases are not a universal scheme requirement.

Browsers and applications need supported versions and timely required fixes. A supported extended-release channel is not automatically disqualified because it is not the latest stable channel.

Remove unsupported software, or exclude it through a defined subset preventing all traffic to or from the internet. An ordinary VLAN or documented risk acceptance is insufficient for this specific condition.

Useful evidence includes the device/version inventory, vendor lifecycle records, active ESU or extended-support entitlement where applicable, and deployed fix dates.

Enable automatic updates where possible and ensure required fixes are applied on time. Managed delivery helps scale and evidence; native automatic updates and effective manual handling where necessary can also work.

What passes:

• Windows: effective native automatic updates, Intune, WSUS or equivalent supported update controls.
• macOS: effective native automatic updates and required-fix checks, or supported MDM update enforcement.
• Mobile: effective native automatic updates and supported-version checks, or MDM as an optional management method.
• Third-party apps on Windows: a patch-management tool (Action1, NinjaOne, Automox, PatchMyPC, etc.) or a managed software delivery platform.
• Browsers: auto-update enabled and not disabled by policy.

What fails:

• Domain-joined machines with Windows Update set to "notify only."
• BYOD devices missing required fixes or without effective automatic updates where possible. Absence of MDM alone does not demonstrate failure.
• Ad-hoc patching by the MSP on request only.

Evidence:

• Intune update ring configuration.
• Patch management tool dashboard screenshot.
• Endpoint compliance report.

v3.3 treats cloud services as in scope for the Security Update pillar. What the assessor cares about:

• SaaS platform provider updates (Microsoft 365, Google Workspace, Salesforce, etc.) - the vendor patches automatically. Confirm the actual provider responsibility and keep customer-managed components supported and updated. A supported release channel is not automatically disqualified because it is not the latest channel.
• IaaS and PaaS (Azure, AWS, GCP) - patching of the underlying service is the cloud provider's responsibility; patching of anything you run on top (VMs, container images, function code, OS-level components of managed services) is yours. Evidence is your deployment pipeline or tooling.
• Configuration drift - a tenant setting that was compliant at issue but has since been changed (MFA disabled for a group, legacy authentication re-enabled) can create a drift-based failure at renewal. Monitor for it.

Evidence:

• Microsoft 365 release channel configuration.
• Container image scan results showing no high/critical CVEs outstanding.
• Cloud security posture management (CSPM) report.

Often overlooked. v3.3 puts firmware on in-scope network and boundary devices explicitly in scope:

• Boundary firewalls and routers - firmware current, vendor-supported.
• Wireless access points - firmware current.
• Home-office routers for remote workers - ordinary privately owned routers are out of scope; organisation-supplied routers are in scope and need applicable configuration and timely firmware fixes. See Cyber Essentials for remote and hybrid workforces.
• Network switches - if they have a management interface, firmware is in scope.

What fails:

• An in-scope organisation-supplied router that is unsupported or missing a required vulnerability fix. A private home router is outside this scope.
• An in-scope firewall with unsupported firmware or an overdue required fix. The firmware date alone does not prove failure.
• A wireless AP on a vendor-pulled firmware release.

Minimum artefacts to have ready before submission:

• [ ] Patch-management tool export showing compliance percentage and the date range covered.
• [ ] Intune / Jamf / MDM update-policy configuration screenshot.
• [ ] Endpoint asset list with OS version, last patch date.
• [ ] Mobile device OS version report.
• [ ] Sample change tickets for recent high/critical patches showing deployment inside 14 days.
• [ ] Record of vendor-approved fixes and deployed dates; unsupported software removed or excluded under the no-internet-traffic condition.
• [ ] Network device firmware inventory.
• [ ] Inventory and update evidence for organisation-supplied routers; no attestation of ordinary privately owned home routers is required.

1. A single device out of support in the sample. Verify exact lifecycle and any qualifying extended support; age or the Windows 10 family label alone does not prove lack of support.

2. Deferrals and restart delays missing the fix deadline. Required fixes must be installed within fourteen days of release; a deferral of fourteen days alone leaves no allowance for installation and restart.

3. BYOD missing required fixes. Apply effective controls; MDM is optional and actual work access prevents arbitrary exclusion.

4. Firmware forgotten. Routers, APs, network appliances never touched.

5. Mobile OS versions past OEM support still used for work email.

6. Third-party applications (not Microsoft, not Google) with no patch mechanism. Adobe, Zoom, Java - these need effective update coverage, whether native automatic updates or management tooling.

7. Software firewall posture on remote-worker laptops missed. Worker- or ISP-supplied home routers are out of scope; organisation-supplied routers remain in scope under v3.3, but the laptop's software firewall must be enabled, default-deny on inbound, and configured so a standard user cannot disable it. Note this explicitly in A2.5 of the questionnaire.

The pillar's failure mode is drift, so the pillar is passed not just at submission but through continuous maintenance. Three operational habits that matter:

1. Monthly patch-status review. Even if patches are delivered automatically, review the compliance percentage monthly. Investigate every device missing a required fix. A 95-percent dashboard target does not allow the remaining devices to miss the requirement.

2. Quarterly OS version review. Confirm every device is on a supported version. This is especially important for macOS and Android, where vendor support windows shorten faster than people remember.

3. Firmware inventory refresh. Check network device firmware twice a year. Routers and APs are the most commonly overlooked assets.

Fig Group's compliance platform automates these checks, raising an alert when a device drifts out of the 14-day window or moves to an unsupported OS, so your submission evidence stays fresh between certifications and the renewal is a formality, not a rebuild.

Security Update Management is a disciplined process problem, not a technical one. Fourteen days, supported versions only, managed mechanism, evidence retained - get that right and the pillar is routine. Ignore it and it is the pillar most likely to fail your renewal. A well-configured small organisation can produce every artefact on the evidence checklist in under an hour; Fig Group's certification service is within 6 working hours for complete compliant submissions received before midday on a UK business day, from £299.99 + VAT.

Start Cyber Essentials from £299.99 + VAT | The 14-day patching rule explained | All pricing | Fig Group platform for continuous compliance