Patch internet-facing services within 14 days of disclosure

What the control is

Every system that answers an unsolicited connection from the public internet — VPN concentrator, mail server, file-transfer appliance, web application, edge firewall, perimeter authentication proxy — is patched within fourteen days of vendor disclosure. Anything that lands on CISA’s Known Exploited Vulnerabilities catalogue moves to a faster track and is patched within seven days, regardless of whether the rest of the change calendar is open.

The control has two halves. The first is an accurate, continuously updated inventory of what is actually exposed to the public internet. The second is a patch-management process whose SLA is measured against the disclosure date, not the next quarterly change window. Both halves break in practice, and the control is only as strong as the weaker of the two.

Why it matters

The catalogue is the argument. Pulse Secure VPN (CVE-2019-11510) was exploited at scale across financial-services, government and energy-sector targets for months while organisations declined to patch their VPN concentrators because the maintenance window was inconvenient. Microsoft Exchange Hafnium (ProxyLogon, March 2021) was a four-vulnerability chain that turned every unpatched Exchange server on the internet into an initial-access target inside a week of disclosure. MOVEit Cl0p was the same dynamic against a managed-file-transfer appliance that finance, payroll and HR departments had quietly exposed to the internet. SharePoint ToolShell in July 2025 repeated the pattern. UNC3886’s eleven-month residence inside Singapore’s four major telecommunications operators — eventually evicted by Operation CYBER GUARDIAN in February 2026 — opened with a perimeter-firewall zero-day. The US Treasury BeyondTrust breach (December 2024) chained a perimeter remote-support appliance into the sanctions team’s workstations.

The shared step in every one of these is that the vendor patch was available before the exploit reached scale. The victim’s patch SLA was longer than the attacker’s exploit-to-mass-scan window. The Jaguar Land Rover production halt of late 2025 is in the same category — a perimeter exposure exploited faster than it was remediated. The control changes the geometry of the race.

Where the regulators sit

NCSC’s Cyber Assessment Framework, principle B4 (“System security”), explicitly requires that “known security vulnerabilities in systems are remediated proactively.” NCSC’s separate vulnerability management guidance specifies a 14-day target for internet-facing systems and 30 days for internal systems. NIST SP 800-40 Rev. 4 (“Guide to Enterprise Patch Management Planning”) makes the same distinction between exposure tiers. CIS Controls v8 Control 7 (“Continuous Vulnerability Management”) requires automated patch deployment for all enterprise assets and a documented SLA against external assets. CISA Binding Operational Directive 22-01 — which is mandatory for US federal civilian agencies — gives a strict deadline for every CVE that lands on the KEV catalogue and tracks compliance publicly. The Australian Essential Eight requires patching internet-facing applications within 48 hours at maturity level 3. None of the major frameworks accepts a patch SLA longer than two weeks for internet-exposed systems.

Where it usually breaks

The first failure mode is inventory. Most enterprises have an asset list maintained by IT and a public-internet attack surface that exceeds the asset list by a wide margin. The shadow-IT services, the forgotten staging environment, the marketing department’s WordPress install, the legacy file-transfer appliance kept alive for a single supplier — these are all on the internet, none of them on the patch register, and every one of them has shown up as an entry vector in the catalogue. The fix is a continuous external attack-surface management programme. Pick a tool, run it weekly, treat anything new it surfaces as an incident.

The second failure mode is the change-window politics. The internal argument against fast patching is operational risk: a botched patch can take a service offline. The argument is real but the comparison is wrong. The choice is not between “patch and risk an outage” and “don’t patch and stay safe.” The choice is between a controlled patch window and an attacker-controlled outage. The catalogue settles that comparison: every named victim above suffered a longer outage from the breach than any patch window would have caused. The fix is a pre-approved emergency patching SLA written into the change-management policy that bypasses the normal CAB cycle for internet-facing systems on the KEV catalogue.

The third failure mode is regression risk on bespoke applications. Patching a vendor appliance is mostly safe. Patching an in-house application stack means real testing. The fix is canary deployment against a copy of production rather than against production itself, and a rollback runbook with a defined trigger. Both are bog-standard SRE practices in the platform engineering world; neither is universal in security-led patch programmes.

What good looks like

A continuously updated inventory of every internet-facing service, generated from external attack-surface scanning rather than internal CMDB. A patch-management programme with an SLA measured in days from disclosure, not days from change-window. A pre-approved emergency patching path for KEV entries that does not require a change-advisory-board sign-off. A canary deployment process for in-house applications that lets a patch be tested against production traffic without exposing production users. A monthly metric reported to the board: percentage of disclosed vulnerabilities on internet-facing systems patched within SLA.

The control is not glamorous and it is not new. It is the single most consistently recommended control across every major framework, and the single most consistently breached one across the catalogue. The regulators are unanimous and the receipts are extensive.