top of page
Search

Security Update Management: How to Actually Meet the Cyber Essentials 14-Day Patching Rule


A guide for Get Cyber Certified applicants

If you take one thing from this article, take this: clicking "Update" is not the same as being compliant. Cyber Essentials does not ask whether your software updates itself. It asks whether every high-risk and critical security fix, for every piece of in-scope software, was installed within 14 days of the vendor releasing it — checked against the date your certificate is actually issued, not the date you pressed submit. Most applicants who fail this control do not fail because they ignored updates. They fail because they assumed "up to date" and "compliant" mean the same thing, and nobody checked the vendor's own vulnerability disclosures to confirm it.


This article explains the rule, where it applies, and where applicants consistently get caught out. It is not a step-by-step manual — vendor update screens change constantly — but a framework you can apply to any device or application, today and after every future release.


1. The rule, in the NCSC's own words


Security Update Management is one of the five Cyber Essentials technical controls, and it is defined in the NCSC's Cyber Essentials: Requirements for IT Infrastructure v3.3 (April 2026), the current authoritative technical standard behind the scheme:


"You must make sure that all software in scope is kept up to date. All software on in-scope devices must: be licensed and supported be removed from devices when it becomes unsupported, or removed from scope by using a defined sub-set that prevents all traffic to or from the internet have automatic updates enabled where possible be updated, including vulnerability fixes, within 14 days of release, where: the update fixes vulnerabilities described by the vendor as 'critical' or 'high risk' the update addresses vulnerabilities with a CVSS v3 base score of 7 or above there are no details of the level of vulnerabilities that the update fixes provided by the vendor"

Source: NCSC, Cyber Essentials: Requirements for IT Infrastructure v3.3, April 2026 (PDF) — see Section E.3, "Security Update Management."

Three important clarifications sit alongside that requirement, and they are exactly where applicants trip up:

  • "No severity stated" is not a free pass — it's the strictest category. If a vendor releases an update and doesn't tell you what it fixes, you must treat it as if it were critical and apply it within 14 days regardless.

  • Bundled updates take on the severity of their worst component. If a single update fixes one critical vulnerability alongside ten low-risk ones, the whole update — including the low-risk fixes — must go in within 14 days. You cannot separate it out and delay the "unimportant" parts.

  • Unsupported software is an automatic problem, full stop. Software must be "licensed and supported" — meaning the vendor has committed to a published future date when they will stop providing vulnerability fixes for it. Once that date passes, or once support ends, the software must be removed from the device or the device must be isolated from the internet entirely. There is no 14-day grace period here — unsupported means unsupported.


2. There are no exceptions — and the clock runs against your certification date, not your submission date


The NCSC's guidance is explicit that the 14-day window applies without carve-outs. There is no allowance for "we test patches before deploying them," no allowance for a slower internal change-management process, and no allowance for legacy or bespoke systems that "can't" be patched quickly. If your organisation's process cannot apply critical and high-risk fixes within 14 days, the process itself needs to change — not the requirement.


The point that catches out the most applicants, however, is this: the date your assessor uses to check whether an update was applied within 14 days is the date your certificate is issued — not the date you submitted your questionnaire. As explained in our companion article on the April 2026 Cyber Essentials requirements, this has always been how "point in time" certification works, and v3.3 has clarified it further. If your assessment isn't marked for several days after submission — for example, over a bank holiday weekend — every one of your in-scope systems must still be within the 14-day window on the day marking actually happens, not the day you clicked "submit." Build in a buffer. Don't submit on the 13th day.


3. Why "I pressed Update" isn't enough


Modern operating systems and applications are very good at telling you an update is installed. They are much less good at telling you:

  • Whether that update was itself released and applied within 14 days of the vendor's disclosure — most update mechanisms show you what's installed, not the gap between release date and install date

  • What severity the vendor assigned to the vulnerabilities it fixed, or the CVSS v3 base score if the vendor didn't use "critical/high risk" wording

  • Whether every in-scope device actually received the update — a single unpatched laptop in a cupboard, or a phone that hasn't synced in three weeks, is enough to fail the control

  • Whether the software itself is still supported at all — a "successful" update on an operating system version that has passed its end-of-support date does not make that system compliant


To genuinely evidence compliance, you need to cross-reference two separate things for every piece of in-scope software: (1) the vendor's own update/release history, and (2) the vendor's own severity rating or the CVSS v3 base score for what each update fixes. Assessors are trained to ask "how do you know," not just "is it up to date" — and "the icon shows a tick" is not an answer that holds up.


4. A generic process that works for any software, now and after future releases


Rather than a step-by-step guide (which would be outdated within months), use this repeatable process for every category of in-scope software:

  1. Confirm the software is still licensed and supported. Navigate to the vendor's official lifecycle or support page for that product and version, and confirm a future end-of-support date is published. If none is published, or the date has passed, that software cannot remain in scope on an internet-facing device.

  2. Navigate to the vendor's dedicated security update or advisory page (not the general "what's new" release notes — look specifically for their security bulletin, security advisory, or vulnerability disclosure page) and follow the vendor's own instructions to identify what the latest security-relevant releases fix.

  3. Check the severity the vendor has assigned. Most major vendors label vulnerabilities as critical, high, important, moderate or low, or provide a CVSS v3 base score. If severity isn't stated anywhere, treat the release as critical for Cyber Essentials purposes.

  4. Cross-reference the release date against your own patch records. For each critical/high-risk (CVSS 7.0+) item, or each unrated item, confirm your organisation applied that specific update within 14 days of its publication date — not 14 days of when you noticed it.

  5. Repeat this for every distinct piece of software in scope, not just the operating system. A typical organisation has far more in-scope software than they initially list — see Section 6 below.

  6. Keep a record. A simple log of vendor advisory reference, release date, severity/CVSS score, and the date you applied it is usually enough to evidence the control if you're asked.


5. Applies to: the categories NCSC names explicitly


The Security Update Management control in v3.3 explicitly states it applies to: servers, desktop computers, laptops, tablets, mobile phones, firewalls, routers, IaaS, PaaS, and SaaS. In practice, that breaks down into the following categories that applicants need to check individually.


Desktop and laptop operating systems

Windows, macOS and Linux distributions all publish monthly (or more frequent) security updates. Each vendor maintains a dedicated security update or release notes page separate from general feature announcements — go to that page specifically, not the general "what's new" blog, and check the severity rating assigned to each fix.


Server operating systems

Server OS versions (Windows Server, Linux server distributions) are frequently on a different patching cadence and update mechanism to desktop equivalents, and are commonly missed because they're patched less visibly than user-facing devices. They are just as in-scope, and just as subject to the 14-day rule, as any laptop.


Mobile phone operating systems

iOS/iPadOS and Android both publish their own security update and support lifecycle pages. Two things catch applicants out here: (1) older or budget Android handsets frequently stop receiving vendor OS security patches years before the physical device is retired — check the specific handset manufacturer's support page, not just "Android" in general; and (2) BYOD devices used for business purposes (subject to the scope conditions in the NCSC requirements) are in scope and must meet the same standard as company-owned devices.


Firewall and router firmware

Boundary firewalls, and any router or firewall functionality (including on VPN appliances), need their firmware checked against the manufacturer's own security advisory or PSIRT (Product Security Incident Response Team) page — this is usually a distinct page from the general firmware download page.


Web browsers

Every major browser (and its underlying engine) publishes its own security advisories separately from general release notes. Because browsers auto-update by default for most users, this is often assumed to be "automatically fine" — but auto-update failures (blocked by policy, a stalled update service, or a machine that's rarely rebooted) are common enough that they need checking, not assuming.


Anti-malware software

Anti-malware products update their detection signatures far more frequently than their application engine. Cyber Essentials is concerned with both: the underlying application/engine must be a supported, patched version, and the vendor's own guidance on how frequently signatures must refresh must be followed.


Email clients and Office/productivity suites

Whether delivered as a locally installed suite, a subscription-based continuously updated product, or a web application, your office suite and any standalone email client are in scope. Vendors typically maintain a specific security update release-notes page separate from feature update notes — that's the one to check.


Common third-party applications

Anything with an internet-connected component is in scope — this reaches well beyond the "obvious" software. PDF readers, image and creative editing software, video conferencing clients, remote access/remote support tools, compression utilities, and any browser extensions all count. These are the applications most frequently missed in a self-assessment, because they don't feel like "IT software" — but if it runs on an in-scope device and can connect to the internet, it's in scope.


Bespoke, Obscure and non common Applications or applications where the vendor does not publish udpates.

Since the assessor marks many assessments its usually quicker for them to check the vendor pages for updates however it is the applicants resopinsibility to demonstrate compliance so dont be surprised if your assessor pushes back to you to ask you for the URL you use to confirm compliance. Or for other evidence to confirm that the version you have listed is supported and has been patched within 14 days. This can cause issues where applications are installed where the vendor does not publish updates. How can you confirm that the application is patched within 14 days? It is the applicants responsibility to confirm this.


6. Cloud services and Security Update Management


Under v3.3, where a cloud service is Software as a Service (SaaS), the cloud provider is responsible for Security Update Management. Where it's Infrastructure as a Service (IaaS) or Platform as a Service (PaaS), responsibility is shared between your organisation and the provider. You remain responsible for confirming, and being able to evidence, how this is handled — a provider's trust centre, security statement, or shared-responsibility documentation is usually where to find this. See Section D(iv) of the NCSC v3.3 requirements for the full breakdown of who typically implements which control for each cloud service type.


7. The scale of the problem this creates for a manual, in-house check


For a single laptop running a typical business setup, "all in-scope software" commonly includes: the operating system, the browser (and often a second browser), anti-malware, an office suite, an email client, a PDF reader, a video conferencing app, one or two collaboration or messaging apps, and any line-of-business software. Multiply that across every desktop, laptop, server, phone, and network device your organisation owns, and cross-reference every one of those against its vendor's own severity-rated advisory page and CVSS score, within a rolling 14-day window that never stops — and you can see why "we keep our software updated" is very rarely enough on its own to evidence compliance to an assessor's satisfaction.


This is precisely the kind of control where a documented, evidenced, ongoing process makes the difference between a straightforward certification and a failed assessment against the automatic-fail conditions introduced in the April 2026 question set. If you're not confident your organisation has a robust way of cross-referencing every in-scope application against vendor severity data — rather than simply trusting that "Check for Updates" was clicked — this is exactly the kind of gap our Cyber Essentials Supported service is built to catch before you submit, through a structured gap analysis against the current question set and marking guidance. You can read more about that service, or get in touch with any questions, using the details below.



Appendix: Where to check vendor update and severity information


These links are correct as of July 2026. Vendors periodically restructure their websites, so if a link has moved, search the vendor's own site for "security update," "security bulletin," or "security advisories." This list covers the most commonly seen products and is not exhaustive — the same principle (find the vendor's dedicated security advisory page, not general release notes) applies to any software not listed here.


Operating systems (desktop)


Server operating systems


Mobile phone operating systems


Firewall and router firmware (examples — check your specific manufacturer)


Web browsers


Anti-malware


Email clients and Office/productivity suites


Common applications


Vulnerability severity reference (CVSS)


Primary Cyber Essentials sources


This article is intended to signpost NCSC and IASME official guidance and reflects the Get Cyber Certified assessor team's understanding of the current requirements. It does not replace the official NCSC and IASME documentation, which should always be treated as authoritative. Get Cyber Certified is in no way liable for any inaccuracies in this article

Comments

Get Cyber Certified Logo

0333 339 0383

bottom of page