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

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.

What the pillar covers

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 high and critical severity vulnerabilities.

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

3. Automated where possible - updates are delivered through a managed mechanism, not user discretion.

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.

1. The 14-day patching rule

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

> Vulnerabilities rated high or critical (CVSS v3 base score 7.0 and above) must be patched within 14 calendar days of the patch being released by the vendor.

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 defined exception process for patches that cannot be applied in 14 days (vendor-issued workaround in place, business-critical system with a mitigation).

What fails:

• "We patch monthly on the second Tuesday." Monthly cycles do not meet 14 days. If a patch drops on day 1 of the cycle, it waits 28 days before deployment.
• No evidence of patch status - "we use Windows Update" without a management console backing it.
• 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 compliance policy showing maximum deferral periods under 14 days.
• Sample change tickets for recent high/critical patches with deployment dates within 14 days of vendor release.

2. Supported versions only

Every in-scope product must be on a vendor-supported version that still receives security updates. This is often where renewal failures happen: the OS version you were on last year is now out of support.

Operating systems under v3.3 (indicative as of April 2026):

• Windows 10 - out of mainstream support. Must be moved off, or on an Extended Security Updates (ESU) contract with evidence of active cover, before the submission window.
• Windows 11 - supported builds only. Older feature updates drop out of support sooner than people expect.
• macOS - current and immediately previous major version receive security updates. Two versions back is usually acceptable if the vendor is still shipping patches.
• iOS / iPadOS - current and immediately previous major version.
• Android - device must be receiving monthly security patches from the OEM. Devices past their OEM support window fail the pillar.
• Windows Server - current supported versions with mainstream support active; out-of-support builds (2012, 2012 R2 without ESU) fail.
• Linux - must be on a distribution release still receiving security patches.

Applications and browsers:

• Browsers must be on the latest stable channel.
• Productivity suites and line-of-business applications must be supported versions.
• Java, Adobe, and other historically vulnerable runtimes must be either removed or current.

What fails:

• A single laptop running Windows 10 Home without ESU in the sample.
• Android phones too old to receive OEM patches, used for email.
• Office 2016 still installed anywhere.
• End-of-life network appliance firmware.

Evidence:

• Intune / Jamf / Workspace ONE device inventory showing OS versions across the fleet.
• Mobile device compliance report confirming minimum OS version.
• Endpoint asset list with OS version column.

3. Automated patching where possible

v3.3 expects updates to be delivered through a managed mechanism rather than left to individual user discretion. This does not mean every patch is applied automatically without review - it means the mechanism of delivery is systematic.

What passes:

• Windows: Intune, WSUS, or equivalent configuration-managed update policy.
• macOS: MDM-enforced update policy (Jamf, Kandji, Intune macOS).
• Mobile: MDM with minimum-OS-version compliance policy.
• 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 without any managed update mechanism.
• Ad-hoc patching by the MSP on request only.

Evidence:

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

4. Cloud-service maintenance

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. You are expected to configure the tenant to receive updates promptly (not pinned to old channels) and to have no auto-disabled security features.
• 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.

Firmware and network devices

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 - under v3.3, these are in scope. Default admin credentials must be changed and firmware must be current. See Cyber Essentials for remote and hybrid workforces.
• Network switches - if they have a management interface, firmware is in scope.

What fails:

• A five-year-old consumer router at a remote worker's home, never updated.
• A business-grade firewall with a firmware version from 2023.
• A wireless AP on a vendor-pulled firmware release.

Evidence checklist for the assessment

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.
• [ ] Exception register for patches that could not be applied in 14 days with documented mitigation.
• [ ] Network device firmware inventory.
• [ ] Home-office router attestation process for remote workers.

Common reasons Security Update Management submissions fail

1. A single device out of support in the sample. One Windows 10 laptop, one old iPhone - the pillar fails on evidence alone.

2. 30-day deferrals on Intune. Must be 14 or fewer.

3. BYOD with no managed update mechanism. Either bring them into MDM or exclude from scope.

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 a patch-management tool.

7. Remote workers' home routers ignored under the pre-v3.3 interpretation of scope. v3.3 puts them in scope explicitly.

Keeping the pillar compliant through the year

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. A drop below 95% inside the 14-day window is a leading indicator of a failed renewal.

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.

Bottom line

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 then certifies the submission within 6 working hours from £299.99 + VAT.

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